Tech Thoughts: How to Breakdown a Monolith
The need to scale is a problem you hope to have as a company. While each company is unique the challenges they face are often quite similar. Here are a few things I consider when helping to break down a monolith to increase service performance and engineering velocity.
🗿 Determine the Type of Monolith
There are many types of monoliths in software. We need to determine what kind we have in order to break it down effectively and figure out points where we will have trouble scaling. Is it an application monolith with many responsibilities? If so we will want to find high volume or non-performant endpoints and break them out into new services to allow these parts to scale separately. Is it a database monolith where multiple services use the same database? If that is the case we will want to decouple the data to allow for different db schemas or even database types. Is it a monolith of deployment that requires a drawn out build and release process to deliver even the smallest feature? In this case creating a new separate service with a small footprint will allow for quicker releases and lighter builds.
👷🏻 Improve Your Operational Readiness
To break down the monolith we will need a solid foundation including continuous delivery pipelines to build, test, and deploy executable services as well as the ability to secure, debug and monitor a distributed architecture. We need this foundation because more services means more deployments, a higher likelihood of bugs being introduced, and more complicated observability. There is no avoiding the fact that breaking apart a monolith increases difficulty but a solid operational foundation can set us up for success. I suggest we work with our internal DevOps/SRE team to help improve and standardize our operational approach and our QA team to prepare for increased complexity in our testing.
👥 Consider the Human Element
As we break down the monolith and spread the logic across teams it is important to consider the increased cross-team communication that will be necessary. One of the big benefits in breaking down the monolith is that we can create greater focus on specific parts of the system instead of spreading the team across a large domain. This creates the need for teams to communicate more effectively as they build separate but interconnected services. It is also very important to build the new services with clear intention and purpose. They should be logically divided across technical or business domains and require constant reevaluation to consider the cost of decoupling against the benefits of increased velocity or scale.
🛰 Choose When to Decouple
The main reasons for decoupling services are based around dividing technical, business, or product domains. Decoupling for technical reasons is generally to address performance or scaling issues. In that case you want to start by identifying non-performant portions of the monolith and determine if they could perform more effectively as a separate service. Decoupling for business reasons usually involves separating features that change frequently to allow for higher velocity.
🛸 Build a Coalition
No work of this magnitude can be done without a cross-functional group working together to achieve the goal. It is important to get everyone together early and create alignment about the purpose of the decoupling and expected benefits. We also need to make sure there is alignment across engineering leadership, product, and the c-suite so we can integrate these changes with business goals and the larger roadmap.
🗺 Choose Where to Start
It is best to start breaking down the monolith by finding a capability that can be clearly defined and understood. The challenge of scaling is not only the technology but the processes and the people behind that technology. The deeper embedded the functionality is within the monolith the harder it will be to define and rebuild as a separate service. Starting with something like an auth service allows us to warm up on something that is clearly defined and use that implementation to improve our approach.
This was originally written as an answer to a case study I was given when applying for a Director of Engineering position.