The brave new world of Azure PaaS

With the release of Sitecore 8.2 Update 1 last week, we finally have support for running our Sitecore solutions as Azure Web App Services without the need for the Sitecore Azure Module. As someone who had never tried a PaaS deployment with the old module, this brings a load of interesting benefits, but also has a few challenges to get your head around. I've spent a bit of time experimenting, and discovered a few things that you might want to read up on before you dive in.

Now updated with a couple of extra links in the text below – And Sitecore's official documentation is appearing too!

What you need to get started url copied!

So, starting at the very beginning, there are two new ways you can fire up an instance of Sitecore on PaaS – via the Azure Marketplace or via an ARM Template.

Creating an instance via the Marketplace is pretty trivial – you just have to find the product for Sitecore in the Marketplace listing (you can search for "Sitecore" or use this link) and then fill in a few fields that you'll be prompted for.

The important thing to remember about the Marketplace approach is that currently there's only one deployment model available – the "XM1" CMS-Only-on-multiple-servers model. That means you don't need an instance of MongoDB to use this approach – but obviously you can't make use of any xDB features.

It's a little more complex to create an instance via the ARM Templates approach – but it's more flexible. You can currently create one of three different deployment models this way:

• XM1 – eXperience Management (Multi server)
  A CMS-Only version with the Content Deployment and Content Management roles split out to separate Web App Services.
• XP1 – eXperience Platform (Multi server)
  An xDB-enabled version of Sitecore with all the roles split out to separate Web App Services. So separate instances for the Content Deployment, Content Management, analytics processing and reporting.
• XP0 – eXperience Platform (Single server)
  The same as XP, but all the roles are on a single Web App Service.

You choose which deployment model you want by your choice of ARM Template files. These are available on GitHub in Sitecore's Azure Quickstart Templates repo. For each of the deployment models above you can download a template and the config file for that template. You need both to set up an instance, and you need to fill in the options in the config file with your required settings.

These scripts describe the infrastructure configuration required, but they don't include the software. To get that you need to go and look at the download page on Sitecore's site. These are available under the "Download options for Azure AppService" heading on the v8.2 update 1 download page. And obviously, you need to get the right version to match the ARM Template you're using.

For a walkthrough of how you can go about installing via these scripts, take a look at this helpful post on ARM installations from Johannes Zijlstra.

It's probably also worth pointing out that you can modify these templates. It's an "advanced user" sort of task, but if you need a deployment that doesn't quite fit with the standard approach then these are the files to start with. Doing stuff like creating a MongoDB instance as part of your deployment can be achieved like this.

Getting going on Azure url copied!

There are a few things you need to remember when you're installing via this route.

The first is that you need to take care of your choices for "where in the world does my stuff get installed?". Azure is broken up into what Microsoft calls "regions". Not all of the Azure features that Sitecore relies upon are available in all regions. So you need to pay attention to where in the world you deploy to. If you try to install to a region that doesn't support all the required features, you'll get errors... At present the Azure Search and Application Insights seem the most likely features to cause challenges here.

Also, as Johannes points out in his post, there's a bug in the ARM Templates at the moment that means the Application Insights is always installed to a specific region rather than the one you choose for everything else in your configuration – however he has a simple fix for this in his post.

One big thing to remember is that Azure installs are asynchronous. Whether you're starting them from the Portal (for a Marketplace install) or from PowerShell (for an ARM Template install), the process of installing will continue in the background after you've submitted your request and had some sort of "OK" response. You need to make sure you remember to wait until everything's finished before you try to use your site.

After you submit an install request, you'll very quickly get all the services appear in your Azure Account:

But if you look at your Resource Group, you'll see it's still busy deploying:

How long it'll keep saying that is very variable – you don't have any control over what's going on in the Azure data centre, and operations like deploying databases and the Sitecore websites seem to take a while. For me it's usually been at least 20 minutes. If you want to find out what it's up to, click the "1 Deploying" link, select the deployment from the list it presents, and scroll all the way down to the bottom of the details of the deployment. Here you'll get a list of all the tasks that were requested, and what each of them is up to:

If they're green, then Azure is done with them and they worked ok. If they're blue then they're still busy. And if they're red something bad went wrong. I've found that installing from the MarketPlace is pretty reliable here, as it tries to validate that you gave sensible answers to its questions – but I've managed to cause all sorts of fun problems with the ARM templates route by getting stuff wrong while I've been learning.

It's worth noting that even if you have some red or some blue icons here, bits of the front-end site may still appear to work. It just won't be very happy under the surface.

But once they all go green, your Resource Group should then say "1 Succeeded" and you can get going.

But what if stuff does go wrong? Well, if your experience is anything like my first few goes, this is an important bit 😉

As far as I can tell, you'll need to delete resources and start again. It's easiest to just delete the Resource Group, as that will tidy up all the resources it contains at the same time. But you can delete just the resources individually if you prefer. Unless you want to customise the templates to do partial installs to put stuff back afterwards, you're going to need to delete them all.

Note that even after you've deleted a resource, Azure seems to remember old names for a while. You should avoid trying to re-install again with the same name.

Stuff you need to think about differently url copied!

The change from the IaaS install model we've been used to for Sitecore to PaaS means a few things we're used to work differently.
(I'm pretty sure this isn't an exhaustive list – it's just what I've had to think about so far)

The first one is how you pay for stuff. The billing model is different for PaaS – and the key thing is that once you spin up an instance via this model it's harder to turn it off. With IaaS VMs that are stopped and deallocated you only pay trivial amounts of money for the disk space they occupy. But some of the resources you need for PaaS can't be treated like that. The Azure SQL databases for example, can only be turned down to lower cost services. Hence this doesn't work so well for installs that you only want to use infrequently. [ Edited to add: Scale-down scripting has appeared already – Rob Habraken has posted an interesting example]

If you want to know how much you're getting charged, you can click the "Resource Costs" option under your Resource Group. Note that this won't tell you anything useful until after a day though as billing costs only update daily.

The second thing is that the PaaS approach uses some different technologies compared to a traditional install of Sitecore. The key things I've seen so far are:

• Your logs got replaced by Application Insights
  This change has been well documented by Johannes as well, so take a look at his post.
• Your databases moved to Azure SQL
  The thing to remember here is that (unless you also spin up an IaaS SQL Server) any custom databases you might want to use in a solution will probably be hosted in Azure SQL too – so you need to think about how that might work differently.
• Your search indexes moved to Azure Search
  In its default state, Lucene has been replaced with Azure's search. In theory, this change should be pretty transparent, since search was already abstracted out, but it does mean that you have a new admin interface for search indexes to learn. Of course it's still possible to reconfigure Sitecore to use an alternative search like Coveo or Solr, but you'll have to do those config changes yourself – and you'll need to host those services somewhere too.
• Your session state storage has moved to Redis

The third place where you have new stuff to think about is your deployments.

If you run a PaaS install with the "everything in a single App Service" model then it appears you can continue to use package deployments the same way you have in the past. (At lest my test of "install PowerShell Extensions and run some scripts" seemed to work ok) But if you use the "multi App Service" model then you need to remember that installing a package will only place the files onto the Content Management website.

But App Services allow file deployments via some new routes. One is Visual Studio's Publishing UI (yet another thing that you can read up on elsewhere). Another alternative is good old FTP connections. Both of these allow you to connect to any of your App Services to push files. [ Edited to add: It seems there's some extra tooling around WebDeploy Packages. Bas Lijten has the lowdown]

If you make use of the scale-out features of App Services, I believe all instances of one Service are sharing the same disk storage under the surface – so even if you're scaled out to "lots of CD Instances", you should only need to deploy files once to the public App Service.

In conclusion url copied!

There's a lot to think about here, and I suspect there's a lot more learning for all of us to do as well. I know I need to find some time to look more closely at deployment, and the ARM Templates themselves. But given the advantages for scaling and deployment automation, this is an important advance for Sitecore.

And surely a SaaS option can't be too far away now? crosses fingers

↑ Back to top