Sitecore XM Cloud Will NOT Take Your Job

Vasiliy Fomichev

In Architecture Posted September 05, 2023

Sitecore XM Cloud (XMC) and the edge function support by Vercel has many backend developers worrying about their job security. One of the most interesting things I hear is that some client technology teams even resist the modernization to XMC because of the fear for their job security. That’s the fact that made me want to put this blog post out there to put the fears of .Net developers to rest. This post has been sitting in draft for too long, and because the concern is not going away, here it goes.

TLDR;  if you are a backend developer, you are still in a good place with XM Cloud and your job security is safe and sound. In fact, if you are specialized in DevOps, there will be a lot more for you to do.

The Scary Tale of Backend Development Death with XM Cloud+

Let’s align on the concerns that the .Net Sitecore developers are losing sleep over –

1. Sitecore XM Cloud requires solutions to be built headlessly, which usually means using a frontend framework like React (Next.js), Vue, or Angular.
2. You cannot host business logic (not supposed to) in Sitecore XMC, so it has to be moved out of the solution into Next.js run in Vercel

The two above put together sound like they spell doom for .Net developers in the world of Sitecore. .Net was the predominant skill in the community and most Sitecore architects were coming from the .Net space, so it is no surprise that the concern is making so much noise in the industry, and that’s the perception I’d like to correct.

The Headless Concern

It is true that, if you are looking to move your solution to headless, you are likely going to look at one of the three frontend frameworks (React, Vue, Angular). In fact, you will most likely end up with React using the Next.js framework, simply because React dominates the world of web development with the other options being far behind in popularity. Exceptions may come up where internal teams may already be highly specialized in Angular or Vue.

While React with Next.js is likely the top choice amongst the frontend frameworks, there is also a .Net SDK available for Sitecore JSS (headless). Somehow it’s not talked about and it’s been getting the short end of the stick, however, it’s there. Going with the .Net Core SDK will keep all components in our well-known and familiar backend code.

There is one problem – hosting and maintaining the code. With Next.js Vercel takes on all the deployment and hosting concerns out of the picture, so the total cost of ownership of a headless solution will be higher. Plus it will take more plumbing to setup Static Site Generation (SSG), which is what all content heavy websites want to remain competitive these days, as well as Incremental Static Generation (ISG). For these reason, plus the fact that the Sitecore community is aligning behind Next.js, in almost all cases, an XM Cloud solution will end up there. However, there is a lot more to Sitecore solutions outside of components. Let’s break down a solution of an average complexity.

Anatomy of a Sitecore Solution

1. Presentation layer – this is where we have our layouts, components, and styling.
2. Integration layer – the code to allow data to flow between systems. We are usually looking at two to three custom integrations in a Sitecore solution that require backend work. Let’s stay conservative here and go with two. These are the integrations that need to built custom for any reason.
3. Business logic layer – all the code we write to manipulate data and content, plus custom APIs that need to be hosted in a Sitecore instance. Background jobs – things that run in the background on a Sitecore instance that do various types of content manipulation, system updates, etc.
4. Sitecore platform customizations – the code written to customize the out of the box functionality of a Sitecore instance. Here we are talking about modules, custom pipes, processors, etc.

While Next.js can potentially impact all of these parts of a Sitecore solution, it really shouldn’t. Next.js is good at some things, however, it is not a replacement for C# or .Net in many ways. Here is how the impact should spread based on using the right tool for the right job –

Using the right tool for the job is key here – .Net is a lot more mature, performant, and secure than Next.js. So it is especially important we us it for sensitive data manipulations.

Read more about comparison of Next.js with .Net here.

So now we see that we have impact in two areas of a solution. Let’s try to quantify it.

Presentation Layer Impact

Let’s say our solution has 50 components – 25 of low complexity, 20 of medium, and 5 – high. The amount of backend work usually applied to these t-shirt sizes is 6, 12, and  24 hrs respectively (if you are an architect reading this, you may have your own buckets and estimates, but they won’t be too far off). After a bit of math we get a total backend effort of 510hrs. This is the effort that gets moved out of the .Net with it getting replaced by Next.js. What % of backend work is that? Usually about 50%.

For instance, 2 integrations – 120hrs each (let’s say), Business logic – another 100hrs and Customizations – 100hrs – 440hrs already (I can see architects raising eye brows on this, just remember, these are high-level ballparks).

Customization layer impact

The modifications we would perform to the way traffic is treated at the Content Delivery level would need to be moved to the edge. This includes one of the most popular customizations that used to be taken care of by a module – the redirects. All redirect logic now needs to live at the edge (rather should for performance). In addition, any customizations to traffic input and output like header manipulation etc. should also mode to the edge. The good news for .Net developers is that the redirects moving to the edge doesn’t really impact the amount of .Net code written, because it was taken care of by the module and request and response manipulation usually doesn’t happen in an average Sitecore build. In other words, on average, there will be no significant impact here.

.Net work getting added

What doesn’t get talked about, however, is all the work that gets added for .Net developers as the result of moving to SaaS and cloud architectures. Business Logic and Integration layers now need to be hosted outside of Sitecore, ideally using a serverless architecture. All of a sudden, our simple APIs and small jobs got a home of their own and need to be placed into a separate project that would get deployed independently from other projects supporting other layers. What we are looking at is significant jump in effort on the DevOps side, which comes with added overhead for backend developers. With that, a simple API that required a method in one of your controllers in C# now needs a separate project  and deployment plumbing. If you are a DevOps-specialized developer, your work has just gone through the roof. Let’s say it takes a few days to setup a pipeline using existing templates for three environments (dev, qat, prd) so let’s multiply that work by at least 5 projects – we get 360hrs back into our backend purse and that’s without even changing the architecture of the solution into what is gaining more and more popularity – microservices. Here we are splitting functionality into more granular projects which adds more and more .Net development and DevOps overhead. The overhead created here for developers comes from managing all the moving pieces – from local setup to aligning deployments of different projects and testing. We likely won’t see microservices and more complex architectural patterns in the XP to XMC migrations, because of companies trying to keep the migration cost down; however, many of the new builds will follow that approach and it will easily add over 150hrs and actually create more work for .Net folks.

All of a sudden, we went from half of the .Net work moving out, to actually more .Net work coming into the Sitecore space! The work that will be done is evolving, but the amount of effort that will be required from backend developers will not change much. Of course, “your mileage may vary” however, this analysis shouldn’t fall far from the average in the Sitecore space.

Still skeptical and not seeing it? Trying out commerce projects with Sitecore. Commerce projects tend to be a lot more complex with significantly more integrations, a larger business logic layer, and plenty of customizations. The component .Net effort reduction from moving to Next.js will have even a smaller impact on the overall backend effort there.

Final thoughts

About 10 years ago I went to Microsoft Build conference in Redmond and heard a debate about what side will win over the web – .Net or JavaScript (jQuery back then). Frontend folks had put out some strong arguments that JavaScript would soon evolve to the point of replacing the need for .Net, while backend folks were stating that new .Net frameworks will remove the need for writing raw JavaScript. In hindsight, neither side was right. The engines that run backend and frontend code get optimized for their respective areas of responsibility, and it seems as when one tries to play the role of the other, it does not do well, because it’s optimized for something else. It is possible we will and up with the “Python of AI”, and maybe Next.js that, however, it’s not there now and it still has serious drawbacks.

Here are a couple of other tips for backend developers –

1. Learn DevOps – hopefully by now you see the reason with the explosion of separate projects
2. Learn to work across operating systems (Linux) – with .Net core, we can gain cost efficiencies, performance, and potentially security by running it in Linux.

Summary

Article Name

Sitecore XM Cloud Will NOT Take Your Job

Description

Sitecore developers are worried about Sitecore XM Cloud taking their jobs with the moajority of work moving to the frontend or the head of applications. In this post we look at the facts showing that .Net development is not likely to be fully replaced by Next.js.

Author

Vasiliy Fomichev