I just concluded Building Microservices: Designing Fine-Grained Systems – 2nd Edition (Sam Newman, 612 pages), and I enjoyed it quite a lot.
Microservices architecture have become quite common over the last decade. Surely due to the fact that it is seen as a great way to scale systems that serve millions of users globally. It has it complexities, though, as this book is great at discussing in details.
To start with, as the author himself points out, microservices should not be an automatic choice for new systems. Quite the opposite. Starting a new system as a monolith is a great alternative. Because it makes many aspects of the architecture simpler to deal with.
With time, though, for those systems and companies that are able to scale up, it becomes very interesting the option to eventually select those parts of the system that are bottlenecks and build them as separably deployed entities. Or, microservices.
The idea of independently deployable services, by the way, is at the core of what the Microservices-oriented software architecture is all about. The point being that a team working on a sub-part of a large system should be able to deploy new versions of their services without any dependency on any other team. This idea is quite powerful. And it certainly requires a mindset changing, for those not used to it.
However, it brings for sure lots of other issues. Typically, teams deploying microservices should own everything related to them, from the user interface to the data persistence layer. For this to happen, though, the system in case needs typically to be partitioned vertically, with different business domain areas being covered by different stream-aligned teams.
For those teams working in internal services that support other business functions, the idea is also that the team is completely responsible to everything under the service, while focusing on providing a stable API to other internal actors.
In any case, ideas like “avoiding code duplication”, and “shared databases” can quickly become strong obstacles to independent teams and services. On the contrary, microservices should encapsulate all their needs and hide their internals from the outside world, as much as possible. Including their database choices.
Communication between different microservices is another topic discussed in details. In short, asynchronous communication, through events and queues, are definitely preferable in the microservices world.
Distributed transactions poses yet another challenge, when multiple services need to collaborate. In fact, distributed transactions should be avoided altogether, and alternative orchestration between services should be build into the system, when multiple steps are required to deliver business value. For example, in a web shop when the catalog, payment, and inventory services may have to collaborate in order to conclude a buying operation.
And there is more. Security and team topology, for example, are two other concerns discussed in details here. If any or all of this sounds interesting, you won’t regret spending your time with this book.
No comments:
Post a Comment