Since PaaS and Windows Azure have both been in the news recently, thanks to a favorable report from Gartner, I thought it might be good timing to revisit a whitepaper I wrote on PaaS. And particularly, look at the differences between Azure IaaS vs. PaaS vs. SaaS.

There’s been a lot of talk about the different cloud-based services available today, including Infrastructure as a Service (IaaS), Software as a Service (SaaS) and Platform as a Service (PaaS). While each of these services is unique, PaaS stands out from the mix. This is not to suggest that PaaS is somehow better than IaaS; that would be an improper comparison. Before we discuss any further, it’s important to answer the question: what is paas cloud computing? The diagram below can help demonstrate how PaaS simply builds on the capabilities offered by IaaS. For a more in-depth breakdown, view a blog here about all the PaaS options available..

But if you are a developer, IT shop or an ISV responsible for building, deploying and maintaining solutions, leveraging PaaS is where you reap the maximum cloud-computing benefits.

When comparing Azure PaaS vs. IaaS, PaaS providers offer comprehensive application development, runtime and hosting environment for cloud-enabled applications. PaaS makes it easy to create SaaS applications with a low cost of entry, stress-free maintenance, scalability and fault tolerance, thus enabling companies to focus on their business expertise. This is why PaaS is seen as a game-changer in the IT world, fueling innovation from the larger players, including Microsoft (Windows Azure Platform), Google (Google App Engine), SalesForce, and even smaller players like Bungee Labs and Heroku.


In 2010, APPIRIO conducted a “State of the Public Cloud” survey. The survey focused on 150+ mid-to-large companies in North America who have already adopted at least one cloud application, and found 68% of the respondents planned to have a majority of their applications in the public cloud within three years. There are two concepts to note here: applications and public cloud. Let’s look at each one of these concepts and see how they relate to PaaS:

  • Public Cloud: In order to provide economies of scale and elasticity of resources at a price that is attractive to SMBs, PaaS providers need to maintain a massive infrastructure. The cost of setting up and maintaining such an infrastructure can only be justified by a large number of tenants. It’s no coincidence that almost all the major PaaS providers, including Windows Azure Platform, are based on the public cloud.
  • Applications: Survey respondents also indicated that they are looking to move their applications to the cloud. This is different from taking existing on-premises servers and moving them to a public IaaS or a private cloud. Doing so would not allow parts of the application to take advantage of elastic resources available in the cloud.

Now let’s compare Azure PaaS vs. IaaS. Moving a server to an IaaS platform can create some elastic virtualization, but the benefits are limited as various parts of the application (UI tier, business tier, etc.) cannot be individually scaled. This is why it is better to migrate the application to the cloud. In order to facilitate this migration, PaaS platforms offer application building-blocks that are symmetrical to the ones available on-premises. In other words, when building cloud applications, developers can still use the same development tools and programming constructs as the ones they use when building on-premises applications.

The diagram below illustrates this concept in the context of a traditional four-tier ASP.NET-based Web application. This application is deployed as a single virtual machine image within the on-premises datacenter.

Moving this image to an IaaS opens up the possibility of using shared pools of infrastructure resources.

However, it’s the PaaS platform (Windows Azure, in this instance) that allows each tier to scale independently. Perhaps your application doesn’t have an immediate need for this elasticity in scaling. By mapping parts of your application to a set of pre-built application services (such as AppFabric Caching, AppFabric storage, etc.), you can also improve fault tolerance and lower maintenance costs.

As you can see, PaaS providers are well-suited to support the two aforementioned concepts—public cloud and applications—and is why PaaS is increasingly seen as such an important service for the future. Here’s an example of how we’ve taken a traditional IT stack to Azure PaaS.

Let’s take a deeper look at the benefits of PaaS with the aid of some concrete examples. Since I have extensive hands-on experience with Windows Azure, I will reference its features to make the case for PaaS.


Even though organizations are benefiting from the advances in virtualization technology (live migration, virtualization assist processors, etc.), the overall management experience is not as seamless as they would like it to be. These organizations must continue to worry about creating and maintaining virtual machine images and configuring the necessary storage and network before they can start building and deploying their applications. By utilizing PaaS, their virtual machines, storage and network are pre-configured by the provider. Furthermore, the PaaS providers monitor the virtual machines for failures and initiate auto-recovery when needed.

In regards to resources like storage, compute and the network, PaaS-based applications can simply acquire these resources as needed and pay only for what they use.

It is helpful to see a series of steps that the Azure platform undertakes in order to meet the needs of an application:

  • First, the application developer uploads the binary code and resource requirements, such as the number of Web and middle-tier nodes, HW, memory, firewall settings, etc.
  • Based on the resource requirements, compute and network, resources are then allocated appropriately. Please refer to diagram below. Windows Azure will attempt to allocate the requested number of Web-tier nodes based on the resources available. Azure will also try to place the nodes across the different racks to improve the fault tolerance.
  • Azure then creates appropriate virtual machine images by placing application-specific code on top of base images and starts the virtual machines.
  • The Windows platform assigns dynamic IP (DIP) addresses to the machines.
  • Virtual IP addresses are allocated and mapped to DIPs.
  • Finally, Azure sets up the load balancer to route incoming client traffic appropriately.

The diagram above depicts a snapshot of available resources within a Windows Azure datacenter. The blue boxes denote available slots. Azure uses this information to dynamically allocate resources.

As you can see from the above steps, Azure intelligently pulls together resources to create a custom setup that meets application-specific needs (applications can operate under the impression there is a limitless supply of resources).

Note: All through the steps above, application developers were not expected to setup the OS, log into the machines directly or worry about IP addresses, routers or storage. Instead, the developers are free to focus on implementing the business logic.


Whether they are utilizing virtualization or not, organizations have to deal with changes in the form of patches, OS upgrades, etc. This is commonly the case even if the servers are placed with a “hoster.” As we saw earlier, PaaS providers are responsible for providing the OS image and are therefore responsible for keeping the images up-to-date.

It is helpful to see how the Windows Azure platform performs OS upgrades:

  • Windows Azure team applies patches once a month.
  • To ensure upgrades are performed without violating the SLA, Windows organizes the nodes that make up an application into virtual groupings called upgrade domains. Azure upgrades one domain at a time, stopping all the nodes, applying the necessary patches and then starting them back up again.
  • By stopping only the nodes running within the current upgrade domain, Azure ensures the upgrade takes place with as little impact to the running service as possible.The underlying virtual machine image is not changed in this process, thereby preserving any cached data.

As a case in point, consider the recent publicly disclosed vulnerability in ASP.NET. ASP.NET-based applications hosted on Windows Azure had the vulnerability patched when the Guest OS was automatically upgraded from version 1.6 to version 1.7.

The Azure platform introduced the notion of a Virtual Machine (VM) role. As part of using the VM role, users are allowed to bring their own custom virtual machine image to the cloud instead of using an image provided by Azure. This powerful capability allows users to control how the virtual machine image is setup. In many ways this is akin to the capability IaaS platforms offer.

But with great power comes great responsibility. Customers using the VM mode are expected to setup and maintain the OS themselves. Windows Azure does not automatically understand the health of applications running in a custom VM image.


Distributed applications, by their very nature, have a lot of moving parts and consequently a lot of required steps to assemble the various components, including installing and configuring caching components, access control components, database-tier components, etc.

PaaS greatly simplifies this assembly by providing many of these application components as ready-made services.

Here are some examples of application building block services offered by Windows Azure:

  • Azure App Fabric Caching: A distributed in-memory cache for applications running in Azure. Application developers do not need to bother with configuration, deployment or management of their cache. Applications simply provision the cache based on their needs (with the ability to dynamically adjust capacity), and only pay for what they use.
  • AppFabric Access Control Service: A service that simplifies access control for applications hosted in Azure. Instead of having to handle different access-control schemes (OAuth, OpenID, etc.), Azure-based applications can integrate with AppFabric Access Control. The AppFabric Access Control service in turn brokers the integration with various access control schemes, thereby greatly simplifying the task for developers.
  • SQL Azure Service:  A cloud-based relational database service available to applications hosted on Azure. Developers do not have to install, setup, patch or manage any software. High availability and fault tolerance is built-in and no physical administration is required.

There are two noteworthy things about the examples above. First, each of the services has a corresponding on-premises equivalent, making it possible for developers to migrate their applications to the cloud. Second, even though these services are functionally and semantically equivalent, they exhibit the core characteristics of the cloud—namely elasticity and fault tolerance.

For example, SQL Azure supports most the T-SQL functionality available on SQL Server running on premise. However, SQL Azure has built-in fault tolerance (it keeps multiple copies of the database in the background) and elasticity (databases can be scaled out seamlessly). Additionally, there is no need to go through the typical setup steps such as installing the product, applying patches and setting up back-up and recovery. Setting up a SQL Azure database is as easy as issuing a “create database” command.


In this post, we compared the difference between Azure PaaS vs. IaaS, reviewing what PaaS in cloud computing is, and how providers offer comprehensive application development, runtime and hosting environment for cloud-enabled applications. This greatly simplifies the IT aspects of creating SaaS applications and enables companies to focus on their business expertise. If you’re interested in seeing how AIS can help, learn more about our Azure PaaS service offering here.