Sitecore has two concepts known as content management (CM) and content delivery (CD) instances or roles. Each performing a very different role to the other. In a nutshell, it’s the idea that one role is used for creating, maintaining and managing content, and the other is purely used to deliver the content to the end user.
Sitecore is designed to be a scaled platform with clear separation of content management to content delivery. It allows for content management to be done in isolation, providing a secure environment to work in.
Now let’s deep dive in to these roles.
What is Sitecore content management?
Sitecore’s content management environment is the “world of content editing”. It’s purely for content editors to access, create, amend and update content for their website. Editors can login into the “Sitecore dashboard” of Sitecore Experience Platform which provides a number of options, dependent on the editor’s role. Ultimately the “content editor” is what would be accessed to manage content changes:
The content management environment and dashboard is typically locked down to the customers’ internal network so that outside access is denied. This is from a security point of view, to prevent someone attempting to gain access to the content management interface, where they could sabotage the content on your website and ultimately publish it.
Given the power that Sitecore harnesses, the “content management” instance is more than just a place to edit content. It’s where content editors can really utilise all of Sitecore’s features to get the best out of the platform.
Not only can they manage the content but they can:
Working with the “master” database
If you’re wondering how it’s possible to create and edit content without it being visible to the public, then this is a high level overview, call it Sitecore 101 on databases.
There are a number of databases that all perform different roles. In this case we will focus on the one around content editing. The content management instance makes use of the “master” database.
The “master” database is the master repository of content, where all content editors will be making their changes. As long as your instance is configured correctly, “versioning” should be used by content editors. This allows the tracking of changes to be managed through versions of an item. Without versioning, content simply gets overwritten and should you need to look historically at what a piece of content was, you would not be able to do so.
All content changes get stored in the “master” database and they will go through (providing your Sitecore instance is configured correctly) various stages of workflow prior to being “allowed” to be published. Once all stages of workflow have been approved, the latest version of an item will be published. This replaces the previous version, although the previous version will still be accessible in the content editor to view, as shown in the below screenshot.
In this case, you can see on the right hand side “9”, this is the number of versions of the “About us” item. The content editor is free to look at earlier versions.
In the “yellow” warning message, it's telling the editor that the version being worked on is “version 9” and is not in a “publishable” state. This is because it has not gone through workflow, therefore if the editor publishes this item, version 8 will actually be published. Demonstrating a good practice of using versioning and workflow.
What is Sitecore content delivery?
The content delivery role, server, instance is one that the end users can see, and delivers the live website. When a user is viewing a website, that site is being surfaced via the content delivery instance.
Content delivery instances only display published content. So when a content editor has finalised their piece of content and its gone through the various stages of workflow, they make it “live”. The process for this is very straight forward, they’re presented with an option to “publish” the content. In doing so, behind the scenes, that piece of content moves from the “master” databases to the “web” database. Once it arrives in the web databases, it is live and available for the world to see.
A content delivery server only connects to the “web” database for content, it does not have access to the “master” database.
An application can have multiple content delivery servers to manage high traffic coming to a website. Most of the applications we build have a minimum of two content delivery servers. They’re fronted with a load balancer which effectively distributes traffic between the two content delivery servers, which manages the performance of the application by not overloading it with traffic. This could cause performance degradation.
How can enterprises differentiate Sitecore Content Management vs Content Delivery?
It’s quite difficult to differentiate unless you have access to the infrastructure itself, however, you might get a clue by simply going to your live domain and appending ‘/sitecore’ to the end of the url.
In a true content delivery environment, you would be presented with a “page not found” or restricted access message of sorts. However, if you are presented with a Sitecore login screen, this could mean one of a few things:
Due to there being a number of ways to architect a Sitecore environment, dependent on the scale of your application, there are applications which run on a single instance. You should still try and ensure the admin area is locked down to a restricted IP range.
How can Sitecore help me?
The delivery environment can manage any amount of traffic thrown at it. If your application can’t handle the traffic, it’s easy enough to add additional content delivery instances into the mix, which allows the distribution of traffic between instances. This ensures the user experience is not impacted.
UNRVLD is a leading Sitecore partner with over 20 years’ experience, designing, building and optimising website solutions for enterprises. If you’d like to explore Sitecore Content Management vs Content delivery further and the information in this article rings true to your organisation – let’s talk.