Those who have been associated with cloud computing for some time knows how to select a cloud deployment architecture. However, a few ISV partners our team works with consistently asks questions about the cloud architecture selection criteria and hence this post. It is really hard to decide IaaS or PaaS without the application context and the associated long term business goals; this post covers a few observations from my own personal experiences from working with various partners.
Cloud platforms at a very high level can be described with two groups of attributes – the architecture type and the deployment model. Infrastructure as a Service (IaaS), Platform as a Service (PaaS ) and Software as a Service (SaaS) are the terms used in describing the architecture while private cloud, public cloud, hosted cloud, government cloud and a few other variations of the similar concepts describe the cloud deployment model. From the technology perspective, every decision maker goes through the process of cloud platform selection and in that context, the first question that comes up is the cloud architecture selection. Risks management, agility, cost and nature of the solution are what will bring the answer.
This write up compares and contrasts PaaS and IaaS so that the technology teams can make informed decisions based on the real benefits of the respective cloud architectures. Even though I am using Azure as the technology, the concepts are equally valid for other cloud platforms.
The canonical benefit of cloud computing is the business agility fueled by the IT scalability enabled by the massive computing resources made available to the application developers. Businesses will no longer be bogged down by the IT resource issues as they now can easily create new solutions to help existing customers, venture into new business domains and enter new markets unhindered. While the business and IT agility characteristics are common to both PaaS and IaaS, some nuanced differences in the context of an application will make one of them more suitable for adoption.
This write up focuses on these differences and outline the business as well as technology benefits relative to each other.
PaaS is the self-service enabled compute service that provisions computing resources in terms of CPU, memory and volatile disk storage through resource descriptors provided at the deployment time. The unit of deployment in PaaS is an application package and its associated data. PaaS is characterized by the stateless compute nodes which will be complimented by a collection of managed services for accelerating the application delivery to the market. These managed services shown in the picture below are not unique to PaaS as the same can be consumed inside an IaaS hosted application.
Windows Azure PaaS is available to application developers as Web Role and Worker Role abstractions deployed into a resource container titled Cloud Service. The role abstractions encapsulate a programming model and a deployment model aided by a resource descriptor which when combined provides complete metadata for design time deployment as well as run time operations. The Web Role presents ASP.NET programming model that is meant to be used as a template for spawning individual node instances of a web farm as dictated by the accompanying XML resource descriptor.
The Worker Role exposes a background processing programming model for implementing batch processing farms with the necessary resources described in the accompanying XML resource descriptor.
There are several variations of the above roles resulting from the customizations for meeting specific platform needs. Examples are: ASP.NET MVC4 Web Role, WCF Service Web Role, Cache Worker Role and Worker Role with Service Bus Queue. These custom roles at provisioning time will invariably be mapped to either a Web Role or a Worker Role.
Web Role, Worker Role and Cloud Service collectively presents a design time sand box which by default constrains developers from taking hard dependencies on the underlying OS environment. Because of the low surface area between the deployed application and the OS, system software upgrades and security patches by Windows Azure is totally opaque to the application. Automated server maintenance presents a tangible opex savings relative to its IaaS counterpart. The complete list of positive and negative aspects of PaaS are listed below:
Automated server maintenance and auto scaling of compute resources for meeting temporal resource demands are the two significant contributors towards lowering the cost of operations. Optimizing operational cost is a key requirement for services operated by cost centers like corporate IT shops which services internal employees. Profitability of certain types of services targeting external customers is sensitive to the operational cost profiles especially the services that are commodity in nature. Commodity services tend to have a lot of competition both from the open source as well as the proprietary providers; the resulting price pressure will make PaaS a suitable hosting platform. Examples of such commodity services include content management, collaboration, storage and other horizontal services.
Certain intellectual property oriented cloud services in the vertical domains like airline revenue management with proprietary algorithms, reservoir simulation in upstream oil & gas operations, seismic interpretation applications for oil & gas exploration, real-time billing for telecom providers, etc. may not have as much price pressure as the commodity services. Providers of these services can afford to extract much larger per-seat licensing fee and hence their motivation towards a cloud architecture selection is not driven by the cost but by the flexibility of the architecture to realize the implementation. Since these vertical applications often require complete control of the OS due to the variety of factors including the usage of low level OS APIs and the 3rd party libraries that may not be compatible with the PaaS sandbox, they may favor IaaS.
Azure team tests the latest OS and application platforms and makes them available for developers to use in their applications. Due to the surface area between the application and the underlying platform is optimal in PaaS, developers will be able to move to new releases easily and build innovative solutions to meet the market demands. With IaaS, applications tend to be sticky to the underlying platform due to the tight coupling resulting from the complete control developers have on the OS and application platform stack. Migrating to newer releases of the infrastructure is much harder in IaaS resulting in applications getting stuck in the older platforms there by hampering innovation.
Windows Azure PaaS is characterized by the REST interfaces for a fine grained interaction with the deployment artifacts. These interfaces are wrapped with developer friendly PowerShell commandlets for easy deployment of applications. Developers are no longer needed to work at the levels that require deep understanding of the OS and the networking infrastructure. OS patch management and upgrades are no longer needed to be part of the runbook for operating PaaS hosted applications.
Adding a new network interface, public or private, is merely a data entry job; the developer is no longer need to be aware of the network adapters, binding IP addresses and entering port number exceptions in the server firewall or setting up routing tables. PaaS makes all of this very simple by allowing a developer to add network endpoints with public and private port mapping through intuitive commands or UI. Developers can also specify system diagnostics like performance monitor counters and application specific events from within the deployment descriptor without ever knowing the arcane aspects of Windows Server performance monitor event configuration. Essentially developers will work with applications and data which they are very familiar with. The data may include deployment metadata as well as line of business data.
Maintaining physical and/or virtual servers is a laborious process as it involves downloading of the patches, testing them on a representative sample of servers, verify application compatibility, distribute patches and perform rolling upgrades so as to not to impact the availability of the mission critical apps. In spite of the advances in automation, it still requires significant effort on the part of the IT Pros to keep the infrastructure healthy. Azure PaaS team takes care of the infrastructure health by keeping the infrastructure updated against all the known vulnerabilities for which fixes have been distributed. Since this process is opaque to the developers and is automatic, the risk of information breach resulting from the known vulnerabilities is significantly reduced
Leveraging the intellectual property embedded in existing applications is relatively harder with PaaS given the extent of rework necessary for certain types of applications due to the PaaS sandbox restrictions. Applications that rely on local file system, expect locally stored data to be persistent between restarts, applications that rely on dynamic TCP and UDP ports, applications that rely on MAC address for licensing, and applications that require reboots during installation (e.g. installation of a driver) are some examples that require rework if at all if they can be migrated to Azure PaaS without sacrificing the core functionality. Applications with dependencies on 3rd party SDKs and servers which may not have been certified to run inside the PaaS sandbox will also run into cloud migration issues. Due these reasons a service provider can’t transform their business through cloud adoption at the pace the market demands.
Due to the run time environment differences between Azure PaaS and the on-premise setup, applications have to be modified to be more transparent in terms of the telemetry they generate so that IT Professional can gain more insights into the operations and proactively mitigate the availability and scalability risks. Rewiring the diagnostics, accommodating resource governance in a multi-tenant setting, local file system access and implementing software metering are a few PaaS specific work items that will impact time-to-market and application portability. Due to these PaaS specific changes to the application, it is not easy to take the same application and run it on-premise.
PaaS ISV ecosystem is not as mature as its IaaS counterpart yet. If an app requires a specific RMS implementation, management & monitoring product or a specific license enforcement product, the chances are that these may not be available on Azure PaaS yet. IaaS will be a good cloud path for such applications due to the immediate portability of these 3rd party solutions. Of course one has to work with the respective ISVs for supportability of these products before making plans for cloud hosting.
Many cloud providers require the same code base for cloud hosting as well as for deploying on-premise at their customers. Due to the irreversible chances one has to make for PaaS deployment, ISVs will have to maintain two different build scripts and two sets of libraries that will adapt the build to multiple deployment and run time environments. This requires deliberate architecture effort that separates core libraries from the environment specific libraries and combine them at build time or inject them at run time into the execution context. This requires skilled architects and software designers to build systems for polymorphic deployments.
IaaS is a managed compute service that gives complete control of the OS and the application platform stack to the application developers and IT Professional which is analogous to Hyper-V and other virtualization platforms. The unit of deployment is at the granularity of a virtual machine. Developers with the help of IT Professionals deploy virtual machines, application bits and the associated data to the target compute infrastructure. Even though developers get complete control of the stack at the design time, the deployment still needs to consider the systemic qualities of the application influenced by the storage, virtual networking and the managed services ecosystem that surrounds it. While IaaS gives design time portability, in due course the application may take advantage of the managed services (e.g. Azure Storage, cache) that will impact its overall portability. Similar to the analysis of PaaS, we will take look at the advantages and disadvantages of IaaS from both business and technology angles.
Due to the excellent portability enabled by IaaS, ISVs now can easily start offering cloud hosted services to their customers with minimal effort. This will help business expansion through upselling within the current customer base as well as into new markets (e.g. small and medium businesses who don’t have much infrastructure) and new geographies. The quick time-to-market aspects of IaaS helps ISVs in establishing their leadership in their respective domains through the agility of technology adaption towards new inflexions in computing.
Mature ISV ecosystem readily offers various solution and operational components that are popular in an on-premise setting. A DRM component for protected content, a special encryption component for compliance, or a domain specific search service for information discovery within your app, anything and everything that is required by your application can be found compatible for running on IaaS. From the operations perspective, leveraging 3rd party components for integrating with the enterprise helpdesk, trouble ticket systems and management and monitoring infrastructure is pretty easy in IaaS relative to PaaS.
Applications that require complete control (e.g. Disaster Recovery services that need to clone the drive by capturing disk IO at the driver level, software licensing service based on the virtual MAC address) can be built on IaaS. The developers and IT professionals have access to the complete app platform stack, user mode subsystems and kernel level control so that the VM can be customized to the needs of the business domains they serve. Some business domains like telecom and financial services require security hardened OS distributions that can only be satisfied by IaaS.
IaaS allows excellent design time portability of the application assets as the granularity of the deployment is a Virtual Hard Drive (VHD) containing both OS and application bits. Application owners can easily migrate their Windows as well as Linux application and system code to Windows Azure without any rework. This assumes that all the system dependencies including database servers (e.g. Oracle, SQL Server, MySQL) and 3rd party components (e.g. Redis, RabitMQ, Cassandra) are also portable along with the application bits. ISVs often thrive to maximize the value of their investment by reusing the existing software assets in the cloud and IaaS is a perfect vehicle for accomplishing that.
Expensive to operate as the solutions have to factor in the higher server maintenance for software patching and upgrades. IaaS generally tend to operate its own database servers and other supporting application infrastructure (e.g. Active Directory) which also adds to the cost of operations relative to PaaS. PaaS is more conducive to the usage of cloud provider’s managed services (e.g. Azure Storage, Azure SQL Database, Azure AD) there by making it a better opex friendly compared to IaaS.
The complete control on the OS and application server stack encourages developers to take dependencies on specific versions of the OS and app server. As a result, application migration to future versions of the OS and app server ecosystem becomes progressively harder and harder. This will not only slow down innovation but also becomes harder to find developers to maintain the existing system.
Many companies have well defined processes for testing and updating on-premise severs for security vulnerabilities. These processes need to be extended to the cloud hosted IaaS VMs to mitigate hacking risks. An unpatched server hosting sensitive data and processing logic can pose a huge PR risk for the company. There are no such problems with PaaS as server patching is automatically taken care of.
Can be stuck with the older version of the operating systems and application stacks. This can result in applications that are difficult to maintain and add new functionality over the period of time. This often will result in massive reengineering efforts that are very risky. For example, companies stuck with VB6, VC++ and MFC find very difficult to find programmers to maintain the systems let alone program new systems. Some point in time they have to start massive fundamental architecture work to mitigate the legacy issues.
IaaS based applications suffer from the same DevOps issues that plague on-premise deployments. It requires rigorous processes to bring developers and IT Pros together to build operations’ friendly applications. One of the important tools of enabling DevOps is the deployment automation and the application instrumentation; given that these two aspects are not as fundamental to IT shops as they are to a PaaS service provider, IaaS requires rigorous processes to build operations friendly cloud services.
Diligent processes are required for server patching and upgrades; this is more so for smaller companies than larger companies with mature server maintenance practices. Customers have to set up patch testing environment either in the cloud or an on-premise representative app environment so that every patch that is applied to the servers will not impact production applications. IT Pros in conjunction with developers need to build smoke test scripts and run them to ensure that the patches won’t take down the mission critical systems. There is no need of patching the PaaS compute infrastructure due to the cloud provider taking care of it.
PaaS and IaaS are part of the larger cloud ecosystem where managed services add a lot of value to the deployment in terms of the accelerated solution development. While these two cloud architectures have their respective benefits as outlined in this document, focusing on either PaaS or IaaS alone only sheds light on a smaller part of the overall application run time environment that is compute. PaaS has a definite economic advantage for operations over IaaS for commodity applications where cost of operations breaks the business model. On the other hand, IaaS gives complete control of the OS and application platform stack which is a requirement for certain class of applications.
In essence, risks management, agility, cost and nature of the solution are the drivers when deciding one architecture solution.
Thanks to my colleague Jean-Roch Trannoy for reviewing this.
Do you know if you can configure certain VM settings to be persisted in Azure IaaS?
We are interested in moving a VM to the azure cloud with an app we have developed in ASP.NET. Unfortunately we use a 3rd-party library that is "hardware locked" to our system by looking at the machine name, MAC address, and HDD serial number.
We are not trying to circumvent our licensing agreement. We would just be able to move this VM to the cloud but if we can't guarantee some of the hardware "settings" our 3rd part component won't work and we can't deploy our app.
The vendor has no clue what their plans are in terms of becoming cloud ready, and so we feel that the onus is on us to get the job done.
Why cant you be more clear on what you are trying to say, than use jaggery words and expand the article.
I can see IAAS is making use of WebRole and WorkerRole with the help of WCF, ASP.Net ... but PAAS which is restful can also be achieved by WCF on Azure VM, I dont really understand the difference still after reading the post.
Can you write it crisp and clear...