Breaking a monolith – modernizing legacy software

Where we’re coming from

We have spoken about legacy software development processes in our previous blog post, if you’ve missed it here is a link. Today I wanted to how to modernize software by breaking a monolith.

When I first started working in software development, we had a saying: "bigger is better". And boy, were we right. Our applications were massive monoliths, sprawling beasts that took up entire racks of servers and required regular sacrifices to the Oracle and MS SQL gods. From HP and IBM clusters to SAN controllers we had everything in the lab. Loads of shining lights and an ear protector to enter. But as time went on, we began to realize that bigger wasn't always better. It was often a huge pain.

Server Room


Standard for the time, these software solutions were deployed in a data centre, as there weren’t any other options at the time. Cloud was still only twinkle, not widely adopted so you're pretty much left with VMWare or bare-metal. Today we of course refer to it as “on-prem” deployment.

In terms of the hardware, you had a choice to make with several manufacturers such as Dell, HP or even Compaq (which later got bought out by HP) or IBM. Not to mention if you were developing in a non-x86 architecture with IBM AIX and HP UX running on specialist CPU architecture such as Power PC or RISC.

HP Rack Mounted Server

On the other hand, having a lab meant we had to deal with the constant maintenance and upgrades of our servers. It was like trying to change the oil on a car while it was still running. And don't even get me started on the cost. We were spending a small fortune just to keep the lights on.

We were using Oracle, and they were absolute beasts. They required constant tuning and optimization, and even then, they would still bring our entire system to a grinding halt when things got busy. We had several DBAs working full-time just to try and come up with some kind of solution to MVs and other lovely DB stuff. It was like trying to steer a cruise ship through a crowded harbour. One wrong move...

The issues with a monolith

These applications were complex in structure, with a large codebase, and a long commit history and therefore it was difficult to maintain, release and patch any issues on them. Even if there was some automatic test available for it, it normally took anywhere from 1-12 hours, or in some extreme cases even longer. 

Even the most well-maintained codebases could easily get out of hand due to the lack of modern collaboration practices such as code reviews or extreme / pair programming. Due to its sheer size, it was also difficult to package and release.


Cloud and microservices

As the years went on, we began to realize that there had to be a better way. And that's when we discovered the cloud. By this point, the cloud was also mature enough for mass adoption. It was like a breath of fresh air. Suddenly, we didn't have to worry about hardware maintenance and upgrades. We could spin up new servers in minutes and only pay for what we used. It was like discovering the joys of renting instead of owning a house - although this also has its obvious pain points.

But the real game-changer was the move to microservices. We slowly started to carve out small pieces of functionality and moved them into modern architecture. By breaking our massive monoliths into smaller, independent services, we were able to greatly reduce the complexity and increase the resilience of our systems. It was like taking a chainsaw to a big old tree and turning it into a bunch of little bonsai trees.

Microservice architecture


But it wasn't all sunshine and rainbows. The transition to the cloud and microservices was not without its challenges. It required a complete rethink of our entire development and deployment process. We had to learn new technologies and best practices. It was like trying to learn how to play the guitar after only ever playing the piano. But we persevered and it was worth it.

Now, we're able to deploy new features and updates to our systems with minimal downtime. We're able to quickly and easily scale up or down as needed. And most importantly, we're able to sleep well at night knowing that our systems are resilient and reliable.

So if you're still stuck in the monolith world, take it from me: there's a better way. Embrace the cloud and microservices. Let us help you get your organisation to the latest standards, and transition to the cloud by using Agile and DevSecOps. We're here to help.