Main Image

Part 2 - Sitecore 7.x: a look back at how things were done before the release of version 8.

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 outlines 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 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.

Introduction
In the previous blog post I introduced the kinds of things that you should be considering when planning your production deployment of the Sitecore® Experience Platform™. In this blog post I want to take a bit of a look back at some of the reasons why the platform has changed from version 7.x before moving on to introduce the new architecture.

Some description

This diagram shows what a typical 7.x installation of Sitecore looked like. Authoring and delivery are split apart and multiple delivery servers provide scalability, high availability and the ability to deliver zero downtime deployments. The core and web databases are shared between the CM and CD servers and the analytics database is housed on a dedicated server. This is done for scalability reasons because this was the hardest part to scale. High availability of all databases except analytics was achieved through mirroring, which was deprecated in SQL Server 2012 in favour of AlwaysOn availability groups.

Each new version of Sitecore brings a wealth of new features and to support that the architecture is becoming increasingly complicated.

The problem
As I mentioned earlier, the problem with the Sitecore 7.x architecture on higher traffic sites was that the analytics database became a performance bottleneck. The main reason for this was that it had to deliver high performance under a mixed workload. Fast writes were required in order to keep request times low as event data was being persisted. At the same time, fast reads were required to keep the behind-the-scenes user interfaces responsive. Any custom code that queried historical data for personalisation or other purposes such as to display page views only compounded the problem.

Some description

Indexes are essential in keeping reads fast, especially as the volume of data grows and table scans become increasingly expensive. The Sitecore 7.x analytics database was no exception to this rule. The problem is that maintaining indexes slows down writes.

It is possible to design SQL Server architectures that can scale to handle these types of challenges and more. However, this can become expensive in terms of skills, hardware and licensing. Additionally, many people don’t have the skills or feel comfortable deviating from the vendor’s recommended architecture.

Sitecore 7.5+
With the release of Sitecore 7.5 (shortly before the 8.0 release) the architecture was changed to address this issue. Sitecore Experience Database xDB, backed by the NoSQL database, MongoDB was added in order to split the analytics read and write workloads. MongoDB became responsible for data collection (writes) and a new aggregation framework based on the MapReduce pattern was added to process data before inserting it into SQL Server for reporting (reads). Separating processing out, enabled it to be scaled horizontally by adding more servers.

This made MongoDB a requirement for a Sitecore® Experience Platform™ 8 installation, a change which introduced a non-Microsoft technology into the Sitecore stack. MongoDB is easy to get started with, but gets more complex as production considerations are taken into account.

Some description

Conclusion
In this post we took a brief look back at the previous versions of Sitecore in order to understand the motivation behind the architectural changes introduced with the Sitecore® Experience Platform™ 8. This helps set the scene for the next post in which I’ll introduce MongoDB and talk about some of the options for running it in production.

For more infomation on Sitecore or if your ready to embark on a new digital project, contact Cucumber today