Microservices: Breaking the Monolith

The Problem

A Client of 345 was having difficulties with one of their main, mission-critical systems.  

Over time, the functionality of the system has expanded to cover a large number of business processes.  This large, complex and high-performance system was suffering from the following symptoms:

  • High cost of change – a relatively small change required disproportionate amounts of retesting as it could affect the whole system.
  • High level of skill and knowledge – the system needed to be understood as a whole by the technical team, requiring a long and steep learning curve.
  • Slow pace of delivery – owing to the test overhead and the complexity, further business change was slow.
  • Painful deployments – because the whole system needed to be updated every time even a relatively small change was made the deployments took a great deal of effort.
We understood why this was happening, as we had seen this many other times in the past.  The system had, over time, evolved with many cross-dependencies so that it had effectively become a monolith.  A system designed initially to be made of separate, contained components, had become intertwined so that a change in one place affected many others.

The system had, over time, effectively become a monolith.

What We Did

Agree a Worthwhile Goal

We worked with the client initially to set the parameters of what a great future system design would look like.  You can’t achieve success if you don’t define what it looks like.  We agreed on a vision that we would move to a “Microservices” architecture – a system composed of small, discrete services where each piece of the puzzle did one thing and did it well.  And more importantly, each piece of the puzzle could be independently changed, tested, deployed and scaled.  


The problem of the “monolith” were understood at a high level, but not at a detailed level.  The first thing we had to do was to understand all the working parts of the system and how they fitted together.  We needed to know what each piece did, what information was flowing through it and how it related to the other parts.

Armed with this information we were able to understand the system as a whole and find the problem areas that would make the biggest impact when we tackled them.

Produce a Compelling Vision

Once we understood the system we were able to start painting a picture of what the future would be like.  

In this case, many of the system’s components were originally intended to be stand-alone, they’d just become baked into the whole over time.  Logically separating these pieces out as part of the vision was an easy first step.

After this, we needed to re-imagine the rest of the system.  We could simplify large parts of the system with newer technology, better design patterns and with the benefit of hindsight.

All this came together to produce a vision of the future system comprised of 39 different microservices, many of which could be created by simply repackaging parts of the existing system.

Plan the Route to Success

In our experience, a barrier to moving to a microservices architecture is the inertia of what seems to be a giant task.  Possibly months of pain battling legacy code when no-one knows how it works and no-one wants to be the one to venture in there either.

How do you eat an elephant?  One bite at a time, of course!  The same applies in cases like this.  Sometimes you need to just do the first chunk and see how you go.  Maybe pick the easiest one, or perhaps the one with the biggest impact.  That’s what we did here – we sequenced the 39 different microservices so that we had a plan of attack.  A plan that would be easy to start on and get easier the further along we got.

A vision of the future system comprised of 39 different microservices.

The Result

At the end of the engagement, 345 produced a blueprint for the future system composed of 39 different microservices.  We produced a development roadmap to deliver the microservices and had identified the key technologies and design elements to make the vision a reality.

At the time of writing, the Client is still working through the roadmap with assistance from 345.

Have a monolith that needs breaking down?

Talk to us about how we can help you make your systems more effective and manageable

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

happy holidays

we want to hear from you