Whither PaaS?

With the big news from Symposium being the start of Sitecore's move towards the SaaS market, it's interesting to have a think about what that means for us developers and architects in the medium to long term. Because it seems likely there's going to be quite a bit of change for us...

Moving existing software to a SaaS model is a really interesting software architecture challenge. We're all used to our software being something where we get given a load of files and data, which we can tinker with in order to make it suit our requirements and our preferred infrastructure. Look at any existing Sitecore project and you'll find a pile of patch files that change configuration and DLLs which provide custom logic. So no two deployments of Sitecore are really that alike – and this makes deployment and upgrade into very bespoke tasks. But this really does not work for SaaS...

For software to work at "cloud scale" and to be sold as a service, you need to find a way of splitting out all this custom code and config from the core software. You need to have a "black box" of the core software, which is extended (rather than customised) by each client. This is critical because the vendor of the SaaS platform needs to be able to provision, manage and upgrade every instance they sell in exactly the same way. All that customisation is a deal-breaker – but if every client has one of these "black boxes" they cannot change then the model works. Each of those identical instances of Sitecore can be managed in the same way – and that approach does scale for the cloud.

A few of Sitecore's presentations at Symposium cover how they're approaching this change. They have a two pronged approach: Firstly they are moving to offer proper support for Containers. In effect, these become the "black box" which contains Sitecore. And secondly they're moving new SaaS-friendly development to a model that is very similar to the JSS Headless approach. The Sitecore servers expose some standard data APIs for getting content and rendering data out, and a separate server runs your "front-end" code which uses those APIs to render the pages you want to publish. Initially they're targeting .Net Core for these front ends, but Node will be supported in the future.

So developers have a new pattern to learn for the future. Your "website" becomes the custom .Net Core (or Node) code you host separately to Sitecore. And your integrations have to move outside of the Sitecore instance – probably becoming something like Serverless Functions or API Endpoints you build which Sitecore can call when specific events are triggered. All your custom code now sits outside the "Black Box". There's some very interesting work going on inside Sitecore to make this model a reality – and I've very much looking forward to getting to experiment with it.

But architects are going to have to get used to some new deployment models too. Given the talk about containers becoming a first-class deployment model in the not too distant future, it can't be too long before we're looking at production deployments of Sitecore being based on container orchestration. And to me, that smells like it the beginning of the end of talk of PaaS around Sitecore.

We've been pushed towards PaaS deployment for a while now, since the concept of Consumption Licenses became a thing. If you buy a license which allows you to run as many servers as you need in Production (and get billed by users hitting your site rather than server count) then it makes perfect sense to make use of a deployment technology that has automatic scaling built in. But at the same time that has caused a certain amount of friction. The work for deploying Sitecore is very different depending on whether you're going to use IaaS or PaaS – which means planning your infrastructure requires an understanding of both approaches in order to pick which is right for any client. Wrapping your head around both SIF and ARM deployments, plus Solr and Azure search takes quite a bit of learning.

But with containers, there's a strong argument that there's no need for this distinction. Developer deployments can be a small number of containers running on your development hardware. Maybe one for databases, one for search, one for CMS and perhaps one for analytics? On-premise deployments can be the scaled containers for each role deployed to whatever container orchestration tool a client happens to have deployed onto their own systems. And a cloud deployment can be running those scaled containers in the Azure Kubernetes implementation, or whatever equivalent your preferred cloud provider offers. In theory, if the containers are built with the right options, you should be able to choose easily whether you're running XP or XM from your choice of image, and whether you're using SQL, Mongo, Solr or Azure Search (etc) based on environment variables which tweak configurations. You can get a lot of flexibility from a standard, and more easily supported, set of containers.

Thinking about all this makes me think that PaaS (and traditional IaaS) days are numbered for new deployments. It makes sense for Sitecore to move away from them – and it seems likely our custom code will go the same way, since why have two deployment models when you could have one?

And I'll be honest – I'm not that sad...

Maybe I should have titled this "Wither PaaS!" instead?

Whither : Adverb. To what situation, position, degree, or end.
Wither : Verb. Fall into decay or decline. To lose vitality, force, or freshness.