Reading time: 9 min read
What Is Sitecore XM Cloud? (Updated)
What we know about Sitecore's new headless SaaS offering
Start typing to search...
Sitecore XM Cloud has officially been released. It’s latest offering from Sitecore, a proper next-generation SaaS-based headless platform, built for the enterprise.
This article was originally posted in July 2022 prior to the release of XM Cloud. Since its release, this article has been updated for accuracy.
In the dark ages we had SaaB (Software as a Burden). Sitecore shifted away from this many years ago, adopting a PaaS (Platform as a Service) model, and today Sitecore has shifted further still into Software as a Service (SaaS).
But what is Software as a Service?
"Software as a service (SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. SaaS is also known as "on-demand software" and Web-based/Web-hosted software.”
- Salesforce.com
The switch to a SaaS model has numerous benefits:
Leaving big lift-and-shift upgrades behind and being replaced with automatic, frequent seamless incremental upgrades will be a huge shift for Sitecore.
Being a headless CMS platform just makes the most sense and Sitecore has already indicated that this is what we're getting. A headless CMS creates a clean separation of responsibilities between the SaaS CMS platform (Sitecore) and the website consuming the content via services (You).
It's very difficult to imagine traditional content delivery servers with their essentially infinite customizations (your website) and compiled code being viable in a SaaS model.
In lower-end headless CMS platforms such as Contentful or Kentico Kontent you can see that they shy away completely from controlling the "content delivery" servers and instead focus on content modelling and APIs.
Sitecore's existing Headless Services are extremely powerful, and I believe with XM Cloud leveraging these services, it is poised to push the limits of what a headless CMS can do.
Sitecore Headless Services has two primary aspects for accessing data: Layout Service & GraphQL. The Layout Service allows sophisticated pages created by authors using Experience Editor (basically infinite possibilities) to be returned in a headless format. GraphQL allows content to be queried at a more granular level (i.e. 5 press releases, tagged with 'investment') in a headless format.
With the separation of CMS and the front-end, I expect we'll be using these services exclusively.
From a feature perspective, Sitecore XM Cloud is an entirely new product, and at this stage, we don't know exactly what it will offer. But that said, as a baseline expect something akin to what we're getting with Sitecore XM (Experience Manager), not Sitecore XP. We've outlined the differences between Sitecore XM vs XP here in quite a lot of detail here.
Sitecore has composable SaaS solutions in Sitecore Personalize & Sitecore CDP that will fill in the gap and do a lot to enhance capabilities beyond the traditional XP offerings.
We'll no longer have traditional content delivery servers running Sitecore. As we've said, being headless there is no longer any ASP.NET Sitecore in the front-end. We'll basically have a front-end consuming the data from a headless CMS. I'll call this our Front-End Delivery Server (FEDS). Usually, this server would be running a JavaScript-based web framework like Next.js to render the site.
One thing to consider is if your content delivery servers were doing any sort of additional processing, customizations, proxying API calls, etc. you'll need to be prepared to retool around that.
As we migrate to a SaaS platform, it goes without saying that we're all hoping to enjoy a simpler process around upgrades. I imagine some migrations will involve no effort while others still may involve some critical evaluation - but overall much less work.
It's a basic give and take - the more we can customize, the less automatic I'd expect upgrades to be. So it will all be about finding that balance.
It's also very worth acknowledging that tools like Sitecore CDP, Sitecore Personalize & Sitecore Content Hub are already SaaS platforms where incremental and major upgrades are happening. So those are major parts of the potential SaaS stack that are already being handled.
Additionally, being headless and having the separation of the Front-End Delivery Server from Sitecore XM, you can see a path to simpler upgrades because XM and your front-end can be upgraded independently from each other.
Next.js is the go-to front-end framework for Sitecore XM Cloud. Being headless, you could use anything to query Sitecore and display the data. But Next.js is the latest and greatest web framework that Sitecore actively supports.
Sitecore's presentations regarding XM Cloud and modernizing tech stacks frequently reference Next.js and refer to its features such as static site generation (SSG) and server-side rendering (SSR). Next.js is based on React - which there is already lots of support for. Sitecore has forged a partnership with Vercel - the creators of Next.js - for hosting Next.js based sites.
Even if you're not thinking of XM Cloud, shifting your web stack to use Next.js has lots of benefits.
The preeminent languages for XM Cloud development are C# & JavaScript. JavaScript is very loaded term in this context. We can unpack from JavaScript to TypeScript. Then expand that to look at front-end framework languages like React. Then go from React to entire development platform like Next.js.
Being headless, you can build front-ends on any platform and consume data from XM Cloud. But you won’t realize the full feature set of functionality like in-page editing, drag-and-drop features, personalization, Sitecore Components unless you use a supported Headless Service library.
Headless Services has a library for React. So you can use React without Next.js. I’m not sure there’d be a strong case for it, but could do that.
Initially it seemed that .NET based customizations (deploying custom configurations and custom DLLs) would not be supported by the platform but they are supported. So go wild. I guess? I would ensure that any changes are built, serialized and integrated into your automated deployments.
To future proof, I’d still be hesitant about doing too many customizations that but I think that is prudent advice regardless.
There are going to be two pipelines for deployments to consider.
Each have their own independent managed release pipeline. Below is a video released by Sitecore showing the XM Cloud deploy (it was in preview). If you’re using Vercel, Netlify or rolling your own front-end delivery, they’ll of course be slightly different depending on the tool.
Experience Edge as a critical part of the of the XM Cloud stack. It’s part of every environment. Experience Edge has been available for some time and we've used across projects dating back to 2022.
Instead of a live database, this is where your content is published to. This is always what is queried by your front-end to retrieve your content.
I think of of Experience Edge as a high-performance, interactive proxy layer used to access your content. What’s really nice about it, is you can think of it as an API, where you can make GraphQL queries and get the data you need.
We query Sitecore Headless services instead of Experience Edge when developing locally. In terms of accessing data, they’re virtually identical (although their architecture, performance, etc are different).
Querying Experience Edge replaces previous use cases for Content Search.
Sitecore CLI is used as the primary way of serialization. It’s integrated into the deployment process. I would abandon all other forms of serialization across Sitecore projects. If you’re using the SXA Starter Kit, it’s used almost immediately to synchronize content from your XM Cloud instance down to your local environment.
There are two main ways of setting XM Cloud development environments. You can add it to clean install (or an existing Sitecore 10 environment) or use docker-based SXA Starter project.
There is no parity between environments. And XM Cloud is a SaaS platform, some features such as personalization, Experience Edge and Sitecore Components are not available locally.
You will have a local Sitecore instance (CM), Headless Services installed into Sitecore (which when accessed via GraphQL is representative Experience Edge) and a Next.js project running (roughly equivalent to Vercel or Netlify).
When creating a site on XM Cloud, a new version of Headless Sitecore SXA is installed by default, and is the recommended way to create sites.
Because it’s headless, we’re building the JSON renderings that return data structures. The HTML and functionality of the components exist in your Next.js project (similar to headless development before).
In previous versions of SXA (non-headless), you could model the data and control how it was rendered. Being headless, there is a cleaner separation.
As Headless SXA is less opinionated, but it also comes with a useful collection of components:
There is a very cool piece of new functionality called Sitecore Components. Its a foray by Sitecore into creating a Front-End As A Service offering and allows components to be created within a visual interface, connect to content stored outside of Sitecore and be added into Sitecore as those they were a standard SXA component.
I’ve written a separate overview of Sitecore Components in XM Cloud. Take a look.
Sitecore XM is an absolutely rock-solid CMS platform. And the idea that an organization could leverage it as a SaaS product, used in concert with Sitecore's Headless Services, Headless SXA and additional features like Sitecore Components is a huge step forward within the CMS space.
As indicated above, this article was originally published in July 2022. Since then XM Cloud has been released and we’ve been able to shift from informed speculation to facts. It’s a very exciting time to be in the Sitecore ecosystem.
As of January 2023 we are actively working on multiple XM Cloud projects and would love share even more. If you have any questions or think we could help please reach out, ask me for, let’s chat. Thank you for reading!
