Main Image

Part 1 - Sitecore® Experience Platform™: Production Hosting

In this series of blog posts I’ll talk about how we approach Sitecore® Experience Platform™ 8 production hosting at Cucumber. As this is a large topic I’ve decided to split it into bite-sized chunks for easier digestion.

Part 1 - Production Hosting
This post will outline the kinds of things that you should be considering when planning your production deployment of the Sitecore® Experience Platform™

Part 2 - Sitecore 7.x
A look a back at how things were done before the release of version 8 and the problems that version 8 addresses.

Part 3 - MongoDB
An introduction to the MongoDB NoSQL database and some of the things you should know about hosting it in production.

Part 4 - Sitecore 8.x Standalone
A description of the minimal infrastructure required to host the Sitecore® Experience Platform™ in production based on Sitecore best practices.

Part 5 - Sitecore 8.x High Availability
This post will show an approach to achieving high availability with the Sitecore® Experience Platform™.

Part 6 - Solr
An introduction to Solr, an open source enterprise search platform used by the Sitecore® Experience Platform™.

Part 7 - Sitecore 8.x xDB Cloud
Sitecore’s xDB cloud edition introduction and current status.

Part 8 - Sitecore 8.x Hybrid Architecture
Designing a hybrid architecture using SaaS offerings.

Part 9 - Sitecore 8.x How to Choose an Architecture
The Cucumber approach to designing Sitecore® Experience Platform™ 8 production infrastructure.

As previously mentioned this post will outline the kinds of things that you should be considering when planning your production deployment of the Sitecore® Experience Platform™. These topics are generally applicable to hosting production websites but are mentioned because they help to inform the architectural decisions that need to be made when designing your production Sitecore® Experience Platform™ infrastructure.

High Availability
High availability (HA) refers to the ability for a system to be continuously operational even in the event of failure measured relative to being 100% operational. A widely-held but difficult-to-achieve standard of availability for a system or product is known as "five 9s" (99.999%) availability. When planning for high availability, the first step is typically the identification and elimination of any single points of failure. A single point of failure (SPOF) is a part of a system that, if it fails, will stop the entire system from working. SPOFs are undesirable in any system with a goal of high availability or reliability, be it a business practice, software application, or other industrial system. This is followed by implementing effective failover in the event of failure.

When designing the production infrastructure to host your website you need to consider how it will scale when it becomes wildly popular . There are typically two options available; horizontal and vertical scaling.

Vertical Scaling
Vertical scaling involves increasing the resources available to your existing servers but not increasing the overall number of servers in the configuration. The resources that can be increased are typically IOPS (Input/Output Operations Per Second), CPU, RAM and storage capacity. An advantage of vertical scaling, particularly when using virtualisation is that it’s relatively trivial to scale up without adding any additional deployment or configuration changes. However, it will often require a machine restart to take advantage of the added capacity. The downside is that this approach is limited by the amount of available resources the underlying hardware can provide. It also contributes nothing towards achieving high availability or zero downtime deployments.

Horizontal Scaling
In contrast to vertical scaling, horizontal scaling does involve increasing the overall number of servers to increase capacity. This type of configuration is typically called clustering where all of the members work together as a single logical unit. Adding machines helps to eliminate single points of failure, providing high availability. Generally speaking, capacity can be added or removed on the fly without any interruption to delivery. In theory this approach is only limited by the number of members that can be successfully connected to the cluster. Zero downtime deployments can be achieved by temporarily removing a member from the cluster and deploying any changes before adding it back.

As modern applications evolve to become more distributed in nature and complex to manage, the need to monitor each component effectively increases. We recommend using one of the main commercial products that provide detailed application level monitoring. The most popular solutions are New Relic, AppDynamics and Application Insights (only available on Azure). All of these products offer granular insights into application performance and can pinpoint errors to specific lines of code. 
Sitecore log monitoring alongside application monitoring can provide useful insights into the health of the installation. It is very common to see production servers with issues visible in the log files that haven’t been picked up on. There are commercial and open source solutions available for shipping and analysing log files to allow advanced search and filtering across the log levels that your application is configured to output.


Some description

Splunk is a commercial tool that allows you to search, monitor and analyse any machine data for powerful new insights. It’s available as a self hosted enterprise version and via a SaaS model. Sitecore uses the log4net library for logging, which can be configured to send logs to Splunk for analysis and alerting.

Elasticsearch, Logstash, and Kibana (ELK)

Some description

The ELK stack can be thought of as an open source version of Splunk. It provides integration with the Sitecore logging system via Logstash to ingest logs into Elasticsearch. It may sound weird to put logs into an enterprise search solution but Elasticsearch includes powerful aggregation capabilities, which the Kibana dashboard is built on top of, providing advanced data visualisations.

In this post I introduced some of things we consider when planning a production Sitecore® Experience Platform™ 8 installation in order to set the scene for the following posts. In the next post I’ll talk about how things were done prior to version 8 to help understand the reasons for the changes and the added complexity. If your ready to embark on a new digital project or need help with an exisiting Sitecore website, contact Cucumber today... | 0800Cucumber