Azure is still somewhat of a “Wild West” territory in the Sitecore world; there is definitely a good amount of curiosity that has built up over the past few years, however, the territory is still uncharted. Over a year ago Sitecore released an Azure module, which allowed hosting the Content Management System in the mysterious place called Azure cloud. Everyone is excited about it, but very few seem to understand it. The following article will explain the difference between the two main Azure hosting options for Sitecore, and lay down the foundation for following the best practices when comes to making an educated decision for choosing the right setup.
What is Microsoft Azure?
This is a huge topic most of which is well outside the scope of this article. To get familiar with Azure, check out the Microsoft’s documentation or even sign up for a free 30-day trial, which is pretty cool as you get unlimited access to all services with a $200 credit at the time of this writing.
As a side note, Azure portal was built on Node.js, but according to Microsoft, they are in the process of transferring it to .NET. Pretty cool, right!?
For the purpose of this article we will look at Azure primarily as a hosting environment. We will discuss other services like SQL Azure, Azure Distributed Cache, and Azure APIs in future posts on Sitecore Best Practices.
Azure Sitecore Hosting Options
When a decision is made to host Sitecore on Azure, for whatever reason, the next question that needs to be answered is what service offering should be used: Infrastructure as a Service, referred to in the rest of the article to as IaaS, and Platform as a Service – PaaS.
Wait, shouldn’t we just use the Sitecore Azure module, that’s what it’s for, right? Yes, and no.
Yes – the Sitecore Azure module allows for an easy use of the Azure’s PaaS offering, however, there are some cases when it may make sense to use the IaaS offering instead. The key difference between the two options is that the PaaS offering is built on Roles (Web and Worker) and the IaaS – Virtual Machines. Before we dive into the details of each hosting option let’s go over the difference between the Virtual Machines (VMs) and Web ad Worker Roles.
Difference Between Azure Virtual Machines and Azure Web and Worker Roles
Microsoft’s documentation has done a pretty good job of confusing new Azure users, they use the term virtual machine for VM and Web and Worker Role instances. The Azure pricing calculator does not make it easier either – both provide configuration for the VM size leading you to think that the difference between them is very subtle, but don’t be misled.
Azure Virtual Machines are the common instances of full server operating systems hosted on a virtual platform. Just like with any VM, users can remote into it and having the right access rights, can control everything on that machine. Nothing new here, just a good-old virtual machine service offer.
On the other hand, Worker and Web Role compute instances are also in their essence virtual machines, yet with limited access. Web Roles are primarily used for hosting websites and web applications, while Worker Roles – long running or resource intensive processes. With a Web Role, users only have access to the IIS, and with a Worker Role – runtime environment for running processes and services without a public facing website. Essentially the IIS and the runtime environment are the only things you have access to. All changes outside of these environments will be erased upon a system restart, a restart of a virtual machine hosting the role. This means that users have almost no control over the rest of the server configuration, although, it is possible to write startup scripts to make changes upon a reboot.
So in their essence, Web and Worker Roles are hosted by VMs, and when purchasing a role, by selecting the size of the VM in the Cloud section of the Azure calculator, you are selecting the size of the compute instance (VM) hosting the role. This is why Microsoft calls both of these options virtual machines, however, it is important to understand the difference, as it is what distinguishes the IaaS and PaaS services.
Now that we understand the difference between the Virtual Machines and Roles let’s take a look at how it translates into the IaaS and PaaS hosting options.
Azure Platform as a Service (PaaS)
Platform as a Service offering is based on Roles, whether Web or Worker. When setup with at least two roles of the same type running the same application, the environment would fall under the PaaS Service Level Agreement (SLA), which guarantees some very attractive benefits. The biggest of them all is eliminating the systems maintenance overhead! That’s right, with the PaaS option Microsoft will take care of all VM maintenance tasks, such as operating system updates, security patches, configuration, software, drivers…etc. This alone could save hundreds of thousands of dollars in system administration costs annually for large setups!
How does that work? Well, since with Web and Worker Roles users only have control over the IIS and the runtime environment, Microsoft is able to freely control everything else on the VM, and this is exactly why any changes outside of those dedicated environments would be erased upon a system reboot – simply because Microsoft does not want you to mess with the rest of the VM, as they are responsible for it.
Azure Infrastructure as a Service (IaaS)
Infrastructure as a Service setup offers a simple well-known access to conventional virtual machines, where users are responsible for all configurations and maintenance. Although this might seem as a worse option at first glance, many applications require having full control over the hosting environment, making the PaaS option too limiting.
Comparison of IaaS and PaaS for Sitecore Hosting
A knee-jerk reaction to a questions of “Which is best?” might point toward the PaaS option due to its excellent SLA terms; however, we should remember that both VMs and Roles are in their essence virtual machines, therefore, the same scalability options and uptime guarantee can be reached on both, IaaS and PaaS, if configured properly. For instance, the PaaS SLA guarantees a 99.95% uptime for Roles, however, we can reach the same availability with the IaaS VMs by placing them into the same Availability Set.This is one of those Azure tricks that not many know about!
At the end of the day, given the VMs are properly configured, the premium price users would pay for the PaaS goes toward the maintenance provided by Microsoft. This is in fact one of the biggest cost factors for choosing the hosting environment.
Another major decision factor is the lack of Sitecore support for the IaaS option. According to a recent message exchange with the support reps on support.sitecore.net, Sitecore would only provide full support for instances using the PaaS offering along with the Sitecore Azure module.
The following table provides a high-level comparison of the major cons and pros between the IaaS and PaaS options.
Lastly, the number of purchased Sitecore licenses can be an unexpected limitation. Why? Well, the PaaS environment requires a minimum of three Sitecore licenses to fall under the Azure SLA , one for the Content Management and two for Content Delivery environments. The same service level configuration can be reached with only two Sitecore licenses, with two load balanced VMs, each acting as a Content Management and Content Delivery environment.
When to use IaaS over Paas for Sitecore
After all, the PaaS seems to be the way to go for Sitecore, as it eliminates the headache of system maintenance, ease of the Sitecore Azure module setup, deployments, and scalability, as well as the full support that Sitecore provides with the use of the module. It seems, outside any internal business reasons, the only valid reason to go with the IaaS option would be when the client has only purchased two Sitecore licenses, or their system administrators really want to keep their jobs 🙂
Recommended Azure Environment for Sitecore
It is now settled that with the proper number of Sitecore licenses, it is best to go with the PaaS hosting option. The next step is to figure out the type of the PaaS Sitecore environment. There are two primary types:
- Hybrid – the CM environment is hosted on premise or in IaaS
- Pure PaaS – both CM and CD environments are hosted in Azure Web Roles
For more information about these two types, please see the Azure CMS Edition PDF (don’t be thrown off, there is in fact no such Sitecore edition, as Azure, this is still referring to the Azure Module; Sitecore happens to refer to the module as an edition in several places around the website, but a regional sales engineer has confirmed that this was referencing the above mentioned module).
The Pure PaaS approach is the recommended option, primarily because of the SLA and scalability applied to the CM environment, allowing for a high availability and spikes of content edits and visits on large websites. This approach is especially preferred if the rest of the company infrastructure is also hosted on Azure.
Some of the reasons to go with a hybrid solution include:
- budget considerations
- large number of on premise resources
- tight security requirements
- need for control over the hardware
- other business reasons
Azure Hosting for Sitecore Decision Review
Hopefully this article shed a bit of light on the two Azure hosting options for Sitecore and will be of help to all developers, architects and Sitecore users, when deciding on the Azure infrastructure or simply discussing it with a client. Although all Azure hosting roads may initially seem to lead to the PaaS approach, it is important to understand the use cases when the IaaS can be a more beneficial option. Like every Sitecore solution requires a custom approach, the environment decisions are just as important, if not more; after all, it presents the base for the new Sitecore website, and we all know that without a proper foundation solutions don’t hold up. Cheers!