I think the best way to answer this question is to go through some of the challenges involved in running Sitecore on Prem and Sitecore IaaS and how the PaaS model solves these challenges. I specifically want to look at installing Sitecore PaaS, deploying code to Sitecore, upgrading Sitecore versions and scaling Sitecore. Infrastructure cost is also an important consideration, so I will provide some real life cost examples of running specific Azure PaaS installs. My working examples and experiences are with Sitecore 9.0.2 specifically.
In this post I cover the benefits and drawbacks of Sitecore PaaS running in Azure cloud, the installation process and hosting models available.
The Sitecore CMS is a difficult platform to install manually. A single workstation install for development purposes is fairly straightforward, this is something that can be completed in a day or less. But a scalable, distributed Sitecore install for production purposes is not a one day activity. It can easily take a good month to stand up and tune an IaaS infrastructure and install Sitecore into it.
A base Sitecore PaaS install however, can be completed in about an hour.
Why are PaaS installs so quick? ARM templates.
Azure Resource Management (ARM) templates enable Azure infrastructure automation. If you are using Azure’s Resource Groups model (vs Classic, as recommended by Microsoft) then you have access to ARM based installs. Sitecore provides Azure ARM templates for several topology SKUs designed for different traffic requirements.
A Sitecore PaaS environment is straightforward for web site code deploys. You have many options here including FTP, Web Deploy, and Kudu. These approaches can be automated as part of a build pipeline using Jenkins or Azure Dev Ops.
There is a snag with PaaS however. Sitecore package deploys that include code do not work well in a scaled PaaS environment. This is because a scaled environment runs CM app services and CD app services, and the CD app services do not expose the Sitecore shell, obviously for security reasons. If you are using package deploys to install your site code, I recommend looking into an alternative. The locked down shell also makes it difficult to install Sitecore modules, since these are just package installs.
Upgrading Sitecore is well - ridiculously difficult. A Sitecore upgrade requires a project, especially if you are skipping multiple versions or moving to a new major release. My experience with Sitecore upgrades involves the following steps typically:
Unless you are running your entire site on one server (which is not uncommon), this is how I recommend upgrading. It gives you the ability to run an existing site in parallel and switch to the upgraded site. It is also handy to have the old site running and available in case you need to fallback. Azure PaaS makes this process a lot easier simply because of the ARM install efficiency. Tearing down an install is also simple. I recommend keeping Sitecore environments in separate resource groups because you can easily tear down an install by removing its parent resource group.
Azure PaaS is highly capable at scaling. I would say this is one of its greatest strengths, and if scaling for seasonal traffic or bursts in traffic is something you need, it is difficult to beat Azure PaaS.
Azure Web App Services can be autoscaled, either manually, or through performance metrics (CPU, memory usage, etc.). For example, Sitecore Content Delivery (CD) services can clone new instances to handle traffic based on metrics based rules These instances can be spun down once Azure detects they are no longer needed. The rules engine that drives the autoscaling is very sophisticated and flexible.
Individual App Services can be scaled up in place and on the fly or with automation as well. Vertical scaling is not as responsive as horizontal. From what I’ve seen, it can take up to 60 minutes to change the ‘size’ of an app service. Resizing also causes a service outage, so make sure you have a failover to handle traffic during this change. PaaS database scaling is just as easy to scale up and down. Database power is measured in DTUs which is a combined metric of CPU, data throughput and memory. Scaling databases is as simple as moving a slider to increase or decrease available DTUs.
Running PaaS means you don’t have to manage patching and testing servers. Setting up patching schedules and managing server restarts is nuisance work. I see this as one of the biggest advantages of Azure PaaS In Azure PaaS setups, Microsoft handles patching the underlying infrastructure and does this without causing service outages.
Note that many security auditors don't fully understand the PaaS ecosystem and can be suspicious of answers like "Microsoft takes care of that for us."
PaaS services offer a lot of other small quality of life benefits.
App Service Environments are highly secure, high performance Azure PaaS environments. They run on dedicated hardware (you don’t share hardware resources with other Azure customers) and they cost somewhere in the $20K/year USD for the smallest environment. Note that there are Internal and External ASE environments, and running a Sitecore site with external internet connectivity would require an External ASE environment.
The Azure Marketplace includes a Sitecore installation wizard that allows you to start an install in minutes. Options to add an Azure CDN and the Experience Accelerator are also included.
Sitecore publishes the standard Sitecore PaaS topology ARM templates through GitHub. These templates also include ARM deployments for Sitecore packages like Web Forms for Marketers (WFFM) and Sitecore Experience Accelerator (SXA) for example. These templates greatly simplify PaaS installs because the scaled model does not handle package installs very well.
If Amazon AWS is your preferred cloud platform you are at a disadvantage. There are no officially supported terraform templates for the AWS PaaS installs - I.e. Elastic Beanstalk and Amazon Relational Database Service (RDS). You’ll have to do some searching for third party scripts, or roll your own.
The ‘out-of-the-box’ Sitecore PaaS install topologies are not adequate as is. So while the install is very quick, there is still more configuration required to create a high-availability environment.
The smaller SKU topologies only deploy a single CD app service. If you need to make a change to a config file on this CD app service, the Sitecore app pool will have to restart and a service outage will occur. I have found this to be a huge gap in the architecture.
Deployment slots are an option here of course. Azure supports the ability to do blue-green deployments with app service slots. A slot is a second copy of the app service currently serving traffic with all of the code and configuration files copied to it. The slot (green) can be changed and tested without affecting the running (blue) app service. Once the slot is declared functional and has been ‘warmed up’ to serve traffic an instantaneous switch can be made where the slot is switched for the live app service. After the swap, the slot now contains the old state as it was running before the swap.
Slot deployments work very well with one exception. Sitecore changes that require template field name changes or field deletions cannot be deployed with slots. Because the database must be changed at exactly the same time as the code or runtime errors will occur. It is possible to create a blue/green web database and point the slot to the green database after the changes had been published to it, but this configuration is complicated.
I recommend adding a second CD if you are running a small or extra small SKU, and load balancing the 2 CD services with Azure’s Application Gateway load balancer or Azure Front Door (See my article on Front Door for App Services). This boosts your site resiliency and gives you the ability to make changes without outages even with breaking Sitecore template changes.
You’ll want to set up backups on your application services. Backups are not part of the ARM install. In fact, the ARM templates for earlier Sitecore 9 versions (Initial Release, 1 and 2) do not scale the app services high enough to unlock backups and other important production functionality (like always on). I recommend scaling up the app services to the 'P' level hosting plans.
Backups can be scheduled or run manually or both, and a storage account is required to store the backup files. Note that restoring an App Service from backup is not instantaneous. The Azure Portal triggers the request asynchronously so it appears to be complete almost immediately, but Sitecore backups are big and can take from 30 - 60 minutes to restore.
Azure PaaS is not cheap. Deploying with SOLR instead of Azure Search will save maybe $100 or so, but there are many databases and app services deployed with Azure PaaS. Sitecore provides very little help with costing, and simply forwards you to the Azure pricing calculator. Unlike IaaS where shutting down VMs in off hours saves cost, shutting down App Services does not save cost. You also cannot reserve instances the way you can with Azure VMs. I hope that these IaaS advantages appear in PaaS because I believe that will help level the playing field between the two models.
An Sitecore PaaS 'small' with app service scaling to P2V2s comes in around $2200 CDN per month on a pay-as-you-go subscription.
A pay-as-you-go dev/test subscription will save you about 40%, so this is a good option to save cost on test installs.
Sitecore PaaS has many advantages over IaaS, such as quick, automated installations using Sitecore supported ARM templates, robust scaling options, reduced maintenance needs with no OS patching and disk monitoring. The cost of PaaS however is high and there is a learning curve if you haven't used PaaS before. Tuning a Sitecore PaaS environment can be tricky and is worthy of another full post. It is difficult to beat the flexibility ease of maintenance of a PaaS setup and if ease of ownership is a high priority, I recommend Sitecore PaaS.
Photo by Alex Machado on Unsplash