Web Sites vs Cloud Services vs Virtual Machines
With its recent expansion, Windows Azure (Microsoft‘s public cloud platform) now
supports 3 modes of cloud computing. In this article, 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
toreserved 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!
INTRODUCTION TO WINDOWS AZURE CLOUD SERVICES
Millions of developers around the world know how to create applications using the Windows Server programming model. Yet applications written for Windows Azure, Microsoft’s cloud platform, don’t exactly use this familiar model. While most of a Windows developer’s skills still apply, Windows Azure provides its own programming model.
Why? Why not just exactly replicate the familiar world of Windows Server in the cloud? Many vendors’
cloud platforms do just this, providing virtual machines (VMs) that act like on-premises VMs. This approach, commonly called Infrastructure as a Service (IaaS), certainly has value, and it’s the right choice for some applications. Yet cloud platforms are a new world, offering the potential for solving today’s problems in new ways. Instead of IaaS, Windows Azure offers a higher-level abstraction that’s typically categorized as Platform as a Service (PaaS). While it’s similar in many ways to the on-premises Windows world, this abstraction has its own programming model meant to help developers build better applications.
The Windows Azure programming model focuses on improving applications in three areas:
Administration: In PaaS technologies, the platform itself handles the lion’s share of administrative tasks. With Windows Azure, this means that the platform automatically takes care of things such as applying Windows patches and installing new versions of system software. The goal is to reduce the effort—and the cost—of administering the application environment.
Availability: Whether it’s planned or not, today’s applications usually have down time for Windows patches, application upgrades, hardware failures, and other reasons. Yet given the redundancy that cloud platforms make possible, there’s no longer any reason to accept this. The Windows Azure programming model is designed to let applications be continuously available, even in the face of software upgrades and hardware failures.
Scalability: The kinds of applications that people want to write for the cloud are often meant to handle lots of users. Yet the traditional Windows Server programming model wasn’t explicitly designed to support Internet-scale applications. The Windows Azure programming model, however, was intended from the start to do this. Created for the cloud era, it’s designed to let developers build the scalable applications that massive cloud data centers can support. Just as important, it also allows applications to scale down when necessary, letting them use just the resources they need.
Whether a developer uses an IaaS technology or a PaaS offering such as Windows Azure, building applications on cloud platforms has some inherent benefits. Both approaches let you pay only for the computing resources you use, for example, and both let you avoid waiting for your IT department to deploy servers. Yet important as they are, these benefits aren’t the topic here. Instead, the focus is entirely on making clear what the Windows Azure programming model is and what it offers.
THE THREE RULES OF THE WINDOWS AZURE PROGRAMMING MODEL
To get the benefits it promises, the Windows Azure programming model imposes three rules on
applications:
A Windows Azure application is built from one or more roles.
A Windows Azure application runs multiple instances of each role.
A Windows Azure application behaves correctly when any role instance fails.
It’s worth pointing out that Windows Azure can run applications that don’t follow all of these rules—it doesn’t actually enforce them. Instead, the platform simply assumes that every application obeys all three. Still, while you might choose to run an application on Windows Azure that violates one or more of the rules, be aware that this application isn’t actually using the Windows Azure programming model.
Unless you understand and follow the model’s rules, the application might not run as you expect it to.
A WINDOWS AZURE APPLICATION IS BUILT FROM ONE OR MORE ROLES
Whether an application runs in the cloud or in your data center, it can almost certainly be divided into logical parts. Windows Azure formalizes these divisions into roles. A role includes a specific set of code, such as a .NET assembly, and it defines the environment in which that code runs. Windows Azure today lets developers create three different kinds of roles:
Web role: As the name suggests, Web roles are largely intended for logic that interacts with the outside world via HTTP. Code written as a Web role typically gets its input through Internet Information Services (IIS), and it can be created using various technologies, including ASP.NET, Windows Communication Foundation (WCF), PHP, and Java.
Worker role: Logic written as a Worker role can interact with the outside world in various ways—it’s not limited to HTTP. For example, a Worker role might contain code that converts videos into a standard format or calculates the risk of an investment portfolio or performs some kind of data analysis.
Virtual Machine (VM) role: A VM role runs an image—a virtual hard disk (VHD)—of a Windows Server 2008 R2 virtual machine. This VHD is created using an on-premises Windows Server machine, then uploaded to Windows Azure. Once it’s stored in the cloud, the VHD can be loaded on demand into a VM role and executed. From January 2012 onwards the Virtual Machine (VM) role is replaced by Windows Azure Virtual Machine.
All three roles are useful. The VM role was made available quite recently, however, and so it’s fair to say that the most frequently used options today are Web and Worker roles. Figure 1 shows a simple Windows Azure application built with one Web role and one Worker role.
This application might use a Web role to accept HTTP requests from users, then hand off the work these users request, such as reformatting a video file and making it available for viewing, to a Worker role. A
primary reason for this two-part breakdown is that dividing tasks in this way can make an application easier to scale.
It’s also fine for a Windows Azure application to consist of just a single Web role or a single Worker role—
you don’t have to use both. A single application can even contain different kinds of Web and Worker roles. For example, an application might have one Web role that implements a browser interface, perhaps built using ASP.NET, and another Web role that exposes a Web services interface implemented using WCF. Similarly, a Windows Azure application that performed two different kinds of data analysis might define a distinct Worker role for each one. To keep things simple, though, we’ll assume that the example application described here has just one Web role and one Worker role.
As part of building a Windows Azure application, a developer creates a service definition file that names and describes the application’s roles. This file can also specify other information, such as the ports each role can listen on. Windows Azure uses this information to build the correct environment for running
As part of building a Windows Azure application, a developer creates a service definition file that names and describes the application’s roles. This file can also specify other information, such as the ports each role can listen on. Windows Azure uses this information to build the correct environment for running