Software
Microservices and Monoliths
By Arthur Correa • Author
One thing I've had to do a lot over the years is deal with a Monolith . In some cases it was not a bad experience, in others it was pretty horrific. Often Monoliths aren't an intended outcome, but unless you take explicit actions to isolate functionality as the code grows the code base will gradually grow into a Ball of Mud. A codebase starts off as something small and focused, but then over time, it grows organically as new user stories are added to it.
As these new user stories are added the code is extended in a tightly coupled way and the Monolith can be an advantage to an organization. It enables any of its people with the right skill set to make changes in any areas of the system. This gives the organization a lot of flexibility in how it staffs projects, and speed in how it can effect change on its codebase. it lets a company focus on getting the right solutions in front of its customers in the timeliest way possible.
However as the codebase and the organization grow the benefits of the Monolith can start to get outweighed by the disadvantages. The larger the Monolith grows the harder it is for the people who maintain and extend it to know the entire code base, the problem space is just too big. In addition the tight couplings between subsystems can grow in number and complexity making it more difficult to make changes without impacting other areas of the system. To make matters worse, the smallest changes require the entire Monolith to be rebuilt and redployed. So, in a nutshell, over time the Monolith gets more and more expensive to work with.
Now some Monoliths are grown in a very structured way, and some of the disadvantages can be mitigated with a cohesive vision for how it all works to together. Unfortunately more often than not a Monolith grows under a number of different architectural visions as different people move in and out of an organization and as a result the code generally grows more complex. In addition sometimes the user stories themselves contribute to poor growth patterns. Some of those user stories are perfect fits, others are shoehorned in, still others may have fit originally but morphed over time until they could be broken out into their own subsystem.
So in general while a Monolith can be a good fit for a company, in time the company must revisit the Monolith and find a better way to work.
One such way is to recast the monolith into smaller, manageable and independent Microservices. Each Microservice should focus on a particular business problem, and have a well-defined interface that keeps it distinct from all the other Microservices. This well defined interface defines a contract for interacting with the Microservice providing a strong boundary that prevents the tight coupling that can cause problems in a Monolith.
Having well-defined Microservices helps the problem of an engineer needing to know the entire code base but instead to focus on just the small isolated business area. This allows the engineer to have a deeper understanding of particular business areas and reduces the risk of unintentional defects as long as they stay true to the contract defined for their Microservice.
This Microservice approach will allow the software to scale, revision, deploy, and grow independently which in turn allows the company itself the same benefits. So a single small change no longer requires the entire codebase to be rebuilt and redployed. Instead just the impacted Microservice needs to get rebuilt and redployed.
Often these Microservices take the form of RESTful web services. In these cases we get a few additional benefits such as
- The ability to choose the right technology for a given web service. In some case you may want to use Java, with some open source support and deploy to Linux. In others you may want to use Ruby or Node.js, in still others you may use .Net and deploy to Windows. In all cases you have the freedom to choose the right tool for the job.
- Since the Microservice uses REST, any client that can make a web request can call your service.
- The REST standard has proscribed ways for doing things such as reading, writing and updating data via a call, so developers will be familiar with how to consume your service.