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 out small and focused, but over time it grows organically as new user stories are added.
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 how quickly it can effect change in 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, revise, 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 redeployed. Instead, just the impacted Microservice needs to get rebuilt and redeployed.
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 cases, 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 prescribed 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.
So, just to wrap it all up. A monolith often starts its life as something good and useful, but over time it will grow into something unmanageable. Eventually, you will need to break it up into focused areas called Microservices. These Microservices focus on serving up a particular area of business functionality. This allows developers to work on smaller pieces of the overall problem and be more confident and effective in making changes.