I bought a copy of the building microservices book from Sam Newman. I felt I had a few knowledge holes with the technology that enables microservices (MS) and this book seemed like a great option. The first chapter hasn't disappointed. I liked that the author is not trying to sell microservices. He even agrees that a monolith should be the starting point in most cases. Here are few notes and thoughts.
Here is a concept I find useful and I didn't know: Architecture alignment. In the book Sam talks about how in a traditional three tier architecture we tend to align the pieces of the architecture with people that have a concrete role. Frontend people with the UI, data engineers with the backend and database admins with the database layer. In that context, the scope of change touches different teams, which may create friction. When working with microservices a single team is responsible for all the different layers we mention above, the UI, backend and database. The business domain is the main force driving the system architecture.
The author defines the monolith as a single unit of deployment. Talks about how this can be an excellent architectural approach:
If the module boundaries are well defined, it can allow for a high degree of parallel work, while avoiding the challenges of the more distributed microservice architecture by having a much simpler deployment topology.
He then introduces the distributed monolith as a system that consists of multiple services, but for whatever reason, the entire system must be deployed together. And then he cautions that in his experience those systems have the worse of both worlds, the distributed systems and the single process monolith. Let's be careful to not end up building one of those.
Sam wisely advises people starting with microservices incorporate technology once you have pains. He acknowledges that there are quite a few pieces of technology that enable microservices: log aggregation and distributed tracing, container and orchestration and streaming (event streaming).
This last one is the one I am most interested on. With MS, you are moving away from the database monolith but you still need to share data between MS. At the same time, companies are moving from batch to real-time processing. Later in the chapter, when the author talks about MS pain points, he mentions how some challenges are inevitable with MS and you will have to understand them. He is talking about things like data consistency, latency, and service modeling.
When he talks about service modeling he refers (I think) to the task of identifying the business ideas that should be grouped together and map it to a MS. And that is where data driven domain(DDD) comes into play.
In MS systems, instead of having one single location for your data, you have the data located on each MS. It is distributed. That introduces challenges regarding the consistency of the data. He hints as sagas for a potential architectural pattern that will help with this problem.
I close this post with a quote from the book:
Despite the drive in some quarters to make microservice architectures the default approach for software, I feel that because of the numerous challenges I’ve outlined, adopting them still requires careful thought. You need to assess your own problem space, skills, and technology landscape and understand what you are trying to achieve before deciding whether microservices are right for you. They are an architectural approach, not the architectural approach. Your own context should play a huge part in your decision whether to go down that path.