Why the new Sitecore on .NET is great

As I have written earlier – Sitecore has begun the journey towards the new Microsoft .NET Core platform. The Publishing Service was the start – and Sitecore Commerce have moved Sitecore towards this new architecture.

I expect the upcoming release of Sitecore 9 to be even another step towards the .NET core platform. From my technology heart, I appreciate the effort Sitecore does to drive the transition to a more modern platform – but as a consultant, delivering advise as well as solutions to our clients I actually like it even more.

In this article, I will give you some of the main reasons that I see and why I appreciate this. It is a good mix of technology driven business reasons – for those of you who know me, that fits me pretty well. I like the possibilities of technology – but there needs to be a driving force and reasoning behind technology decisions – pure technology alone is not enough for driving changes like this.

For me – it is actually not .NET core (and the advantages this brings for heterogenous platforms as well as a number of other things) – but for me it is actually the microservice architecture that I find the most interesting.

Sitecore has always been about extensibility, plug-ability and giving the solution providers like ourselves the possibilities to extend and change what we need. We have had that for a long time in the pipeline, event-driven, component-based architecture – with a lot of options for overriding the platform. Leveraging Inversion of Control (the possibility to change the actual implemented behavior of a component without letting the users of the component know that it is changed) has always been important – and this is only extended in the microservice architecture. So – I will highlight three different reasons for why I like the new Sitecore architecture:

Evolutionary architectural principles
Service switching for advanced, functional A/B testing
Granular scalability

"EVOLUTIONARY ARCHITECTURE PRINCIPLES" - WHICH MICROSERVICES

First of is a principle very important to me – the ability to cater for change. Most of the projects we do have an extended lifetime of many years – which means you need to be able to cater for change and evolution. I am very fund of the “Evolutionary Architecture principles” – which microservices to a great extend supports. I urge you to read the blog entry of ThoughtWorks CTO, Rebecca Parsons and Neal Ford. It describes very well why a microservice architecture like the one Sitecore have started supports you in not maintaining state – but makes you able to evolve your solution while still sustaining stable operations. The granularity of switching in the microservice makes them replaceable and changeable.

For those of you, who are familiar with the Helix principles – Helix is built along the same principles and lines of thought – just moving it up to a platform level as well.

The PaaS architecture of the Sitecore Cloud offerings extends it even more – you can commission and decommission services as you see fit – at the service level – not at the application monolith level. The important thing is what this offers to our customers – the ability to be creative and evolve the needed functionalities as the client needs grows and matures – meaning you can start out with default implementations – but when time arises – your services can evolve into more advanced features. It will be interesting to see this in Sitecore 9 as well.

The most obvious one for a commerce solution is the pricing service. All of us wants to end up in pure dynamic pricing – where the price is determined by supply and demand, time to purchase, personal preference and a lot of other parameters. Not something we control by human intervention – but dynamically “calculated” or evaluated Pricing Points based on datasets. Not the easiest implementation around – but using a microservice architecture – you start out with the default pricing engine – but as you get more data and information for setting the price – you implement and deploy a new price service with more advanced features – and nobody knows or cares – but your margins go up.

THIS LEADS DIRECTLY INTO THE NEXT SUBJECT - SERVICE SWITCHING FOR A/B TESTING

How do you bring this new enhanced dynamic pricing engine to your platform? Like everything else – you test whether it performs better than what you have. Instead of implementing this testing feature in your code – you make it a concern of service routing – the infrastructure or service platform can decide which of the two versions of the service you should have – and we will keep track of this and evaluate the business results of this.

This can be done in any other platform as well – but you will probably have to code the service switching into your own code – instead of making it a separate concern. You get this in Microsoft services as a result of the architecture – not as a result of a good thinking developer who foresee this.

SCALABILITY IS ALWAYS AN ISSUE

Let us more to the even more technology stuff – scalability. Scalability is always an issue – and from having implemented a ton of solutions that needs to sustain Black Friday sales on a BtC market – we know about scalability. A lot of web applications are scaling as a monolith – meaning you need to scale the complete functional stack, when you need to scale a solution.

When you have a Microsoft service architecture – you are able to scale the solution based on the service – and the more granular the service, the better you can sustain. As an example, you will need to scale the order and basket services for a Black Friday – but an order management and Catalogue management system does not need to scale (given that you build the webstore correctly). End consumers are pushing sales towards the basket – but you might not need to fulfill them at the same time. But – at night – when you need to pick’n’pack all the orders – you can scale down the webstore – but you need to scale up the order management systems. Microservices and a PaaS architecture helps you do that – you can scale out the individual services and keeping others running in a simple setup.

So – as you can see above – there are very sound reasons to why the new Sitecore architecture has strong advantages for driving more complex and dynamic solutions. For a static, smaller website – it does not matter – but when you move into business-critical scenarios, the ability to evolve and scale your solution at a very granular level it becomes even more important.

At the time of writing this – there is less than 1 month to the Sitecore Symposium 2017 in Las Vegas. I hope to meet a lot of you there – give me a call or sent me a message if you would like to meet up and discuss the possibilities that you are given by encompassing the new Sitecore architecture.