{"id":491,"date":"2022-01-18T10:49:06","date_gmt":"2022-01-18T15:49:06","guid":{"rendered":"https:\/\/freedville.com\/blog\/?p=491"},"modified":"2022-01-18T10:49:08","modified_gmt":"2022-01-18T15:49:08","slug":"book-review-microservices-in-action","status":"publish","type":"post","link":"https:\/\/freedville.com\/blog\/2022\/01\/18\/book-review-microservices-in-action\/","title":{"rendered":"Book Review: Microservices In Action"},"content":{"rendered":"\n
\"Collection
Microservices are small, partially independent cogs in a larger application. Photo by Laura Ockel<\/a> on Unsplash<\/a><\/figcaption><\/figure>\n\n\n\n

I\u2019m glad I read this \u201cone-stop\u201d microservices book: Microservices in Action by Morgan Bruce and Paulo A. Pereira<\/a>.\u00a0 If you have time for just one microservices book, I think you can do well with this book. \u00a0It covers a variety of topics, not just the build and runtime but also the people and organizational aspects.\u00a0 The book has good breadth of topics.<\/p>\n\n\n\n

If you have more time however, I recommend reading two different books for a deep dive.\u00a0 The first half of this book is covered more deeply in Microservices Patterns<\/a> and the second half is covered more deeply in Site Reliability Engineering<\/a>.\u00a0 Multiple perspectives are often helpful, so you may want to read Microservices In Action first before reading the other two books.<\/p>\n\n\n\n

Most of the development techniques I\u2019ve heard for the last few years emphasized shifting as much as possible to the left \u2013 addressing challenges earlier in linear time (left) rather than later (right).\u00a0 The key insight I got from this book is rather than eliminating risk, microservices moves risk “to the right”<\/strong>!\u00a0<\/p>\n\n\n\n

\"Road
Microservices moves some complexity to the right, instead of to the left. Photo by Yeshi Kangrang<\/a> on Unsplash<\/a><\/figcaption><\/figure>\n\n\n\n

Like any architectural decision, a microservice architecture introduces tradeoffs.  We hear so often that microservices have lower development complexity within<\/strong> 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.<\/p>\n\n\n\n

This style of development requires a different organizational structure \u2013 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.<\/p>\n\n\n\n

The authors spend a little time on this problem, indicating that some concerns are addressed by overarching product\/technical leadership.\u00a0 But I can\u2019t help but feel that they skimped a bit in this area.\u00a0 I feel that an application with many microservice teams involved is going to devolve into a finger-pointing, \u201cbattlin\u2019 microservice teams\u201d situation.\u00a0 If the application as a whole does not work well, how does that get resolved?<\/p>\n\n\n\n

\"Hands
Teamwork is important, even across microservices! Photo by Rineshkumar Ghirao<\/a> on Unsplash<\/a><\/figcaption><\/figure>\n\n\n\n

I believe the authors skirt this issue because it\u2019s a difficult problem in monolithic applications as well.  It\u2019s 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!)<\/p>\n\n\n\n

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 \u2013 microservices require so many additional concerns to be effective (common logging, service registry, service discovery, metrics collection, and more) \u2013 that without a good chassis you\u2019ll spend all your time writing (and re-writing) boilerplate code instead of business logic.<\/p>\n\n\n\n

A good chassis is going to pull you towards centralized standardization.  If you have a chassis you love in Java, that\u2019s powerful gravity towards building each service in Java.  This is slightly counter to the \u201cuse whatever platform is best for each service\u201d mantra in microservices.  From a CIO perspective I cannot fathom a complete \u201cwild-west\u201d 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.<\/p>\n\n\n\n

This was the first microservices resource I read that advocated heavily for documentation.  It suggested for key types of documentation:<\/p>\n\n\n\n