One of the things that almost everyone asks me when starting cloud adoption, is what the difference is between the various as a Service models. So much so, that I recently did a presentation on the topic at MVPDays in Edmonton. Here are the main points that I talked about for Infrastructure, Platform, and Software as a Service:

Infrastructure as a Service

IaaS, often called Cloud Infrastructure Services, is the first thing someone things of when they hear about “moving to the cloud.” Purely speaking, it’s a self-provisioned, self-managed server in someone else’s datacenter, that’s billed on a regular (ie: monthly) basis…The beefier your VM, the more expensive your bill. Running your VM into Azure does not mean that it’s now a Cloud VM, it just means that you’re running a VM in Azure. Cloud means elasticity, and a proper cloud implementation of a VM is a little more complex as we add in the ability to add or shrink the amount of VMs as required.

Cloud-enabling a VM workload is required if you want to meet the prerequisites to achieve Microsoft Azure’s 99.95% update guarantee. In the private enterprise, this will typically translate to your Line of Business applications, which would have been implemented as highly-available on-premises, often using Windows Failover Clustering. These workloads must be multi-instance compatible (aka cluster aware) to facilitate VM scaling.

Many VMs are not mission critical, however, or would otherwise not affect production due to a temporary outage. In these cases, I could guarantee you that running a single-instance VM in Azure will provide you a much higher level of stability and redundancy for significantly cheaper than can be purchased on-premises or at a co-location facility. With ExpressRoute connections to Azure providing 10Gb connectivity to your enterprise MPLS, Azure becomes a great primary or DR facility without even factoring in cloud capabilities.

Platform as a Service

PaaS is accurately dubbed Cloud Platform Services, and it’s role is to automate and manage the back-end components required to make a development platform available. Though most often classified for software developers to create, test, and debug applications, some PaaS solutions can also be used as a portion of a production workload. This provides guaranteed availability for the supporting components of an application and ensures patch levels are maintained.

Unfortunately, to utilize a PaaS solution, due to the runtime-level automation you are tied to a specific design and patch/version levels, which will turn some projects to IaaS. The AppDev folks really like building their software on PaaS, as there is no requirement to involve the infrastructure team in the VM/OS deployment process. It makes their job much easier, if the product they’re working on will support a PaaS backend.

Software as a Service

Cloud Application Services have taken control of the consumer market, with a plethora of solutions available from OneDrive to Netflix. Just like PaaS, one must first consider if the solution can be integrated into the organization. If so, it is often more beneficial to choose a SaaS solution when the opportunity exists. Take Office365 for example: E-mail is arguably the most critical system in any enterprise, and to provide highly-available messaging on-premises not only requires expensive hardware, but also to employ the expertise to maintain it. Alternatively, for ~$5/month/user, Microsoft can manage the system, providing you with connectivity, services, and an uptime guarantee that would be impossible to match for the same annual cost.

Hope this helps!

É