|
|
posted: June 11, 2017
tl;dr: Guidebook to implementing a microservices architecture, with many battle-tested tips and warnings...
I read this book more than a year ago and I still find myself referring back to it, which is a sign that it contains valuable information. Sam Newman covers the topic of microservices very broadly and from the top down, starting first with the business and organizational factors involved in the decision to implement a microservices architecture.
This focus likely comes from Newman’s years of experience working with a variety of companies as an IT consultant: software must meet the needs of the business first and foremost, and organizational structure does play an important role in system architecture (Newman is a big fan of Conway’s Law). Newman takes a cautionary approach throughout the book, warning that microservices are not the solution for every business need and every company, and pointing out the many pitfalls along the way. Microservices bring a new set of challenges for securing, deploying, monitoring, and ensuring the overall end-to-end performance of an application, as Newman details throughout the book.
This book is not a coding book; it is not going to tell the reader, for example, the commands to instantiate and deploy a Docker container. Rather it can be viewed as operating at a layer above the coding layer, at the architectural layer. As such it will have the most value for system architects, technical managers, technical leaders, and developers who want to grasp the big picture view of microservices and how to build a microservices-based software system. It might also be of interest to product managers and business folks who want to learn a bit about how a microservices architecture actually delivers the business benefits they are seeking.
I especially liked Newman’s emphasis on the people side of software development: he understands that software is written by people, not robots (at least not today), and there will need to be changes in how people interact with each other when implementing a microservices architecture. I liked his description of the technical architect as a “town planner” who plots out the general functions to take place in various areas and who plans the basic services which are available to all. I also like the way he breaks down a monolithic system by bounded contexts modeled after how the departments in a company already behave. Additionally, Newman has a wide exposure to many distributed software technologies, and he has some good insights as to what has worked well for him in the past.
There are real world lessons throughout Building Microservices, as Newman has clearly been through the process numerous times. He has some great war stories about problems to be avoided, such as cascading failures. Even with the pitfalls and all the changes in behavior and new technology needed to implement microservices, Newman is, of course, a fan. Done right, microservices can deliver more functionality to market faster, at greater scale, with increased developer efficiency and higher autonomy. This can lead to happier developers, which benefits both the company and the company’s customers in the long run.