Let's Talk About Microservices

In this article I want to present the case for a microservice architecture-based website. Such an architecture allows for a powerful CMS to be decoupled from specific user-centric services, providing the flexibility to choose a mix of different best of breed microservices rather than being forced to use those that come OOTB with the CMS.

As these services become more affordable and powerful it makes sense to utilise the best of the best instead of having to compromise on feature set or functionality by using the built-in CMS alternative. Liberate the CMS and let it do what it does best; content management.

Enter the Monoliths

I was first introduced to the CMS back in the early 2000’s and it changed the way I saw web development. Up until that time, I only knew web development to be a recipe consisting of static HTML, JavaScript, a sprinkle of CSS and server-side code for additional functionality. I still remember how being exposed to the likes of Umbraco and Sitecore was a major mental paradigm shift where, with the use (or re-use I should say) of templates and layouts, one could build content and presentation layers in a cookie cutter fashion; it was a brave new world.

Over the years the landscape had evolved, filled with a multitude of CMS products, across multiple technology stacks, with an ever-growing abundance of features. The age of the monolithic CMS was upon us. CMS product releases were incrementally providing richer feature sets; competing not only on their core CMS-related features (templates, layouts, workflow, etc.) but also on non-traditional CMS features such as e-Commerce, email marketing and event management to name just a few.

Fast forward to more recent times, and the core value proposition of the enterprise CMS platform is usually it’s monolith style all-in-one architecture. Organisations have, up to now, embraced the promise of a one-stop-shop where they can invest in a single product that reduces licensing and integration costs, minimises the number of vendors they have to engage with and the simplifies the management of their digital marketing program. 

Best of Breed Alternatives

However, in some cases, clients have opted to replace one or more of the CMS monolith’s features with other best of breed alternatives – a trend that is growing. This isn’t specific to one particular CMS product, but has been the case for most of the big CMS platforms that I’ve been involved with. Perhaps Google’s Analytics services offer more power than the CMS bundled equivalent, or the team responsible for EDMs find Mail Chimp has a distinct edge or maybe Marketo’s promise of enhanced marketing automation capabilities seems irresistible.

Whatever the case may be, companies like Mail Chimp focus all their resources to make their platform a market leader in it’s specific niche; in contrast, a CMS platform is spread thinner as it needs to develop solutions for any number of specific features. This is not to say that in some cases they may offer a service that is on par with what a service specific vendor can – it would just be very hard for them to provide that across every single feature. 

There is also a speed to market question. Often single feature focussed platforms can bring innovative new features to market quite quickly. In contrast the monolithic CMS will usually be a year or two behind, taking a more cautious approach that factors in the vagaries of interdependencies between various components and the risks of destabilising the entire platform with the introduction of new untried features.

In all of this, it is worth remembering why CMS platforms exist - at their core at is to create best of breed content management systems. This line of thinking lends itself to the microservice architecture approach being able to provide the opportunity to create the optimal solution across the breadth of digital ecosystem.

Monoliths Vs Microservices

For me, the easiest way to look at it (monolith vs. microservice based solution) is with old school sound systems. Back in high school (going back to the 90’s now), I had an all-in-one stereo, complete with two tape decks, equalizers, a CD player, two speakers and an LP on top - pretty cool stuff. My older brother, on the other hand, had a high-end setup (of a particular German brand) which was a combination of top of the range individual components. Functionality-wise they did the same thing, had the same types of components, but his was better on two fronts: 

• First, his components were range topping (best-of-breed)

• Second, if his CD player broke, he only had to replace the CD player, the rest of the system continued to work. 

I remember that my CD player broke and the all-in-one stereo went in the bin; it was a sad day.

How does this equate to a website? Well, in the case of a monolithic system, if your CMS goes down, everything goes down. In the case of a microservices architecture, your CMS might go down, but your microservice live on; there is nothing stopping you from setting up a holding page which hosts your Google Form registration form and redirecting the inbound URL accordingly. On forms, suppose you’re not satisfied with the capabilities of Google Forms, you can swap it all out for the alternative Paper Form product without significant effort. Not so easy with the monolith.

In my experience, the advent of the headless CMS was the catalyst for a paradigm shift in my thinking; to begin to look at digital transformation solutions with a new set of eyes. Perhaps the ideal of digital transformation is a solution which comprises a joint set of best of breed products working cohesively. It stands to reason that an all-in-one is unlikely to provide market-leading performance across every facet of functionality. Popular microservices such as Paper Form, Google Analytics, Microsoft Azure search, Disqus, Marketo and Mail Chimp can do certain things better.

Disadvantages of Microservices Architecture

There are, of course, disadvantages to a microservices architecture. Most notably, the disconnection and siloing of data; which means that although each part of the collective system may work well in isolation but your data is stored in disparate systems.

Accessing the data is not in your complete control and subject to the specific vendor terms; a potential problem if you consider GDPR and privacy laws. Another factor to consider is how your organisation is structured with teams and resources tasked with maintaining an online presence. A smaller company with a single content editor would benefit from a monolithic system where every service is built in, but they may be at a potential disadvantage if they had to maintain several systems all at once. 

However, a large corporate with specific teams tasked with managing a specific part of their online eco-system might greatly benefit from a microservices architecture. The marketing team do not need to concern themselves with the CMS at all; they simply manage their campaign-based activities and the fact that there is a level of integration with the CMS is irrelevant.

The Future

The monolithic CMS is not dead, not by a long shot. It has its place in the industry and we will continue to see vendors enrich the built-in services that the big CMS products offer. However, as best-of-breed microservices continue to evolve and can offer a more powerful alternative at the right price, the idea of a microservices architecture becomes all the more attractive. 

Written by Jake Kula | Lead CMS Developer