IaaS, PaaS, and the Windows Azure Platform

Keith Pijanowski Platform Strategy Advisor Microsoft October 2009

Contents
Introduction .................................................................................................................................................. 2 An Overview of IaaS and PaaS ...................................................................................................................... 4 Building Applications to run in the Cloud ..................................................................................................... 6 Building Virtual Machines for an IaaS Offering ......................................................................................... 7 Building Application Packages for Windows Azure .................................................................................. 9 Scalability, Availability, and Reliability in the Cloud ................................................................................... 10 Managing Multiple Machine Instances ................................................................................................... 11 Windows Azures Fabric Controller ........................................................................................................ 12 Dependency Management in the Cloud ..................................................................................................... 13 Software Licenses and Virtual Machines ................................................................................................ 14 Azure Services ......................................................................................................................................... 14 Application Lifecycle Considerations .......................................................................................................... 16 The Lifecycle of a Virtual Machine .......................................................................................................... 16 The Lifecycle of an Application Package ................................................................................................. 19 Summary ..................................................................................................................................................... 20

Introduction
One of the uses of Cloud Computing is to provide an environment in which organizations can run their own custom applications in the Cloud. This is important because most organizations today have an IT presence whose purpose is to build custom software that gives the organization a competitive advantage. Unfortunately, the problem with custom built software is that it is expensive. Organizations have to pay a lot of upfront costs to purchase hardware and acquire software licenses (operating systems, databases, etc.). These upfront costs that are amortized over several years are known as capital expenditures. Additionally, ongoing support for hardware, software, and the application itself can be high. The bottom line is that to build a conventional on-premise solution a lot of costs are incurred before any value is gained from the custom application. Figure 1 below is a chart of upfront costs, ongoing costs and the value gained from an application over time when it is run on-premise. Figure 2 shows the lifecycle of a custom application and all the phases that are needed to procure and support an environment for the application to live on-premise. The goal of a Cloud Computing is to drive down upfront cost, drive down ongoing costs, and take complexity out of an applications lifecycle.

Figure 1 Capital Expenditures and ongoing costs associated with On-Premise Applications

Figure 2 The On-Premise Application Lifecycle

An Overview of IaaS and PaaS

Today there are two types of Cloud offerings emerging in the industry that can be used to host a custom application. These two offerings are Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). IaaS provides an environment for running user built virtualized systems in the cloud. A high level graphic illustrating this technique is shown in Figure 3. Using this technique virtual machines are created on premise and loaded with all the software that will eventually run in the cloud. This includes custom built software as well as licensed software. After the virtual machine is built it is uploaded to the Cloud Infrastructure and started. Once the virtual machine is started the IaaS vendor can ensure that the running virtual machine continues to look healthy as a whole. It is the responsibility of the customer to monitor all the custom built software and licensed software to insure that they are operating properly. IaaS is an option that is very flexible and is the best choice for moving applications to the cloud when there is no time to rework the applications code for a cloud environment.

Figure 3 Infrastructure as a Service

The other type of Cloud Offering for running custom applications is known as a Platform as a Service or PaaS for short. The Windows Azure Platform is such a platform. In a PaaS environment only application code needs to be uploaded configured and run. In other words, in a PaaS environment the unit of deployment is an application package which contains the code developed by the development team. This is shown in Figure 4. This implies that all the tools that an application requires to do its job already exist within the PaaS environment and are ready to use on demand.

Figure 4 The Azure Services Platform

Figure 5 below shows a list of cloud vendors that offer either Infrastructure as a Service or a Platform as a Service. This is by no means a complete list. It is just a sampling of what is out in the industry today in order to provide concrete examples of the two different techniques for building environments in the Cloud that can host a custom application.

Platform Vendor Amazon ServePath Rackspace Google Microsoft Salesforce.com

Offering Amazon Web Services GoGrid Mosso|The Rackspace Cloud Google App Engine Azure Services Platform Force.com

Style IaaS IaaS IaaS PaaS PaaS PaaS

Figure 5 Cloud Offerings for hosting custom applications

Figures 3 and 4 above are simplistic representations of both techniques. They leave out important details such as: 1. Are there any special considerations for building an application to run in each of these Cloud offerings? 2. How does each Cloud offering provide scalability, availability, and reliability? 3. What Cloud services can be utilized to replace licensed software? 4. How does each cloud offering affect the application lifecycle? Investigating these questions is a good way to develop an understanding of each offering and the differences between them. In the remaining sections of this article I will describe how IaaS environments operate and how the Windows Azure Platform operates. Along the way I will address the questions above. The questions above are not the only questions that should be considered when evaluating a cloud offering. There are other important questions pertaining to data privacy, service level agreements, and data center certifications that will impact the types of organizations and the types of applications that can take advantage of these cloud offerings. These issues are beyond the scope of this paper. In this paper I wish to focus on issues that will impact total cost of ownership and the complexity of the application running in the cloud.

Building Applications to run in the Cloud

In this section I will compare the unit of deployment for each offering style. Specifically I will discuss what is required to build a virtual machine for a cloud platform (IaaS). Then I will describe how application code needs to be structured and configured in order to run in the Azure Services Platform (PaaS).

Building Virtual Machines for an IaaS Offering

Before discussing how to build a virtual machine for an IaaS environment it is necessary to understand the runtime environment of an IaaS environment. Figure 6 shows a typical runtime environment for IaaS. Here we see physical infrastructure, volume storage and management APIs. Once a virtual machine is uploaded to an IaaS vendors hosting environment it can be configured to use the IaaS vendors raw storage (discussed in the next paragraph). Once configured, the virtual machine can be deployed and started via some form of automation which allocates available infrastructure to run the virtual machine (and the application within it).

Figure 6 The runtime environment for an IaaS offering

Building an application to run in an IaaS environment is very similar to building an application to run onpremise. Developers will use familiar tools, programming languages, and any needed licensed products (database software, workflow, user management, etc.). Once application development is complete the application code and any licensed software that the application is dependent upon are installed on a virtual machine. The virtual machine can be thought of as a container that insulates the application and its dependencies from the run time environment. A diagram showing the components of a virtual machine built for an IaaS environment is shown in Figure 7.

Figure 7 Inside a Virtual Machine built for an IaaS environment.

Application storage is an important consideration when using any cloud offering. Figure 7 shows how an IaaS vendor provides storage to a virtual machine. When running in an IaaS environment all storage local to the virtual machine should be considered volatile. For example, you would not want to create a folder on your C:\ drive and use it for database storage. This is due to the fact that if your virtual machine crashes while it is running then the easiest thing for your IaaS vendor to do is to restart your virtual machine from its initial state which is the state it was in when you uploaded it. To get around this problem cloud based storage volumes can be purchased and mounted as devices within your virtual machine. This allows any software running within the virtual machine to see these external cloud storage volumes as if they were conventional disk drives. This does not really represent an additional cost because if there was a way to safely use storage local to your virtual machine then that would mean your virtual machine would grow in size with usage. This would use roughly the same amount of storage as if the data were placed in the externally mounted volumes. The bottom line is that the cost would be about the same since most vendors charge by total storage used without regard for how it is chunked up into volumes. Furthermore, placing your application data in volumes outside the virtual machine allows the platform vendor to replicate (and possibly backup) the data for durability.

Building Application Packages for Windows Azure

The runtime environment of the Windows Azure Platform is known as Windows Azure. Windows Azure which is shown in Figure 8 is an operating system for the Cloud. A useful analogy is to compare Windows Azure to conventional on-premise operating systems. Conventional operating systems manage basic storage, devices, and run applications. Windows Azure provides the same functionality within Microsofts datacenters which are built to provide cloud computing. Basic storage is provided by the table, queue, and blob services shown in Figure 8. In order to provide a runtime environment for custom applications, Windows Azures Fabric Controller manages a datacenter of servers to provide compute power. Do not think of Windows Azure as a conventional operating system with a Start menu, a Control panel, and a desktop of icons. It is not an operating system in the traditional sense. Windows Azure is the storage services previous mentioned and the services provided by the Fabric Controller that provide compute power to an application running in a Microsoft datacenter that is accessible via the public internet.

Figure 8 Windows Azure the runtime environment for the Windows Azure Platform

The Fabric Controller can be thought of as a layer that sits on top of the physical infrastructure that is used to host an application. Application packages which contain all the components of an application are uploaded to Windows Azure. Once uploaded the application packages can be further configured and started on demand by the software owner. When started application components are deployed to physical infrastructure by the Fabric Controller.

Developers will use familiar tools and programming languages to build for Windows Azure. However, Windows Azure is slightly different than the runtime environment found within an on-premise data center because availability, reliability, and scale are specified via configuration and provided for automatically by the Fabric Controller (this will be discussed in the next section). Therefore, application code needs to be structured for Windows Azure. Figure 9 shows the basic structure of an application that is designed for Windows Azure. Using the terminology of the Windows Azure documentation, a web application becomes a Service that is composed of web roles and worker roles. A web role is a component that listens for web requests and responds to web requests. A worker role performs background processing and typically receives its input from the Windows Azure Queue Service. In a cloud environment that is managed by a Fabric Controller the service definition file is a very important part of the application. This file indentifies all the web roles and worker roles in the application. As we will see in the next section, the service definition file contains the applications needs for compute resources.

Figure 9 - Service Code (or a Web Application) built for the Azure Services Platform

Microsoft provides a software development kit that includes a Development Fabric that emulates Windows Azure on a developers desktop. This allows developers to code and unit test locally. It would be unfortunate if developers had to actually code and unit test within the cloud platform. Windows Azure also provides a staging environment that is separate from the production environment. Once code has been developed and unit tested locally it can be uploaded to the staging environment for integration testing and any other last minute tests before being deployed to the production environment.

Scalability, Availability, and Reliability in the Cloud

Most applications today do not run on a single machine. Oftentimes an applications workload is spread out over several machines to increase availability, allow for scalability, and eliminate any single points of failure (reliability). The configuration shown in Figure 10 illustrates this concept. It contains three web servers, three application servers, and two clustered database servers. Deploying an application in this

10

three tiered manner allows each tier to be available, reliable, and scale. In this section Ill show how an IaaS environment and the Windows Azure Platform provide scalability, availability, and reliability by emulating the techniques shown in Figure 10.

Figure 10 Availability, Scalability and Reliability in an on-premise environment

Managing Multiple Machine Instances

If an application is architected to be deployed across three logic tiers as shown in Figure 10 then to achieve the same availability and reliability from a cloud platform based on virtual machines, three different virtual machines would need to be designed, built and stored within the IaaS vendors environment. Specifically, you would need one virtual machine designed and built to play the role of a web server, another for the application server, and finally a database server would be needed. At run time the appropriate number of each type of virtual machine would need to be started. For example, to emulate Figure 10 in an IaaS environment you would need to start three instances of the web server virtual machine, three instances of the application server virtual machine, and two instances of the database server virtual machine. Therefore the environment shown in Figure 10 would require a total of eight machine instances to be up and running. Typically management APIs or a Management Web Site is used to mount storage volumes, load each virtual machine, and then run each virtual machine. If any layer of the system requires more processing power then it can be scaled accordingly. For example, the web servers and the application servers could be scaled out and the database servers could be scaled up. Figure 11 shows how such a system would be deployed to a cloud platform based on virtual machines.

11

Figure 11 Deploying a three tiered system to an IaaS environment

Windows Azures Fabric Controller

The Windows Azure Fabric Controller contains the machinery needed to inspect an applications service definition file and deploy the application in a manner that provides the availability, reliability, and scale needed by the application. For example, lets say that an application requires three instances of its web role and three instances of its worker role to be running at all times. The service definition file is used to specify how many instances of each role the Fabric Controller should start and keep running. The Fabric Controller would look for a place to deploy and run the three web roles and the three worker roles. A simple deployment option would be for the Fabric Controller to provide one physical system for all the roles that make up an application. This means that the three web roles and the three worker roles would be run on one physical system within a Microsoft datacenter. While this provides some availability (many web roles and worker roles can be started on the single virtual machine) it provides minimum scalability (limited to the CPU cycles of a single system) and no reliability (the system is a single point of failure). There is an answer to this problem. When multiple instances of roles are needed the Fabric Controller will make sure that the application does not sit behind a single physical point of failure like a power switch on a single rack of servers. This is shown in Figure 12. Notice in Figure 12 that relational database services are provided by SQL Azure Database, one of the Azure Services that will be discussed in the next section.

12

Figure 12 Availability, Scalability, and Reliability in the Azure Services Platform

Dependency Management in the Cloud

Today development teams do not build custom applications from scratch implementing every capability in the build phase of the application lifecycle. Typically, core software components such as database management systems are purchased from third party vendors. If a Cloud vendor can provide cloud services with similar capabilities then these dependencies can be reduced. This will also allow the cost and complexity of the application to be reduced. Additionally, no application should be a silo even if it is running in the cloud. Applications developers should have tools that let them easily connect to external applications. This allows for the retrieval of data managed by external applications. It also allows the application to consume external business logic. For example, many applications need to interoperate with purchased applications that provide capabilities to the business such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). Dealing with both of these dependencies licensed software components and interoperability with external systems - will be the toughest challenge development teams face if they wish to move to any cloud environment.

13

Software Licenses and Virtual Machines

If the application you wish to virtualize and run in an IaaS environment requires third party products like a relational database, or messaging middleware then customers will have to be purchase and support this third party products themselves. However, some IaaS vendors provide cloud based services that have the same or similar capabilities as licensed products. For example, data services and queue services can be used to replace a purchased database management systems and middleware messaging software respectively. This is shown in Figure 13. Application code would need to be rewritten such that it utilizes these cloud storage services instead of licensed database management software. However, once the application is restructured to use these services the complexity of the application would be reduced since this would result in one less virtual machine being needed. More importantly, the licenses for the database software and the messaging software would no longer be needed. These licenses would be replaced with usage fees associated with the cloud storage services.

Figure 13 - Replacing Licensed Software with Cloud Services

Azure Services
The goal of Azure Services is to reduce the need for licensed software. At the commercial launch of the Windows Azure Platform the following services will be online: Access Control Service, Service Bus, and

14

SQL Azure Database. Figure 14 shows the Azure Services and how they can be consumed by an application running in Windows Azure. To address the need for structured data, SQL Data Services can be used as a relational database in the Cloud.

Figure 14 Using Azure Services

The Service Bus, which is one of the Azure Services shown in Figure 14, provides for application interoperability. Using the Service Bus applications can expose their own data and logic to others as services and consume other applications services. For example, using the Service bus an application running within the Azure Services Platform could communicate with another application that is still running within the organizations on-premise datacenter. The other Azure Services shown in Figure 14 can be used in a similar fashion to help alleviate the need for purchased third party components. These are capabilities that most organizations do not wish to build themselves. In an on-premise environment software that provides these capabilities would be licensed from a third party vendor. Replacing these licensed software components is a tall order; however, if it can be accomplished then the savings passed on to the customer are far greater than the savings achieved by using a platform built to host virtual machines. This is due to the fact that only the custom code needs to be built and

15

uploaded to the Cloud. Once the application is started, only the application itself needs to be supported directly by the customer. Third party software does not need to be supported by the customer since these dependencies are replaced by the Azure services which are part of the platform and supported by Microsoft. There is a downside to this offering - application code will need to be reworked to take advantage of the Windows Azure Platform.

Application Lifecycle Considerations

Both of the cloud environments discussed in this paper makes the application lifecycle cheaper and easier than on premise development. However, there are differences between the two especially when it comes to the procurement of third party software, complexity in the application lifecycle, the types of applications that can be hosted, and the ongoing maintenance needed to support the hosted application. In this section I will investigate the application lifecycle for applications built for IaaS environments as well as applications built for the Windows Azure Platform.

The Lifecycle of a Virtual Machine

Figure 15 shows a high level process that depicts the tasks needed to utilize an IaaS environment for a custom application. Local development activities do not need to change assuming everything utilized to build the application can be virtualized. (This is the Build phase shown in Figure 15.) Next, software licenses will need to be procured from third party software vendors. For example database management systems and messaging middleware (Procurement phase). The virtual machines that represent the logical layers of the application can then be built. This is when the virtual machines that represent, the web servers, the application servers, and the database servers are built out (Virtualize phase). Usually IaaS vendors have readymade virtual machines that can be downloaded and used as a starting point for building out your virtual machines. Once the virtual machines are created and fully installed with all relevant software, you will need to create an account with your IaaS vendor if you do not already have one (Account phase). This step does not represent a cost. Typically just a credit card is needed. The virtual machines that make up the application can then be uploaded and started (Upload and Start phases respectively).

16

Figure 15 Using an Infrastructure as a Service Environment

It is important to note that there will be a charge for each virtual machine instance that is running. So if one virtual machine is started three times because it provides web server functionality which requires fault tolerance and high availability then there will be a charge for each running instance. While the application is running the platform vendor can monitor your virtual machine instances to insure that they look healthy. However, it is up to the customer to monitor the application and any third party software, like databases and messaging middleware, to make sure they are operating properly (Support phase). At some point the virtualized operating system and any third party software will need to be updated with either service packs or new versions. This will be the responsibility of the customer (shown as the Patch/Upgrade phase in the figure above). The upgrading of all underlying infrastructure is the responsibility of the IaaS vendor. Figure 15 also shows where costs are incurred in the process and Figure 16 shows these same costs over time in the form of a cash flow diagram.

17

Figure 16 Cash Flow for an IaaS Environment

18

The Lifecycle of an Application Package

Figure 17 shows a high level process that depicts the tasks needed to utilize the Windows Azure Platform. Local development activities do not need to change since Microsofts software development kit comes with a Development Fabric that emulates the runtime environment of Windows Azure. (This is the Build phase shown in Figure 17.) Before uploading code to the Windows Azure Platform you will need to create an account if you do not already have one (Account phase). This step does not represent a cost - only a credit card is needed. Once an account is setup application code can be uploaded and started. (The upload and start phases respectively.) It is important to note that there will be a charge for each web role and worker role that is running. So if one web role is started three times because it provides web functionality that requires fault tolerance and high availability then there will be a charge for each running instance. While the application is running it is the responsibility of the customer to monitor the application to make sure it is operating properly (Support phase). The upgrading of all infrastructure and software that makes up the Windows Azure Platform is the responsibility of Microsoft so this is not part of the application lifecycle for applications running on the Windows Azure Platform. Figure 17 also shows where costs are incurred in the process and Figure 18 shows these same costs over time in the form of a cash flow diagram.

Figure 17 Using the Azure Services Platform

19

Figure 18 Cash Flow for an Application using the Azure Services Platform

Summary
The true spirit of cloud computing is about replacing upfront costs and capital expenditures (CAPEX) with operational expenditures (OPEX). A Cloud environment should also drive down ongoing support costs. Today there are two types of cloud environments that can be utilized to lower upfront costs and ongoing costs that are incurred while building and running a custom application. These two styles are known as Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). An Infrastructure as a Service (IaaS) offering provides solid cost savings because the infrastructure associated with providing compute power, storage, and networking does not need to be purchased and maintained by the customer. These assets are the responsibility of the IaaS vendor. However, customers will have to be purchase and support third party software in the traditional fashion.

20

An Infrastructure as a Service offering also provides maximum flexibility because just about anything that can be virtualized can be run on these platforms. This is perhaps the biggest benefit of an IaaS environment. If a system can be represented as a series of virtual machines then it can be migrated into an IaaS environment with little or no rewriting of code. This also allows applications to more easily move back and forth between cloud environments and on-premise datacenters. The Windows Azure Platform is a Platform as a Service (PaaS) offering. Developers can use familiar programming languages and common development environments to build their applications. Simple applications that just use web pages, web services, and SQL Azure Database will be able to move between on-premise datacenters to the Azure Services Platform with minor configuration changes. However, applications that take advantage of the other Azure Services and Cloud specific features of Windows Azure like Blobs, Tables, Queues, and Worker roles will need to be written specifically for the platform. This is certainly an adoption hurdle for migrating existing applications to the Windows Azure Platform. However, organizations that do move to this platform will be able to replace more upfront costs and capital expenditures with operational expenditures because third party software licenses will no longer be needed.

Acknowledgements I would like to thank the following people for providing feedback that allowed this paper to be accurate and understandable: David Aiken, Eric Castillo, David Chou, Hanu Kommalapati, Steve Marx, Abe Pachikara, Wade Wegner, and William Zack.

Biography Keith Pijanowski is a Platform Strategy Advisor for Microsoft's Developer and Platform Evangelism team. Keith works with Microsoft's larger customers by helping them to apply new ideas and new technologies to business problems. Keith is also a frequent speaker at Microsoft events and community events in the New Jersey and New York area. You can reach Keith at www.KeithPij.com.

21