Download - IaaS, PaaS, And the Windows Azure Platform

8/2/2019 IaaS, PaaS, And the Windows Azure Platform

1/21

1

IaaS, PaaS, and the Windows Azure

Platform

Keith Pijanowski

Platform Strategy Advisor

Microsoft

October 2009

ContentsIntroduction .................................................................................................................................................. 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


2/21

2

IntroductionOne 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.


3/21

3

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


4/21

4

Figure 2 The On-Premise Application Lifecycle

An Overview of IaaS and PaaSToday 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.


5/21

5

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 applicationcode 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.


6/21

6

Platform Vendor Offering Style

Amazon Amazon Web Services IaaS

ServePath GoGrid IaaS

Rackspace Mosso|The Rackspace Cloud IaaS

Google Google App Engine PaaS

Microsoft Azure Services Platform PaaS

Salesforce.com Force.com 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 Cloudofferings?

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, anddata 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 CloudIn 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).
http://aws.amazon.com/http://aws.amazon.com/http://www.gogrid.com/http://www.gogrid.com/http://www.mosso.com/index.jsphttp://www.mosso.com/index.jsphttp://code.google.com/appengine/docs/whatisgoogleappengine.htmlhttp://code.google.com/appengine/docs/whatisgoogleappengine.htmlhttp://www.microsoft.com/azure/default.mspxhttp://www.microsoft.com/azure/default.mspxhttp://www.salesforce.com/platform/http://www.salesforce.com/platform/http://www.salesforce.com/platform/http://www.microsoft.com/azure/default.mspxhttp://code.google.com/appengine/docs/whatisgoogleappengine.htmlhttp://www.mosso.com/index.jsphttp://www.gogrid.com/http://aws.amazon.com/


7/21

7

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 on-

premise. 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.


8/21

8

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 afolder 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 upinto 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.


9/21

9

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.


10/21

10

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 CloudMost 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


11/21

11

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 InstancesIf 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.


12/21

12

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 scaleneeded 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 areneeded 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.


13/21

13

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

Dependency Management in the CloudToday 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 businesslogic. 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.


14/21

14

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 thathave 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


15/21

15

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


16/21

16

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 ConsiderationsBoth 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).


17/21

17

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 beupdated 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.


18/21

18

Figure 16 Cash Flow for an IaaS Environment


19/21

19

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


20/21

20

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

SummaryThe 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.


21/21

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 atwww.KeithPij.com.
http://www.keithpij.com/http://www.keithpij.com/http://www.keithpij.com/http://www.keithpij.com/