Skip to content Skip to footer

Sitecore on Azure

Sitecore Hosting Configuration for Microsoft Azure

Hosting the Sitecore Experience Cloud on Microsoft Azure gives many benefits including, transparency, scalability and time savings.

However, to successful deploy Sitecore on Azure then experience is needed. For organisations that own Sitecore, it’s likely that any installation will be a one-off. Getting up to speed and taking responsibility in-house, could be unnecessary up-skilling. Hence, partners like Redweb are invaluable to step in, making the process easy and seamless.

As a Sitecore Gold Partner, Microsoft Cloud Service Provider (CSP) and Cloud Platform Gold Partner, we’re ideally placed to assist you with your requirements.

It is all about the apps

Redweb install Sitecore using Azure apps. This gives a Pay-As-You-Go model allowing scaling and tailoring as needed. Apps can be split into 2 things, App Services and App Plans.

The App Service is easy to understand, it’s the actual instance of your web application, it’s where you deploy your code, set up SSL certificates and connections. The App Plan is like an envelope or container for your App Service/s. It is used to determine the resources available to your application and their boundaries, hence it sets the price range you’ll pay.

In the old Sitecore hosting world, we had only a minimal number of servers to consider. It was “how many Content Delivery servers do we need to our one Content Management box”. Many people even ran them off one machine.

In Azure PaaS this thinking has been completely reshaped. In what is much a response to dealing with the increased demands of XP, the architecture is blown apart and now all the predominant functions each sit on an separate app.

Hence, the architecture diagram has got more complex, but for engineers it means greater transparency as capacity and diagnosis becomes more granular. This new approach does have a bearing on price, with architects balancing the decision of “small capacity yet more instances” v “less instances with larger capacity”.

Redweb’s favoured configuration splits the structure down to 7 distinct purposes, each powered as need be, but with the minimum requirement of being at least 1 app instance.

Content Delivery

Content Management

Processing

Reporting

Identity

Solr Search

Cortex Reporting, Marketing Operations, Marketing Reporting and XC Search

Cortex Processing, XC Collect and XC Ref Data

The 7 instances are then arranged across 4 App Service Plans as shown in the diagram below.

Diagram as PDF

Power and scaling options

Whilst the majority of the apps can exist as a single entity for the Content Delivery function, hosting on Azure apps allows increased flexibility. It introduces the concept of scale-up and scale-out.

Scale-up is similar to the old mindset of buying a bigger server. You can increase or decrease the capacity of the app on things like RAM or storage. Within different tiers the apps have codes such as B1, S1, P1v2, P2v2, relating to a set specifications. When configuring a Sitecore environment, getting the correct size for each app is important when managing the overall costs. More information on the breadth and individual cost of each Azure instance option is here.

The flexibility of Azure is that these can be changed on the fly. So carefully review after go live will allow any necessary optimisation. However, like traditional hosting the capacity needs to cater for peak times so care should be taken. The process of scaling-up/down is a manual process.

With scaling-out you are increasing the capacity of the app by duplicating the number of host instances. Those duplicates need to remain the same instance type as the parent. Namely, you scale out an S1 to be 2/3/4 S1s.

One thing to note, is a scaled-out instance isn’t the same as 2 separate servers other than in capacity. Scaling out on Azure doesn’t create 2 separate entities that could be individually altered and no external load balancing is required. It creates a perfect immutable clone with traffic configuration dealt with by the platform.

Scaling-out has one major advantage in that auto-scaling can be set. This happens without interruption as new resources are provisioned. Scaling can be performed on a schedule, or based on a runtime metric, such as CPU or memory usage. Examples:

  • Scale out to X instances on weekdays, and scale down on Saturday and Sunday.
  • Scale out by 1 instance if average CPU usage is above 70%, and scale in by one instance if CPU usage falls below 50%.

So when setting up a Sitecore environment and in particular the content delivery function, you must decide the number of servers, the capacity of those servers and any scaling capacity requirements.

For Redweb, we generally set only 1 server at P2v2 for CD and run it at 2 instances by default. We then allow auto-scaling to a limit of 5, to cope with high volume periods. So our customer’s base cost is the same as 2 instances but has the peace of mind that performance isn’t compromised.

This approach makes good sense but for many clients not defining the exact cost can be troublesome. A procurement exercise needing a fixed price will struggle with the unknown. Will it be £450 a month or over £1,000 a month? At Redweb, we try to talk about hosting as a utility!

SQL Databases

As with apps the number of SQL databases needed to host SItecore in Azure has also increased. We count 16 SQL databases in a production environment.

Databases again are provisioned based on a specification and alter based on the load and Sitecore features enabled on the platform. We typically know what tier and capacity for launch, then make adjustments, once the site goes live. This is as much for cost management as performance.

Other Items

As well as apps and databases the environment will also require an Application Gateway. We typically set them to scale against traffic demand. Application Gateways in Azure offer a host of features as discussed here.

Finally, Sitecore also requires an Azure Cache for Redis which is used as a session store.

Environments

In addition to the Live environment, you will also need a UAT and ideally a QA environment to develop and improve the solution.

For UAT, it is best to get as close to the live environment structure as possible. This ensures any testing is representational of the final deployment. However, specifications can be lowered and scaling is not necessary.

For QA the aim is have a separate functioning version of Sitecore, so we aim to create the most cost effective configuration we can.

Our Tier-1 backing from Microsoft

By choosing Redweb, you’ll not only benefit from our extensive experience in Sitecore, but also our expertise and relationship with Microsoft. As a Microsoft Cloud Platform Gold partner and Tier-1 Cloud Solution Provider.

As a Tier-1 partner we have a direct line to Microsoft, with priority access to Microsoft support to assist us in supporting and maximising the platform for our clients – whatever your requirements, we have a wealth of expertise on hand.

Our Azure pricing is the same as going direct to Microsoft but you get the peace-of-mind of having the expertise by your side.

See also

Powering your Sitecore platform on Microsoft Azure

Redweb

Contact us now about your Sitecore hosting on Azure

Find out about the benefits of partnering with Redweb as your Cloud Solution Provider for Sitecore.

By entering my details, I agree to the use and storage of my data as described in Redweb’s privacy policy.