There are some great initiatives already of running Sitecore in containers. The problem is that Sitecore is still using the .Net Framework which needs IIS to run hence you’ll need some sort of a Windows Server OS base image to be able to run your application. Although Windows server is offering very small instances (Windows Server Core and Windows Server Nano) the final containers to run Sitecore are pretty large which makes it not an ideal scenario for containerized environments. Moving around these large images is just not fun.
Besides that, from what I see, there is some lack of dedicated Docker support from Sitecore itself. There is still lots of work to be done. I assume Sitecore will improve Docker support and one day there will be proper support for:
- Sitecore on premise
- Sitecore Azure (PAAS)
- Sitecore Containerized
However, there are some options to unleash the full power of both worlds (Paas and Docker).
So, what about frontends?
The downside of this implementation is that there is a need for a complete new type of developer. All we needed the past years were Sitecore backend developers. But now, when business logic is moving towards the frontend developers. The frontend developers are required to perform a whole different kind of development tasks. The past years, frontend development was limited to pure frontend logic which varies from setting up accordions, do some styling and visualize API outputs. These are actually all non-breaking tasks. The application will run anyway.
But now, using Sitecore JSS, the responsibility for a Sitecore developer is in the js code itself. The frontend developer is responsible for setting up Sitecore, defining template structure and participate in the software architecture to define proper business logic in the application. From now, frontend developers can actually break the application!
At this point we are basically not talking about ‘frontend’ developers anymore. We are defining new Sitecore developers, which are developers who are
- Have sufficient Sitecore knowledge to understand how Sitecore works
- Accept the responsibility for deeper understandings of application architecture and design
When I look at the 2 teams which are working on the project right now, the team composition is totally different from the composition I’m used to work in. A usual Sitecore development team is powered by 2 or 3 backend developers (C#), a technical frontend developer(js) and a creative frontend developer (html/css/sass/less). In a JSS setup, the team composition is 2-3 technical frontend developers(Angular developers), 1-2 creative frontend developers and a Sitecore backend developer who is working in multiple teams (because there is not enough work in a single team).
So, if your next project is using JSS/Sitecore headless, think twice before taking this step.
From my point of view, I think the Sitecore headless in combination with an Angular/React/Vue setup is the key in taking Sitecore to the next step in development! Being part of a highly skilled Angular development team has opened my eyes regarding a whole new world which was unknown territory for me the past years. The way we are working now forced me to take multiple steps at once, not only regarding frontend frameworks, but also regarding SSR (Server Side Rendering), NodeJS, Docker and Kubernetes.
So, my advice for all backend developers:
- Learn Angular/React/Vue
- Learn how to work with NodeJS
- Understand SSR
- Learn about Docker
Personally, I don’t think the step for learning these frontend frameworks is steep. Backend developers are already trained in a more object/component way of thinking. The problem is more in the fact that C# developers are kind of spoiled with very mature frameworks like .Net MVC and .Net Core. There is no IDE like Visual Studio for Angular development. There is no Resharper. All there is, is Visual Studio Code which is an awesome editor but is lacking tools offered by Visual Studio.
And if you conquer all these challenges…. then there is the gold at the end of the rainbow!
Wait…. you said gold?
Yes, that’s correct! When the team is ready to take these steps, we can have a look at the way we are processing Sitecore deployments. And that’s where the fun begins!
Because we are decoupling the presentation from the Sitecore instance, we just don’t need Sitecore anymore to run a Sitecore website. All we need is a webserver which is running NodeJS to render the Angular scripts on the server (SSR). These applications communicate with the Sitecore Layout service to get the data. A JSS website might look like this:
The NodeJS site is the only public facing application. Because we’re using SSR, we can just limit the access to the Sitecore environments to the NodeJS webserver only. The downside of this setup is that we’ll need additional servers to run this kind of application.
In our project, the application is powered by an ESB(Enterprise Service Bus) which is offering several endpoints to talk to. So, the Angular application is merging data from 2 datasources:
- The ESB
- Sitecore Layout service
Because we are running a Test, Staging and Production environment, there is also a need for a Test, Staging and Production like environment for the ESB. And there is, sort of. However, the test environment is not fully operational, is missing endpoints etc.
To maintain high velocity in the team, we needed a way to make our application independent of the ESB. We ended up using Node Red Mockservice. Using this mockservice we are able to mock the ESB endpoints easily. By linking the Mockservice to our own Git repo, we can just add new flows for our components without being delayed by the ESB development team.
This is all running fine now, but does have some impact on our architecture which now looks like:
And, to make it complete, we did add an additional API to run functions which cannot be done by the Node application or ESB. This API is running on .Net Core. which will give us this setup:
Using only a mockservice for testing however is extremely risky. We just need to do E2E testing using the actual ESB services too which will give us our final setup:
Our first setup was designed to run on Azure as a full blown Paas application which will lead to a lot of PAAS resources where we need to define (and maintain) a lot of webapps and define and maintain a lot of deployments.
This was the time to rethink our cloud design. Setting up environments like this using Paas or VM’s is just taking a lot of time and effort.
Docker to the rescue!
Of course, this setup is screaming for a Docker setup, so we discussed this with the operations department and we decided to go for a hybrid Docker setup. We are still using Sitecore running in Azure as a Paas solution. Sitecore will be deployed using ARM and powershell. Our frontend applications however, will be running in AWS. This is done because the organization is already using AWS for a large part of their infrastructure in AWS.
And while we were discussing the migration to Docker, the operations department, who is in charge of the maintenance of the setup, proposed to use Kubernetes to orchestrate all these images which was an excellent proposal! So our new setup is using Azure for Sitecore and AWS Kubernetes for hosting the containers. Unfortunately, Amazon is not offering a managed Kubernetes service yet (only in the US available) so we have to build our own cluster. When the cluster is up and running we will have a architecture like:
And that’s a far more cleaner setup then all these webapps! Running these containers in Kubernetes is giving us the flexibility we want. Think about all these great ways to deploy new features using the Kubernetes deploy strategies. And what about deployments itself, we do not need to deploy files anymore! We just deploy a state of the application which already contains all we need. Rolling back an application is just a rollback to a previous container (we will still face the challenge of rolling back Sitecore data).
For now, Kubernetes is the way to go for us and hopefully we will be able to get to the 100 Sitecore deployments a day!