Building Microservices: Designing Fine-Grained Systems – 2nd Edition

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.

UML Distilled – Third Edition

I just finished reading UML Distilled – Third Edition (Martin Fowler, 175 pages). This book delivers on what one could expect from it.

This is not exactly the type of book that would cause much excitement, perhaps. It is all about an introduction to the Unified Modeling Language, which is not exactly a fresh topic nowadays anymore, as it could be said for a set of conventions first defined around 25 years ago.

It is, however, a very powerful design language for what I intend to use it. Namely, visually describing software architecture. And, as much as software ideas, frameworks, and architecture patterns have advanced and expanded, along the last couple of decades, a clear way to represent a designed architecture continues to be very relevant.

That’s what brought me to this book, even though I have already used UML several times before. I think an official recap on the most used diagrams and conventions could be good for some of my tasks ahead. And I found this book indeed helpful with that.

In addition, it covers interesting aspects of a language that can be used in formal systems design. As well as it serves as an indirect overview over some central aspects of Object-Oriented design and Model Driven Architecture.

If these topics are of interest, you won’t regretting the time spent reading this book.