Microservices as Lean Architecture
In my article microservices adoption in traditional companies, I raised a question after describing the complexities of a microservices architecture implementation: Is it worth it?
In our work, it’s very common to find ourselves in the situation of having to justify the choice of a microservices architecture to technology professionals, some of which do not necessarily have background or considerable experience in software development.
This article is a tool for those cases: mapping the lean concepts to monolithic systems concerns, giving arguments that are not software centered, have broader scope and are stated from the perspective of general industrial organization.
Lean Methodology was created by Toyota Company and is very well known by professionals familiar with industrial production. This methodology has long been a mainstay in formal, graduate-level academic study, and continues to provide a framework for substantial improvements in industrial organization for production optimization.
At the core of Lean Methodology is the concept of waste, called muda, and the mandatory process to develop this methodology is the identification and removal of muda. Mura and muri are deviations in the product building process that have to be removed to avoid the accumulation of waste.
In brief, muda is all that does not add value to the client. Mura is the unevenness or set of irregularities that happen in the process, and muri is the overburden on the processes or humans that is caused by muda and mura.
OVERBURDEN ( MURI ) IN MONOLITHIC SYSTEMS
Overburden in monolithic systems takes place along the whole software development lifecycle. When the amount of code that is impacted when a new feature is implemented is larger, there is a greater likelihood that the changes impact other unrelated modules.
As a consequence, any quality control team member that verifies the functionality of a particular feature and any developer that solves bugs or implements new features are overburdened. Finally, any component that provides memory and cpu resources to the overall monolith when only part of it receives an increment of demand is overburdened as well.
This accumulation of overburden is caused primarily because monolithic systems are not designed for the separation of components that can have distinguished consumption of resources and for several different domain-aligned teams managing its development and evolution. This characteristic favors the structuring of the monolith into modules of broader scope and with no business aligned separation, mainly because the separation is not designed from the beginning. And if it is designed, it’s not done purposefully or flexibly and if it is, the enforcement may not always be done or consequently verified.
Of course, this concern does not necessarily mean that the monolithic system cannot be properly structured, but it’s less feasible due to the initial predisposition and associated practices in its design and development.
The broadly well-known requirement of leveraging Domain Driven Design practice to discover subdomains and determine a high level structure of the architecture when designing microservices based architectures is a key differentiator from the monolithic architectures in this topic.
UNEVENNESS ( MURA ) IN MONOLITHIC SYSTEMS
Where are the unevenness or irregularities in the monolithic systems? Mura can be seen in the non-restricted couplings in the design of monolithic architecture, which causes the time and effort required to implement a new feature to be affected due to those couplings. This means that a simple feature may require more time or effort because of the implied changes in other modules or in a wider codebase. A consequence is that two functionalities that seem to be of the same complexity can have differences in the time and effort for their implementation due to their hidden, and not required by business, dependencies.
So, the estimation is less reasonable in terms of the functionality provided and hence two similar features may be assigned to two different team members but one of them may be overburdened in comparison to the other, causing unevenness.
WASTE ( MUDA ) IN MONOLITHIC SYSTEMS
For identifying muda in monolithic systems, we will go through the 7 types of waste. When relevant, we will use the software mapping that Mary and Tom Poppendieck used in their 2006 book (Ref. 1).
Inventory. The available stock is, in the monolithic systems, the resources assigned to the monolith for a capacity measured for the worst case. In comparison, a microservices architecture provisions, at most, the resources that are needed in a normal, average usage and the peaks of demand are covered by scaling thanks to the elasticity feature.
Extra Processing and Overproduction. Both types of waste do not require detailed explanation besides considering that a more proper alignment to business with DDD methodologies lowers the risk of having overproduction and extra processing (developing more features that a particular business domain or subdomain requires in a certain moment).
Transportation. This type of waste is mapped by Poppendieck to the handoffs, documents that “carry” the knowledge between teams and team members. In general, they are not a good thing to have: It’s better to guide the tasks for some time until the knowledge is transmitted. The assignment of a microservice to a team minimizes the need for this type of document. Each team member can guide another one while the microservice is built and its reduced scope makes this guidance easier and in a shorter period of time. A full working microservice baseline with good comments can, for certain seniority levels of developers, make the onboarding completely non-guided. In a monolithic system the knowledge demarcation is not clear and there is a tendency to make complete documentation for the monolith that is generic for any new team member used as part of the onboarding.
Waiting. Taking into account the muri, or overburdens, not only the QC process but also the bug fixing and the feature implementation may produce delays. Adding the mura already considered for the monoliths, the unevenness in the estimations may result in unforeseen delays.
Motion. Following the mapping to software of the methodology already referenced, motion is the task switching in software development. It’s clear that task switching is minimized when there is a clear separation of components and ownership of each by a team. Each team member can be the owner of a microservice and an autonomous microservice solution (a DDD bounded context) can be owned by the whole team. The focus that is optimized in terms of time by the agile methodologies are optimized in terms of the scope of code to be worked on by microservices architectures.
Defects. When there is more possibility of couplings or of a wider codebase affected by a feature, the risk of defects increases. The non-business alignment of the structure of the monolith goes in the same direction.
CONCLUSION. MURI, MURA and MUDA in MONOLITHIC SYSTEMS.
To sum up, the coupling in monolithic systems results in muri and mura for the excess of work in a broader codebase and the affection in the reasonability of the estimation of a feature considering its functional scope. Besides, the risk of muda of type defect rises. The mura generates waiting muda. The lack of knowledge demarcation for maintaining a software service enables the generation of larger handoffs (transportation muda) and the assignment of a team to the overall monolith increments the task switching (motion muda). The practice of Domain Driven Design, adopted in microservices architectures definition, is key for minimizing the risk of overburden (muri) and overproduction and extra processing types of waste. Finally, the impossibility of a granular and elastic assignment of resources to services generates an available stock that is used only in the worst cases (peak of demand), which constitutes muda of type inventory.
REFERENCES
- (1) Implementing Lean Software Development From Concept to Cash. Mary and Tom Poppendieck. Addison Wesley Professional. 2006.
