Breaking up monoliths for fun and profit

We work with enterprise customers and although each company feels it’s a unique and delicate snowflake, most of them think, purchase, and implement the same things from an enterprise software point of view.
This typically means that every organization has a monolith — a software project that has grown to be mission critical and gained complexity and size with ever-growing challenges to maintain it or to have it running quickly, securely, and modernly.

The way that the software world (first in startups but now also within enterprise software ) has innovated after years of building bigger and thus slower legacy systems was first to adopt the SOA (Service Oriented Architecture) approach breaking up their monolith into several services that communicate between themselves through the network.

This was a good step in the right direction and led to the birth of web services and of the distributed computing approach but typically the projects were still part of the same codebase and run by the same people.

In the past years, these services were broken down, even more, to deal with and deploy a microservices architecture, basically thinking about your application as something built of dozens of stateless microservices typically communicating through a shared service bus or message queue.

bob sponge gets it right

This has a profound effect on the scale, development speed, and way that developers take responsibility in an enterprise organization. By breaking the software into many small microservices we’re achieving a few things

1. Reducing complexity
   By breaking down the internal logic of an application to dozens of stateless services and their intercommunication it’s easier to debug and understand the application.
2. Developer responsability
   Typically with monoliths, you were dependent on that engineer that “knew everything” about the project but if he would be absent or left the organization you would be truly in a problem.
   With microservices, you could allocate a few services per developer and have a fully functioning application without requiring one person to control and know the whole application.
3. Horizontal scale
   Writing microservices is implicitly thinking in a distributed way which enables you to spin up a few identical microservices to tackle a certain bottleneck that might be created by seasonal load or a batch process and scaling those services down, leads to much better utilization of the hardware beneath but also gives you the ability to grow your application horizontally and if performed right to basically let you grow infinitely.
4. Move fast (and break things) — development speed
   Facebook famously coined this mantra but it is a key feature related to the speeds startups operate and the ability to innovate as fast as the competition.
   With monoliths typically, you would release code once a month or a quarter and it would always be associated with “the release” meaning that you’ll have a few dramatic days as you deploy the new code after running QA and regression tests.
   With microservices, a lot of this drama is handled by the fact that when you want to fix a bug you would be deploying only one service in hundreds so effectively you would not need to recheck the application. changed and deployed only a small part of it.

Decoupled Releases and Deployments

Working in a test-driven approach also helps you find problems before you deploy them because you would be defining the health of the service and would test to make sure it is running correctly as a separate unit and in the larger “end to end” context.

One of the main things we do in Linnovate is handhold organizations in their path to break up the monoliths and to host and manage them with modern deployment toolings such as docker, docker-compose, and Kubernetes (we’ll try to dive into that in the upcoming blog posts).