I’m glad I read this “one-stop” microservices book: Microservices in Action by Morgan Bruce and Paulo A. Pereira. If you have time for just one microservices book, I think you can do well with this book. It covers a variety of topics, not just the build and runtime but also the people and organizational aspects. The book has good breadth of topics.
If you have more time however, I recommend reading two different books for a deep dive. The first half of this book is covered more deeply in Microservices Patterns and the second half is covered more deeply in Site Reliability Engineering. Multiple perspectives are often helpful, so you may want to read Microservices In Action first before reading the other two books.
Most of the development techniques I’ve heard for the last few years emphasized shifting as much as possible to the left – addressing challenges earlier in linear time (left) rather than later (right). The key insight I got from this book is rather than eliminating risk, microservices moves risk “to the right”!
Like any architectural decision, a microservice architecture introduces tradeoffs. We hear so often that microservices have lower development complexity within a service, because each service is smaller and has less dependencies. However, the entire microservice application has more complexity, and this is borne out during deployment, verification, and observation.
This style of development requires a different organizational structure – easier said than done. Each microservice is owned by a multi-functional team (and that team might own multiple microservices). The organizational challenge is clearly getting the different microservice teams to work together in the context of the broader application.
The authors spend a little time on this problem, indicating that some concerns are addressed by overarching product/technical leadership. But I can’t help but feel that they skimped a bit in this area. I feel that an application with many microservice teams involved is going to devolve into a finger-pointing, “battlin’ microservice teams” situation. If the application as a whole does not work well, how does that get resolved?
I believe the authors skirt this issue because it’s a difficult problem in monolithic applications as well. It’s not clear that microservices help or hurt with complex problem resolution. The authors are quick to mention that debugging across microservices can be difficult but they suggest a number of observability techniques which help. (The monolith world could benefit from this observability techniques as well!)
Like other microservice books, this book urges architects and developers to start with a microservice chassis that provides base infrastructure needed by any microservice. This feels almost undersold – microservices require so many additional concerns to be effective (common logging, service registry, service discovery, metrics collection, and more) – that without a good chassis you’ll spend all your time writing (and re-writing) boilerplate code instead of business logic.
A good chassis is going to pull you towards centralized standardization. If you have a chassis you love in Java, that’s powerful gravity towards building each service in Java. This is slightly counter to the “use whatever platform is best for each service” mantra in microservices. From a CIO perspective I cannot fathom a complete “wild-west” approach is a good idea, on the other hand forcing technology because of a chassis seems like a bad idea too. The authors note that there are not many chassis that work across multiple languages. I would have liked to see more on how you efficiently do observability across say 2-3 different chassis types.
This was the first microservices resource I read that advocated heavily for documentation. It suggested for key types of documentation:
- Overview (purpose, intended usage, overall architecture)
- Contract (API specification, ie Swagger/OpenAPI or protocol buffers for gRPC)
- Runbooks (Common operational and failure scenarios)
- Metadata (programming language, framework versions, links to supporting tools/builds/deployments/etc)
Further, the authors noted that many of these are hard to keep up to date and suggested to use auto-generation where possible. However they noted that very few tools exist for this purpose and you’re likely to need to roll-your-own.
Overall I am glad I read this book – a solid contributor to a microservices education.
1 Comment