Windows Azure is a 3-Lane Highway: How to Drive It

With its recent expansion, Windows Azure (Microsoft’s public cloud platform) now supports 3 modes of cloud computing. In this post, we’ll explain the rules of the road using a highway metaphor. Which lane of this 3-way highway should you drive in, and what kind of vehicles are permitted in each lane?

Traditionally, there was one way to use Windows Azure: Platform-as-a-Service (now called Cloud Services). Recently, the platform was greatly expanded to also provide Infrastructure-as-a-Service capability (Virtual Machines) and a special mode for web sites (Windows Azure Web Sites). Let’s point out here and now that although one area of the platform has “web sites” in its name, you can in fact host web sites at all three levels. The table below will give you a quick idea of what kind of apps belong where, after which we’ll take a look at each of these ways to use Windows Azure and compare them.

Windows Azure Web Sites	2-Tier Simple Web Sites • Web sites using open source frameworks • Web sites using SQL DB or MySQL • Web sites that run on IIS: ASP.NET, PHP, node.js
Cloud Services	Multi-Tier Modern Solutions • Stateless VM farms • Run on Windows Server • Where automated management is required • Require advanced functionality such as service bus, identity federation, CDN, traffic management
Virtual Machines	Legacy Solutions • Stateful single VM or VM farms • Run on Windows Server or Linux • Legacy LOB applications • Enterprise server products • Where portability between cloud and on-premises is required

Windows Azure Web Sites: The Fast Lane

Windows Azure Web Sites provides an accelerated way to work in the cloud for modern web sites. It has the automated management benefits normally associated with Platform-as-a-Service and the portability of workload normally associated with Infrastructure-as-a-Service. Unlike the other two modes for using Windows Azure, which support a great diversity of solution types, WAWS is limited to simple 2-tier web sites that can run on a standard IIS configuration. At the time of this writing, WAWS is in preview and does not yet come with an SLA. A certain level of use is free before charges apply.

Why do we call WAWS the fast lane? First of all, provisioning is lightning-quick: you can provision a web site and accompanying SQL or MySQL database in well under a minute—far less than the 10-15 minutes of provisioning time other segments of the platform require. Second, you have high productivity from the get-go because your web developers don’t have to learn anything new or change the way they work. Your web site can run as-is in the cloud. Deployment is a beautiful thing in WAWS: you can use Web Deploy, FTS, Git or TFS. Moreover, you only have to deploy to a single server regardless of how many VMs your site runs on: Windows Azure takes care of distributing deployments out to all instances. Lastly, one other nice speedy aspect of WAWS is that you can provision web sites ready to go with your favorite web framework by choosing from a gallery that includes DotNetNuke, Drupal, Joomla, Orchard, Umbraco, and WordPress.

The reason WAWS deployment is so fast is that it uses a pre-allocated pool of VMs for web serving. By default, you are working in shared mode, which means you are using this pool and sharing your VMs with other tenants. That might sound a little dangerous, but virtual directory isolation keeps your work and that of other tenants walled off from each other. At a higher cost, you can choose to switch over to reserved mode, in which your VMs are dedicated to you alone. In either mode, you can scale the number of instances using the Windows Azure management portal.

What kind of web technologies can you run in WAWS? Anything compatible with IIS, including ASP.NET, classic ASP, PHP, and node.js. WAWS does come with some limitations. Architecturally, you are limited to simple 2-tier web sites that run on IIS with a standard configuration. However, you cannot change the IIS configuration, remote desktop to the VM, or otherwise make changes that might affect other tenants. If you need more than this, such as a third tier for web services, you should look at Cloud Services or Virtual Machines instead.

From a VM persistence standpoint, disk file changes are persistently saved in Windows Azure Storage. However, all VM instances for a site are sharing common storage—so you need to consider file overwrites.

The bottom line: Windows Azure Web Sites provide a fast lane for web sites in the cloud, offering the best attributes of PaaS (automated management) and IaaS (portability) without requiring web developers to change the way the work—but they can only be used with simple 2-tier web sites that can run on IIS in a default configuration.

See my post Reintroducing Windows Azure: Web Sites for a detailed walk-through of this feature.

Cloud Services: Leave the Driving to Us

Cloud Services are the Platform-as-a-Service (PaaS) way to use Windows Azure. PaaS gives you automated management and a large toolbox of valuable services to compose solutions from. 

PaaS can be controversial: some see it as the modern way to design applications that leverage the differences and advantages of cloud computing environments; others view PaaS with concerns about vendor/platform lock-in. Keep in mind, the expense of preserving full cloud/on-prem portability is limiting yourself to the least common denominator of both; that is, not taking advantage of the special functionality available in the cloud.

The cornerstone Windows Azure Compute service which hosts applications uses a declarative model to specify the shape and size of your solution. Although many kinds of software can run in the cloud at this level, including complex multi-tier solutions, this model must be adhered to. Your solution consists of one of more roles, where each role is a VM farm. There are several kinds of roles, including web roles for Internet-facing software and worker roles for everything else. You can connect your roles to each other or to the outside world using load-balanced endpoints or alternative methods such as queues. The VM instances that make up a role are not persistent, meaning you cannot rely on VM state changes (such as disk file updates) to stay around; for persistence you must use a storage or database service. You’ll need at least 2 VM instances per role in order for the 99.95% (3½ 9’s) Compute SLA to apply. Most of the other cloud services give you a 99.9% (3 9’s) SLA.

There are many other cloud services to choose from that provide storage, relational data, identity, communication, caching, traffic management, and more. Many of these services provide extremely valuable functionality for pennies such as federating identity or brokering messages—and they’re managed for you. Most PaaS solutions leverage a combination of cloud services.

The automated management in Cloud Services is very attractive. For the Compute service, this includes automated patching and orchestrated software updates across your VMs. Storage and database services store data with triple-redundancy and have automatic fail-over. The traffic management service can check the health of your applications and fail over from one data center to another when necessary. VM instances and storage units are spread across fault domains in the data center to maintain availability in the event of a data center failure.

Cloud Services do require you to adhere to its model, and sometimes that means designing for the cloud or adapting existing applications to fit the cloud. Sometimes this is a small effort and sometimes it is not. Modern SOA applications based on tiers of stateless VM farms are generally very straightforward to move to Cloud Services. Solutions that have a single-server model, or depend on local VM state, usually require moderate-to-significant changes. These changes can sacrifice portability of your application, especially if you are highly dependent on cloud service functionality not available elsewhere.

Cloud Services provide an SDK and a simulation environment that allow you to develop and test locally before deploying to a cloud data center. To deploy, you must package your solution and publish it to the cloud to a Staging slot or a Production slot. You can promote a cloud deployment from Staging to Production in a fast, one-click operation.

The bottom line: cloud services provide automated management, valuable functionality, and architectural versatility—but apps may need to be adapted to fit its model, and strong dependence on platform-specific cloud services can result in apps that are no longer portable to other environments.

See my post Reintroducing Windows Azure: Cloud Services for highlights of what’s new in this area.

Virtual Machines: Self-Service

Virtual Machines are the Infrastructure-as-a-Service (IaaS) level of Windows Azure. You stand up virtual machines, configure them yourself, and manage them yourself. If you value portability of workload (the ability to move your IT assets between the cloud and on-premises seamlessly) and are fine managing your systems yourself, this lane might be for you. At the time of this writing, Virtual Machines are in preview; however, they do come with an SLA and are not free despite the pre-release status.

Although it comes at the cost of self-management, Virtual Machines provide great versatility. You provision Linux or Windows Server VMs and either compose the VM images in the cloud or upload a VHD you’re previously created using Hyper-V. You can capture a VM and add it your image gallery for easy reuse.

In Virtual Machines, individual VMs are persistent. It’s fine to run just one instance of a VM, you don’t have to worry about losing VM state, and you get a 99.9% SLA. This makes virtual machines the right choice for single-server solutions and server products that use local disk files. You can’t run a product like Active Directory or SQL Server or SharePoint Server successfully in Cloud Services, but you can in Virtual Machines. Virtual machines are also often the best fit for legacy applications.

You can group your virtual machines in a common availability set, which will spread instances across fault domains in the data center for high availability in the event of a data center failure. You can provision load-balanced endpoints to direct Internet traffic to your availability set.

The bottom line: Virtual Machines are for the do-it-yourself IT person (like a driving enthusiast who also likes to work on their car and do their own tuning and maintenance). It's also the only way to run certain kinds of applications, such as single-server stateful solutions and some server products.

See my post Reintroducing Windows Azure: Virtual Machines for a detailed walk-through of this feature.

WAWS, Cloud Services, & VMs Compared

The table below contrasts Windows Azure, Web Sites, Cloud Services, and Virtual Machines.

	WAWS	Cloud Services	Virtual Machines
Level (PaaS/IaaS)	PaaS with the portability of IaaS	PaaS	IaaS
Portability	Fully portable	Design or adapt for cloud	Fully portable
Management	Automated	Automated	Customer Responsibility
Architecture	2-tier IIS web sites only	Versatile	Versatile
Unit of  Management	Web Site	Cloud Service	Virtual Machine
Persistence	VMs share persistence	VMs are not persistent	Each VM is persistent
Provisioning	Under a minute	10-15 minutes	10-15 minutes
Technology platform	Windows Server / IIS	Windows Server	Windows Server, Linux
Deployment	Web Deploy, FTP, Git, TFS	Package and Publish	Compose VMs or upload VHDs
Gallery	Common web frameworks	Microsoft Guest OS images	Microsoft-provided and user-saved VM images
SLA	None during preview	3 9’s / (3½ 9’s Compute) requires 2+ VMs per role	3 9’s (single VM)

Let’s contrast three characteristics that you might care about when using the cloud: automated management, portability of workload between cloud and on-premises, and architectural versatility. As you can see from the magic triangle below, each mode will give you two of the three.

Choice is good, but it comes with the responsibility to choose well. I hope the above has helped to characterize the 3-lane highway that is Windows Azure. Drive safely!

Reintroducing Windows Azure, Part 2: Windows Azure Web Sites

In this series we’re taking a fresh look at Windows Azure, which was re-launched on June 7 with a highly-publicized Meet Windows Azure event. Here in Part 2, we’ll explore the new Windows Azure Web Sites (WAWS) feature.

What are Windows Azure Web Sites for?

As we mentioned in Part 1, the new Windows Azure can be used at 3 levels. Two of these are well-known cloud categories: Virtual Machines provides Infrastructure-as-a-Service (IaaS), and Cloud Services provides Platform-as-a-Service (PaaS). PaaS, the traditional offering in Windows Azure, has many attractive qualities including automated management and a powerful collection of services for compute, storage, relational data, caching, communication, identity, networking, and more.

You can run web sites at either the PaaS and IaaS level, so why a third mode for using the cloud just for web sites? Well, PaaS and IaaS both force some compromises on you. PaaS often requires you to make application changes to accommodate the platform—which means portability suffers. IaaS, in contrast, doesn’t require you to change the way you do things—but it comes with the burden of self-management. Wouldn’t it be nice to combine the best of IaaS (“I don’t have to change the way I do things”) with the best of PaaS (“managed for me”)? That’s what Windows Azure Web Sites provides—but at the expense of architectural versatility: it’s only for 2-tier web sites that can run on IIS such as ASP.NET, PHP, or node.js. Since the vast majority of applications hosted in the cloud are web-based it’s appropriate to have this facility.

Three Modes for using Windows Azure

Since you can host web sites at all three levels of Windows Azure, which should you use and when?

·         WAWS is best for simple 2-tier web sites, especially if you’re using a popular web framework like WordPress, Drupal, Umbraco, Orchard, etc.; or if there is a My SQL requirement.

·         Cloud Services are best for applications that are more complex than 2-tier sites where you want automated management; and when you want to take advantage of the many powerful services in the platform.

·         Virtual Machines are best for solutions that are complex, hybrid, or require a server product; for single-server solutions; or when you prefer to manage everything yourself.

Speed: The Velocity You’ve Been Waiting For

Windows Azure Web Sites is the fastest way to use Windows Azure. There are a couple of reasons for that. First off, provisioning of a new web site takes under a minute. That’s right, under a minute. If you’ve used Windows Azure at other levels you know that a deployment takes around 10-15 minutes, so how is this lightning-fast provisioning realized? Well, Windows Azure Web Sites share a pool of shared VMs already fired up and ready to go.

There’s another sense in which Windows Azure Web Sites are fast, and that relates to your ability to work the way you always have. There’s support for a gallery of common web frameworks such as Joomla and WordPress. And, you can deploy the way you’re used to, such as by FTP or Web Deploy. You don’t have to deal with special cloud artifacts, you don’t have to learn something new, and you don’t have to change your processes or preferred tools. That protects your ability to work productively.

WAWS Eliminates Barriers to Productivity

Creating a Web Site #1: Quick Create

Creating a new web site is a fast and simple operation:

1. In the new Window Azure management portal, navigate to the Web Sites area.

2. Click the CREATE A WEB SITE link, or click the + New button at bottom left.

3. Select the method of web site creation you want. You can quickly create a web site with or without a database; or you can select from a gallery of open source frameworks. Depending on your choice, the dialog will ask you for one or more forms of information. Here, we’ll do a Quick Create which creates an empty web site with no database.

Quick Create of a Web Site

Once you click CREATE WEB SITE to complete the dialog, you’re on your way to a provisioned web site in no time at all. You’ll first see a Creating message. Shortly thereafter, once the site is ready to go, the status will show as Running and there will be a notification that the web site creation has succeeded.

Fast Provisioning of a Web Site

If we hit the production URL for the site (shown in the portal, based on the name you specified), we’ll get a placeholder page:

Default Page for a Newly Created Web Site

From here you could proceed to deploy a site up to the cloud such as an ASP.NET web site, a PHP web site, or a node.js web site. We’ll talk about deployment later in this post, but first let’s examine two other ways to create web sites.

Creating a Web Site #2: Quick Create with Database

You can also create a web site along with a database. When we select that option, the dialog will ask you whether to use an existing database or to create a new one. You can choose between a Windows Azure SQL database or a My SQL database.

Create Web Site with Database

The My SQL database-as-a-service is provided by Microsoft’s partner ClearDB, so if you choose this option you’ll need to agree to ClearDB’s terms of service.

Selecting My SQL Database Region and Agreeing to Terms of Service

Once again you’ll see the site (and database) provisioned very quickly, and the status will show as Running when the site is ready for use.

 

If you click the site to go its detail page in the portal, you’ll see near the bottom that the site has a linked resource: the MySQL database that was created.

At this point you can deploy your web site and data to the cloud when ready.

Creating a Web Site #3: Using the Gallery

Yet a third way to create a site is to select from a gallery. When you select this method, you’re given the choice of a web framework to install on the web site. We’ll choose WordPress here in our example.

 Again, the site will be quickly provisioned and can be used once its status shows as Running.

In our case, since we selected WordPress, we can do everything directly in the cloud at this point using WordPress itself. Clicking on the URL at right takes us to the admin set up page:

Newly-created WordPress site in the cloud – set up

From here, it’s just a matter of creating content and configuring the site the way you want. Here’s what the site looks like after initial admin set up:

 Deployment

As web developers use a variety of languages and frameworks, there’s no one way to do web site deployment. Windows Azure Web Sites therefore supports a number of popular deployment methods. These include Visual Studio Web Deploy, GitHub, FTP, Team Foundation Services (TFS), and Microsoft WebMatrix.

Let’s show one of those methods, deploying by FTP using Visual Studio. Assume we’ve done a quick create of an empty web site in the cloud (see Creating a Web Site #1: Quick Create above), and now we want to create and deploy an ASP.NET MVC4 site. For our purposes, we’ll just create a standard MVC4 project from a template.

If we look at the detail page for our web site in the portal, there are links at right to set deployment credentials and to download a publishing profile. Some forms of deployment will use your administrator credentials, but for FTP we need to specify custom credentials. First, we select Reset deployment credentials and set up a username and password.

Next, we click the link to download a publishing profile. We save the .publishsettings file to disk on our local machine, in the root folder of our web project.

Now, we can perform a Publish action on our web project in Visual Studio, selecting the FTP option in the publishing dialog.

Now we sit back for the publishing operation to finish.

Soon the publishing is complete and we can try hitting our web site cloud URL again. The deployed site now looks like this:

You may be wondering how this works when you have multiple web servers – do you need to separately publish to each one? No, you don’t: Windows Azure takes care of that for you. For all effective purposes, you can pretend there’s just one web server out there to publish to even if you have 2, 20 or 200 servers in actuality.

Dashboard

Each Windows Azure Web Site has a detail page that includes a dashboard. The dashboard shows you usage metrics for the site and details about your site such as its access URL and data center locale. From here you can take site actions, such as browsing to the site, stopping/starting it, or deleting it altogether.

Scaling

From the dash you can click Scale to review or change scale settings. You can scale by changing the number of instances, using slider controls and then saving changes. There’s also the option to run in shared or reserved mode. By default, you site is running in shared mode, which means your web site is running as part of a large pool, co-habiting VMs with other web sites (with isolation protections). You can elect to move to reserved mode, where the hosting VMs are dedicated to your site only (which costs more).

Windows Azure Web Sites is a service currently in preview that you have to sign up for in order to use. Your first 10 web sites are free (in shared mode).  In reserved mode you can run Small, Medium, or Large size VMs. See azure.com for rates and a pricing calculator.

Summary

Windows Azure Web Sites adds a compelling and low-cost cloud computing alternative to traditional IaaS and PaaS for 2-tier web sites. It provides the management benefits of PaaS without sacrificing the portability normally associated with IaaS. It’s extremely fast and productive to use. It plays well with popular web frameworks and deployment methods. It’s the way the cloud should be: easy and frictionless.

Next: Part 3: Windows Azure Virtual Machines