Editor’s Note: In this series of blogs, we’ve chosen a series of software development design patterns to help developers keep up to date on the patterns most important to the DevOps industry. Previous blog posts focused on value stream mapping and the anti-corruption layer .
In this series of blogs, we’ve chosen a series of software development design patterns to help developers keep up to date on the patterns most important to the DevOps industry. The first one focused on value stream mapping and the second one on anti-corruption layers. This is the third one.
Name
Strangulating the monolith
Intent
Legacy code often involves systems that are architecturally coupled together -- the antithesis of the modern microservices world. Wherever you are in your journey of continuous everything (integration | testing | delivery | deployment | analytics | governance), you may have faced these challenges.
Scenario 1
You are able to release small changes only after you have executed intense integration tests in complex end-to-end (E2E) environments. The overall test cycle time is inflated by not just the execution time of the integration tests but also by the labor involved in setting up and maintaining an integration environment. Worse still, large organizations can end up with several integration environments that cater to different teams who refuse to share.
Scenario 2
Changes to one part of the codebase can affect other unrelated parts in unexpected ways, which means testing a small change requires integration tests with other parts of the larger system as well.
So, consider modular designs rather than lumping everything together into one unwieldy monolithic application, commonly known as a “big ball of mud.” This design pattern decomposes or incrementally strangles the large codebase, referred to as a monolith, into smaller modular services. This happens as new features are introduced.
Also Known As
Architecture Decoupling.
Motivation
Strangulation enables parts of the codebase, that have a higher rate of change, to be decoupled from a legacy monolith.
Strangulation empowers small, possibly separate teams to release at their own pace. It fuels decentralized approaches, like decentralized governance and decentralized data management. Decentralized approaches align well with the modern microservices architecture, and hence have gained momentum in organizations undergoing digital transformation.
Applicability
Let’s define components as the smallest distributable and testable units, and subsystems as the smallest deployable and runnable units. Loosely coupled components make up subsystems. Loosely coupled subsystems get assembled into a system or several mini-systems. The figure illustrates subsystems 1 through N being assembled into a system. This assembly or composition pattern leads to a monolithic system. It is to the organization’s disadvantage that the system needs to be validated in its entirety so that individual subsystems can be released. These intense integration tests typically happen in cumbersome E2E or end-to-end environments.
Migrating a monolith (and tests) into a service oriented architecture (SOA) or microservices architecture makes sense if:
Teams experience difficulty and delay in building, testing, deploying and in general, maneuvering a monolith. These teams have been appalled by the cost of delay after assessing their processes with value stream maps or other techniques.
Teams prefer multiple independently deployable artifacts over one monolith since this is a nice way to empower small teams to innovate at their own pace.
Teams prefer microservices centered around independent business capabilities. Microservices generate linear continuous delivery pipelines that are easier to troubleshoot than complex, graph-based pipelines generated from artifacts that need to be assembled before release.
Consequences
(Take these consequences with a grain of salt since a negative consequence for one team can be a boon to another. You need to look at the overall outcomes.)
One side effect of microservices being the shiny new thing on the horizon is that inexperienced teams try to start with microservices and encounter problems. Remember, there’s no shame in starting with a monolith and eventually figuring your way out.
Even otherwise, strangulating the monolith has its (un)fair share of woes:
Some teams fail to agree upfront on the definition of microservices. For example, here’s Martin Fowler's definition and here’s SmartBear’s definition . Irrespective of how you define the problem statement, without a shared understanding, execution can be frictional and the outcome debatable.
As far as microservices go, most/all teams want to opt in. Yet they get confused between the technicalities of a monolithic codebase and a monolithic artifact.
Big bang architectural changes are incredibly hard to execute, and vision without execution is no good. A popular joke goes “All you get from a big bang re-architecture is a BIG bang!”.
Microservices are centered around single business capabilities and independently deployable artifacts. Re-architecting to achieve those goals may not be a top priority for some organizations because they need to keep the lights on with the same resources.
Return on investment (ROI) may be high for partial strangulation of monoliths into microservices, while complete strangulation might best be postponed for further assessment. It may be best to chip the monolith down to a manageable size and leave it alone after that.
Microservices can add complexity if you cannot condone decentralized governance and decentralized data management. Both are powerful decentralization concepts, yet evaluate honestly if your teams are disciplined enough to be liberated from centralized standards.
Implementation
There are a few experience reports of how strangulation of monoliths to microservices has been executed in the industry:
Fearless monolith to microservices migration - a guided journey
Using API gateways to facilitate your transition from monolith to microservices
Known Uses
Here's the journey at Cupenya .
Related Patterns
API Gateway, Strangler.
References
The following articles reveal more detail on whether to use monoliths or microservices and the pros and cons of each approach.