Sitecore recently came with very exciting news regarding their Cloud proposition:

from version 8.2 Update 1 Sitecore will support Azure App Service Web Apps! The current estimation is that this update will come available early November.

In this first blog post on Azure Web Apps I will discuss the differences compared to earlier Cloud options and sketch the outlines of how our new Sitecore Azure environment would look like. Doing so, I will also include other required Azure services like Azure SQL, Azure Search, Redis cache and Application Insights.

In my next blog posts on this topic I will explore the actual proof of concept implementations I will build as soon as the new version becomes available, and I am also planning to set up a demo Continuous Integration process afterwards that runs on Azure Web Apps. Most of the contents of this post is stuff I learned on the Sitecore Symposium and worked out with other Sitecore developers on that event, especially Bas Lijten, who also helped me writing this article. If you have any feedback or additions, please feel free to let me know and chime in!

Web Apps vs. Cloud Services

So, Sitecore (and actually Microsoft too) moves towards Web Apps. Following this change, the existing PaaS-architecture, or Cloud Services option, is no longer supported, nor an ideal or logical solution for going Azure: it is cumbersome to setup (as you’ve seen in my previous blog posts and video), it doesn’t support all modules or features (like WFFM and EXM), and next to that, Cloud Services aren’t scalable well (you need third party services like Cloudmonix to set up auto-scaling and it takes 20 – 45 minutes per instance).

Azure Web Apps, on the other hand, are easy to setup and scale well out-of-the-box. As you probably already know, the scaling feature is a native Azure feature where you can easily configure the minimum and maximum amount of servers. Sitecore will even provide the required packages and ARM templates for each server role (content delivery, content management, processing, et cetera) to initially setup your environment.

An ARM template is a JSON based configuration template that fully defines the configuration of the new App instance to setup. It is parameterized, so you can configure it based on your specific environment, and you’re even able to tailor them to your needs by extending them or linking to additional scripts, to create your own baseline per server type. This makes provisioning new environments extremely easy and accurately reproducible, which is very good news for your Continuous Integration based development and deployment process.

Deployment process & improvements

Another advantage of Web Apps is that you only have to deploy one instance per server role / type. If you need more instances, just scale out! This means the deployment time, and thus the complete cycle time of your CI-process drastically decreases. With Cloud Services, a deployment took 20 to 45 minutes per instance, based on the size of your Cloud Service. Now you can deploy a single instance much faster (I still need to collect actual data on this) and scale up instantaneously.

Note that this scaling strategy works by referencing the same file set for all likewise instances. That’s why scaling out is so quick, but this also means that you cannot have any specific configuration per server within a range of servers of the same server type. So all content delivery servers should have the exact same configuration. I know there are some settings that Sitecore advises to differentiate per server (for reporting purposes i.e.), so this is one of the things I’m going to figure out first in the proof of concept I’m going to do as soon as it becomes available. Probably, Sitecore will find a way to configure this differently for version 8.2 Update 1 (like using the machine name automatically, which should be already possible in this case I reckon).

This deploying once and then scaling out method is also the preferred way to go, since there’s still an issue in Azure with deploying multiple App instances (of the same type) simultaneously. The more instances you deploy at once, the more likely the process is to fail. But as far as I can see that’s not problematic, because there is a big advantage in deploying one instance per server type or role first: you are able to deploy the minimal version of your environment in the staging slot and test it automatically before you swap.

So the process would look like this

• Deploy one instance per server role (one content delivery, one content mangement, one processing, an xDB server et cetera) in a staging slot;
• Automatically test the new version on production within the staging slot. Of course, a performance test would not yet be representative, but functionally you can test everything;
• If succeeded, scale out the different server types to the amount required – this is very fast;
• Now you could run a regressive performance test if you would like;
• Swap the production environment to the new version;
• When everything works as expected, run down the old version (now in the staging slot). Mind that you can still switch back as long as this version is available.

I like this process very much. It promises to be fast and transparent, while being highly predictable at the same time.

Licensing implications

Although it is not imposed by Sitecore, the new consumption based licensing is more or less a requirement for moving to Azure Apps! If you would stick to the server based licensing model, you cannot benefit from the seamless and flexible scaling Apps Services offer, and you would lack the possibility to use the staging slot, because those instance also require separate licenses in the server based model.

The consumption based licensing model is ideal when using Apps, because you can really leverage the full potential of this Azure service without being limited by the available instances within your license. Note that this only concerns the production environment itself, as, to my knowledge, non-production licenses are still being sold as a monthly addition per server, depending on the consumption level you are subscribed to.

Sizing

Together with the different consumption levels the consumption based license model offers, which is based on the number of estimated (unique) visits monthly, Sitecore will probably also provide sizing advise that fits your estimated consumption. So for each level, you will have an indication of the size per instance (like S3, P3 or P4 for example) and the number of instances required to serve the corresponding volumes. Of course, when you have the consumption based license and enabled outscaling, bursting will also be handled well, and you can scale accordingly to your needs afterwards, but this at least gives you guidance on the initial setup. Something that I think fits the new way of thinking (as I see it) of Sitecore very well, in that they give you more guidance in how to use their product, on different levels, like Helix on architecture.

Other services

Azure Redis cache

But there’s more! You may or may not know that Sitecore xDB wasn’t compatible with Redis cache yet, because of the fact that Redis didn’t support the onSessionEnd event, which is required for xDB. Sitecore flushes the session profile towards MongoDB, for persistent storage, upon this event. Lacking the event results in an empty Experience Database. The good news is that from now on, Redis supports the onSessionEnd event and that Sitecore officially supports this caching service as well from version 8.2 Update 1 and up.

Redis cache is very easy to configure and better scalable and better performing than existing alternatives. So now we are no longer tied to SQL Session state or using MongoDB for caching (the latter being a debatable alternative due to not being high transactional like SQL or Redis, but that’s my personal opinion).

Azure Search

Azure Search is a new alternative for implementing indexing and search, next to Lucene and Solr. Azure is easier to configure and should equal (or outperform) Solr in terms of performance and functionality. I think this should be the new search implementation to go for, especially within Azure hosted environments, and even more when using Web Apps opposed to IaaS VM setups. To control the costs that this service generates, and to improve the overall performance, you should only configure and setup the indexes you will actually use.

Azure SQL

The use of Azure SQL databases as a service didn’t change from how you would provision them in the previous Azure implementations for Sitecore. They run and are managed separately as well, and the creation is exactly the same as I showed in my video on how we used the Sitecore PaaS offering using Cloud Services in this blog post.

Application Insights

For monitoring, in his session “Better Together: Sitecore on Azure”, Ciaran McAuliffe showed how the potential of Application Insights can now be leveraged within your Sitecore environment. Although Application Insights is not yet globally available, but only in the Western US region currently, you can already use it to experiment with the extensive monitoring features it offers. In our upcoming demo setup, we will experiment with this and maybe we can setup our environment within a Europe region, while logging to the US. I should note though, that this may impose legal issues when sending actual data outside the Europe region, so be careful with this construction. However, for or early demo and research purposes this isn’t relevant.

A bright future :-)

I can’t wait to start experimenting with this, and as soon as I have any findings or results, I will share them with you. And if you like, please share your thoughts and ideas on this as well. I think together we can create a good set of best practices around this topic, making our lives and our Sitecore deployments way easier and more robust!