What Is ‘Monolith to Microservices’ and How Will It Change Tech

by Ned Hallett
Published on January 2020

Monolith to microservices has become a popular talking point in the digital space. Microservices offer more flexibility, quicker time to market, and the removal of the barriers to scaling associated with the monolithic approach. But what do these terms mean, and how will a broad movement from monolith to microservices reshape the industry – and the way you work?

What does it mean to refactor from monolith to microservices?

Microservice and monolithic are both styles of programme architecture. In a monolithic application, all processes are tightly coupled, often connected to a single relational database. If our application is getting people from A to B, then the monolithic version would be a train. 
If we were to adopt a microservices approach, however, we would have a convoy.

desert convoy

Microservice applications are made up of smaller, autonomous processes running independently of each other, often communicating via APIs.
This seems simple enough, until we consider that one of the core benefits of microservices is that the individual components are not, as in the convoy analogy, all working towards the same goal. 

In fact, what makes microservice architecture so powerful is that each service is not only different but can be selected from a sea of options, allowing you to build from a combination of best-of-breed.  A microservices application may combine web analytics, AI or e-commerce services from completely different providers, all working together to support a range of business processes.

A better comparison, therefore, might be that of a tree and a garden. 

All the monolithic tree’s processes, its growth, photosynthesis and, for the sake of argument, bark production, are inextricably tied to each other. A garden, similarly, is an interdependent system tending toward equilibrium – the plants produce, the insects consume and the bacteria decompose dead matter back into vital nutrients – the difference being, of course, that the plants, insects and bacteria, all specialists, can be swapped out for superior alternatives without damaging or causing friction to the overall structure of the garden. 

Refactoring then, is something that can be done in software but not nature: the breaking down of a monolithic structure into a set of smaller microservices. And the benefits are substantial. In addition to the obvious advantage of building from a combination of best-of-breed services, microservice architectures also solve a number of problems caused by their monolithic counterparts.

Smaller, discrete services are easier for a team to manage, maintain and understand. They also allow specialists to flourish, who are able to engage with their service without worrying about every way it will interact with the monolith. They reduce barriers to adoption, allowing developers to choose the technology which best complements their service. And microservices can be deployed independently, making the much-vaunted continuous deployment possible. 

But let’s see all these benefits at work in an example.

Imagine an e-commerce page running a cart, search bar and order processing service. With microservices, the cart function can be scaled independent of the search service. Further, the search function can be refined by its team, independent of the cart team, and utilising the technology that they see fit. While all this is going on, the order processing service has been replaced by a better one.

The companies currently pushing microservices are various, since this is a widespread trend, the move from monolith to microservices being one facet of a broader move toward small and consistent releases, and away from the traditional software development timeline, on which nothing happens until the big release at the end.

However, some companies do stand out. With their fiendishly simple 5-step How  to Break a Monolith Application into Microservices resource, AWS are certainly making a difficult process simple. Their approach, making use of Amazon Elastic Container Service, Docker, and EC2 delivers a decoupling of monolithic applications into microservices with zero downtime. 

Elsewhere, forward-thinking platforms in the CXM space, like Sitecore and Kentico, are offering more and more of their features as a service, as well as compatibility with microservices from other providers.

The fact that the major players are making this shift is surely a signal that microservices will become pervasive in the years to come. But what will that mean for the industry? And how does it affect you?

1 – Service Management Overheads, Headaches  and the Support Partner


man at desk with computer

One drawback of microservices is the multiplication of service partners, SLAs and time spent managing user accounts. Instead of dealing with one platform partner, you’ll now be dealing individually with the cart, search function and order processing services from the previous example. 

But where this gets really dicey is in the event of a hiccup.

Most brands will already be aware of the difficulties of pinning ownership for downtime or malfunction on any one party: it didn’t happen in your agency’s office hours, the cloud provider points to the application, and the application support team point back at the provider. The simple truth is that problems often do cross multiple boundaries, which makes it even harder to get the right people to take ownership. 

Split your application into 50 or even 500 microservices, and you can see where this is going. 

Enter the dedicated support partner. A relatively new concept in the digital space, support partners are able to take sole responsibility for the incident management of your now-complex and widely distributed application. To jump all the way back to one of our first analogies, the support partner is your on-hand ecologist in the garden of your new microservices application. 

IT support as business service is, of course, nothing new, but in an increasingly atomic world of server-less computing and this-or-that as a service, there is an increasing need for an expertise resource who makes unifying all this divergent knowledge their business, and this challenge is taking support in a whole new direction. 

2 – Standardisation and the Microservices Myths


Dragon made of metal looks right

While it’s true that microservice architecture is more scalable and flexible than monolithic architecture, some people have taken this concept a little too far. All around the internet, claims abound that microservices mean an unfettered release of dev creativity, with everyone using whatever programming language or database they like. 

The reality is that standardisation is key to an efficient set of microservices. Any programming language could be used, but in practice this creates a boatload of additional work. Rather, interservice communication protocols, cloud platform and tools should be standardised where possible. Not least because this offsets, a little, the problem of dealing with 101 and licences.

There is a strain of rosy-eyed thinking in the digital industries about microservices which sees every developer running custom scripts and each service working beautifully and uniquely side by side. This kind of over-valuing / silver-bullet worship often crops up around new concepts, and it’s usually either excited technical people who haven’t thought everything through or marketing people who’re going for wows over facts. It’s a myth. Don’t believe it.  

3 – Microservices Culture


two men talk in chairs

As with any fundamental shift in technical approach, there is a concordant shift in the culture of the people who’re responsible for implementing that approach. Notes of the microservices myth are present in much of the advice you’ll find, with endless and quite vague endorsements of ‘giving autonomy’, ‘enabling collaboration’ and ‘unleashing creativity’.

Again, we’re not saying microservices won’t bring about these things – but in practical terms, many of the more advisable microservice culture recommendations look to constrain an excess of these things, as they arise naturally from the microservices approach, rather than to promote them for their own sake.   

For one, the separation of teams into autonomous units, each responsible for their own service or set of services, throws up an immediate need for bringing them together again.  Regular sync-up meetings, documentation and sharing are advised to offset the sudden drop-off in visibility.

Similarly, the increased division of teams necessitates informed, business-conscious oversight, as the priorities of each individual team will clash as often as they’re dependent on one another – which is to say a lot. 

The takeaways: 

  • Monoliths are like trees and microservices are like gardens, both contain interdependent processes, but one is more modular and customizable.
  • Microservices generally allow faster time to market, combining best-of-breed services and independent scaling. 
  • Leading companies like AWS, Sitecore and Kentico are ready for microservices, signalling the continuation of broader trends within the industry of which microservices are one facet. 
  • Microservices present some problems in incident management and management overhead, expanding the role of dedicated 24hr support partners as they become more pervasive.
  • There are a few myths about microservices – they are not a development Wild West in which anything goes. 
  • The working culture response to microservices is one of sensibly constraining the creative scope opened up by microservices via business processes and technological standardisation.  

We hope you enjoyed reading. Get in touch about monolith or microservices, refactoring from one to the other, or just with your own monolithic and microservices analogy!