A first look at the Sitecore demo portal

If you're part of the Sitecore Partner or MVP community then you probably watched some of the content from their "Global Sales Kick-off" recently. They talked about product roadmap and strategy stuff for the coming year, especially the new XM Cloud product. But something else which Dave O'Flanagan called out in his session is of interest to us in the community too: Sitecore's new internal demo portal.

The need to spin up a demo instance of Sitecore has been a common challenge for me over the time I've worked with the product. There have been various ways to do this - some very manual, and some involving a bit more automation. Different organisations and people all had their own approaches to how best to do this - but it's now being looked at centrally. I was lucky enough to get a sneak-peak of their new approach to this problem. And now it's been launched it seemed like something worth writing up, to make more Partners and MVPs aware of the tools at their disposal.

Internally, Sitecore's Demo Team have been dealing with the "how to we deploy and manage demos" problem at scale, and they've built up an interesting response based on Kubernetes automation as a result. The management portal that's come out of this in is an cool piece of technology - with some fascinating parallels to Sitecore's (not related) XM Cloud product.

What is it? url copied!

The bigger your need to run demo instances, the more sense it makes to invest in the best automation you can to reduce the challenges of deploying the sites you require. So Sitecore's demo team have worked to leverage modern deployment techniques to make this as simple as possible for themselves. The system is a set of automations based on Kubernetes, Git and Sitecore's developer tooling patterns. Its goal is to allow the simplest possible approach to spinning up examples of their standard demo sites.

Since I've been working with Sitecore (starting a decade ago, around v6.4) there have been a series of changes which have helped to raise the level of abstraction for how you host and deploy their software. This tooling is continuing that trend.

Back in the day, you had to provision servers to run a Sitecore instance yourself. It might have been physical boxes you ordered for your office's server room, or it might have been some of IaaS virtual machines in somebody else's data centre. But either way, you were worrying about the setup at the O/S level initially before moving on to adding Sitecore and SQL Server to the mix, and then deploying your custom code. And once it was running all the effort of maintaining and patching it fell on your shoulders too.

But around v9 the use of PaaS became more common - abstracting away the O/S and its patching needs, so that you just had to worry about the SQL Databases and IIS Sites aspect of your deployment. So patching and configuring the physical server underneath was no longer your problem. You only need to worry about configuring the ARM templates to set your infrastructure up for you, and then deploying your custom code.

And with the recent adoption of containers and composable SaaS-hosted products, Sitecore have the opportunity to take another step of abstraction. This portal is providing an approach where you worry about what Sitecore instances you need, and what code you want to deploy onto them, but all of the processes for getting that infrastructure in place, wiring systems up and getting the base Sitecore instance running can be hidden from you now. The bar for abstraction has risen above IIS and SQL, and up to your demo Sitecore site.

So you get to focus on the content and the features of your site, and ignore all the hassles of installation. And as someone who's spent a career fighting obscure "works on this machine!" issues, this is a really appealing idea...

There are strong parallels between this piece of work and the new XM Cloud product that Sitecore have recently started marketing. They both rely on similar patterns of containerisation and git-based automation. But a key difference is that XM Cloud is aimed at public websites and "normal" Sitecore users. Whereas this tooling is aimed at the sales need for easy to create, but short-lived demo sites. The future probably sees these two approaches aligning on the same technology stack eventually - but it's not there right now.

What does all this look like? url copied!

Well, it's a web portal, so if you're granted access you can log on to the site using the same SSO credentials you use for other Sitecore properties like the Support or Learning sites. And once you've done that you get a list of the instances you've currently got deployed:

By default the list shows each of the instances that you own, but you can also get a view of all the instances that you have any access to, as you can be invited to collaborate on an instance that you didn't create too.

There's a "Quick Deploy" button here, which lets you fire up a new instance:

For the moment there's a choice of three of Sitecore's demo websites you can deploy from here. But the underlying infrastructure of can (in theory) be used with any headless-focused Sitecore code. And when you pick a demo to start from it asks some fairly simple questions:

When you pick a base project you get to name your instance, you get to pick a Sitecore version, and you can pick which Azure Region you want your resources to run in. There is some further detail you can configure here, if you click the "customise" button. That expands out the wizard view to a more detailed form giving you some extra choices - starting with integrations:

The options here can vary with the particular demo you're deploying. Above is from the more complex "Play! Summit" example. The ability to provision Content Hub or CDP/Personalize instances as part of your site setup makes perfect sense - those are other Sitecore products which have a fairly SaaS-friendly delivery model already. In the future I expect we'll see options for all of Sitecore's composable product suite here. It makes a lot of sense that you'd want to be able to provision demos which relate to all of the product suite. Similarly, provisioning Vercel as a host for your Next.js based Headless sites is pretty self-explanatory - Sitecore have a partnership here and it fits the headless model well.

The other option here is to connect the system to your own git repository. (Currently limited to GitHub - but I expect to see other providers like Azure DevOps here too, eventually) If you select this, Sitecore's demo code can be cloned to your source control, and that gets used as the source for releases. So you'd be able to customise the code, if you have a need for a demo that's modified to suit a specific customer or sales opportunity.

For demo and test instances, it's might also be important to you to reduce running costs by having your site turn off on a schedule. There are UI options for this too:

Since all of this runs on cloud resources provisioned by Sitecore, all the storage and compute power used by each site has to be paid for somehow. And the more sites they have to run, the bigger that challenge becomes - An organisation of Sitecore's scale is likely dealing with a lot. So turning off sites overnight and when they're not in use can help reduce those fees, and keep the provisioning more affordable.

But once you fill in all these options and make your choices, you can click "Deploy" button to fire off the release process. That will take you to the details page for your new release:

There's a lot going on here. Top left, "Important Links" is a list of all the URLs relevant for your deployment. Since this has only justs started, there's nothing here yet, other than some usernames (and the ability to grab passwords) for key users in your system. The links appear once the systems running them have been provisioned. Below that, the "Members" show which portal users have access to this deployment. And below that there's data about the demo license you have been granted to run the site, and the Experience Edge endpoints your site is using.

In the right column there's data about the options for the deployment under "Instance details", plus the ability to manually start and stop your site, or delete it if you're done with it. There's also the "View Deployment Details" button, which will take you to the details and progress screen for the deployment:

This shows you each of the deployment steps required to achieve your release. The list of things here will vary depending on the requirements of your particular demo repository. And as you'd expect for a release process, it works roughly from top to bottom, turning the rows green as each automated step gets sorted out for you. At its simplest, you can see above here it's providing a temporary license, some DNS entries, the Experience Edge endpoint I mentioned above, plus the containers required for the core CMS.

If you pick a more complex demo, with other integrations, you can see that the list of steps gets longer. Here it's also provisioning Vercel for the headless "head" and Content Hub integrations for content and image management:

And you're able to select individual steps if you want to see more detail of what's happening:

And once the steps are all complete, the relevant links for your site will appear on the details page, so you can click through to them easily. This example provided some Vercel-hosted websites, an instance of Horizon and the standard XM CMS instance:

It takes minutes to provision a new site - though the time is dependent on the set of resources being provisoned, and there's probably a factor for how busy the underlying infrastructure in Azure is. While playing I've seen times around five to twenty minutes. And once it's done you're free to log in to the instances created, to do your work. In the Content Editor, for example:

Or in Horizon or other tools deployed as part of this setup:

And of course you can browse the public sites too. But once you're done with your instance, you can click the "delete" button to tidy up all the resources that were allocated during deployment:

First impressions url copied!

Having had a weekend to have a tinker with this, I think it's a great step forward for the provision of Sitecore instances. It brings speed and simplicity to demo infrastructure for partner organisations, MVPs and Sitecore's own staff. And I think it shows off some of the power of container automation, along side the new world of composable systems and Sitecore's work on demo websites. It's a provisioning system which is usable by people with little technical knowledge, so it's giving sales and marketing staff a lot of power to organise demos "on demand" for their engagements with clients and other events. That "help, I've got a demo in two hours and I don't have a site to show off!" email that I used to dread receiving should be a thing of the past...

The more complex instance provisioned above is the "Play Summit!" demo provided by Sitecore. This is open-source, and you can take a look at the overall code for the site if that's your thing. That repository shows what the code for the websites looks like, plus what the configuration for container-based execution too. There are a lot of moving parts to this demo - so there's lots to learn here about how it's all brought together. Plenty of interesting stuff for anyone who's more technically focused.

The ability to build up a custom Sitecore solution (like these demos) and have it work with an effective automatic provisioning system is really helpful - but it's also going to become more of our day-to-day development life once the new XM Cloud product gets it's full general release. While that's not the same thing as is being used here, the parallels are significant. And this model of "abstracting away much more of the infrastructure" is key to both these approaches. We're not too far from a position where devs, tech leads and architects spend less project time worrying about what infrastructure a site requires. The various cloud hosting technologies we can now employ can abstract that away for both the back-end code (Azure Functions, XM Cloud for example) and the front-end (e.g. Vercel).

For me, however, the key thing right now is how the demo portal can simplify my work: Reducing the up-front effort needed to deploy infrastructure for a Sitecore demo website, and enabling sales and marketing staff to self-manage demo instances without technical help.

Between this and XM Cloud, it's exciting times to be a Sitecore architect...

↑ Back to top