Review: “Monolith to Microservices” by Sam Newman
Microservices are independently deployable services modeled around a business domain.
I wanted to update myself on the latest patterns and techniques in the microservices space. It seems that the “Building Microservices” by Sam Newman covers the microservices in great depth. At the same time, there is another foundational book — “Domain-Driven Design” by Eric Evans that is usually recommended to successfully apply microservices. Both of these books have great reviews but I saw quite a lot of comments that they are too wordy (especially DDD). I was looking for something short, practical, and concise so ended up reading the “Monolith to Microservices” book. It provides a very pragmatic approach to monolith decomposition into microservices along with core patterns and techniques.
Summary
Sam provides two main definitions that one should be aware of when adopting microservices architecture:
- Aggregate — a representation of a real domain concept (Offer, Invoice, Reward). They should be treated as a self-contained units — the state and the code that handles the state transitions should be grouped together.
- Bounded context — a larger organizational boundary inside an organization (for example Warehouse business functions vs Finance). They contain one or more associated aggregates. Some can be exposed outside the bounded context, others are hidden internally.
Both can be represented as microservices in the system. The author advises keeping the number of services minimal when you start decomposing monolith. Therefore, he suggests to model bounded contexts as services first and only then consider breaking them into smaller services around aggregate boundaries. This way you can continue to introduce new microservices within the bounded context as an implementation detail that doesn’t require the outside world to know about it. As a result, it will reduce the number of moving pieces between the organizational units and it will allow staying on track during the migration process.
Sam provides a few reasons on why to choose the microservices:
- Improve team autonomy
- Reduce time to market
- Scale cost-effectively for load
- Improve robustness
- Scale the number of developers
- Embrace new technology
At the same time he advises against the microservices in the following cases :
- Unclear domain
- Startups
- Customer-installed and managed software
- Not having a good reason
Microservices can help to scale the business but at the same, they will introduce the operational complexity that will require better infrastructure tooling and SRE discipline/maturity.
Sam suggests to ask three questions when you consider adopting microservices:
- What are you hoping to achieve? — at the end of the day, the outcome should describe the benefit to the end-users and be aligned with business
- Have you considered alternatives to using microservices? — the book describes many ways to achieve the same benefits that microservices bring by using much easier and boring techniques
- How will you know if the transition is working? — there should be a clear way to measure the success of the transition by planning it in the incremental approach. This way it will be cheaper and easy to make changes during execution.
Overall, the author tries to deliver two messages. First, gather as much information as needed in order to make a rational decision in the context of your situation. What works for others might not necessarily work for you. Second, embrace the incremental adoption of microservices. The book covers all the major patterns of monolith decomposition from application and data perspectives. It also gives a very brief overview of how to plan the migration and how to deal with growth challenges when using microservices.
My experience
At Jetlore, we were a startup in the unknown domain for the majority of us. The architecture and design of the system were evolving together with the company when it was searching for the product-market fit in the personalization space. We had around 20 engineers split into five teams across different geographies. The production environment was running on AWS across 500 EC2 instances. In 2019, we migrated to Kubernetes to address the operational complexity.
The system looked a lot like a distributed monolith however there were clear boundaries of decomposition at the logical level for both of our main services: personalization engine and orchestration REST API. The biggest challenge came from the monolith database. We used Play evolutions module in our merchant dashboard web app and it was a serious flaw in the system. When I look back, I feel that the monolith database was one of the biggest sources of failed releases and stability. However, as it usually happens when you learn things the hard way, we started to address this problem with the final product iterations and refactorings.
Getting back to the book, I really liked the saga pattern — orchestrated and choreographed sagas. The former can introduce a place where the logic can be centralized. As a result, most of the logic will end up there leaving the rest of the microservices without any logic. On the other hand, the choreographed sagas introduce the event-driven design that brings a very decoupled architecture at the expense of business flow visibility.
We didn’t use choreographed sagas at Jetlore but we played with actors throughout the lifetime of the company (as early as 2011). Based on my observation, every time it was a big challenge for anyone to figure out how the system works when workflows were modeled using actors. Our learning was that event-driven architecture requires very strong supporting documentation with flow diagrams or very good tooling for visualization and debugging the states.
Interesting fact: Concept “Saga” was first introduced back in 1987 by Hector Garcia-Molina and Kenneth Salem in the paper “Sagas”. They tried to address the challenges of long-lived transactions.
Verdict
Recommended
