New Book Review: "Building Microservices"

New book review for Building Microservices: Designing Fine-Grained Systems, by Sam Newman, O'Reilly, 2015, reposted here:

Building_microservices

Stars-4-0._V192240704_

As explained in the preface to this book, "microservices" are small, autonomous services that work together, each of which is focused on doing one thing well. While the topic of microservices is fast-moving, the term itself is new even though the idea is not. Be aware at the outset that some other reviewers here did not pay attention to the philosophy used for this book. Newman indicates that, due to the fast pace of change in this space, he tried to focus this book "on ideas more than specific technologies, knowing that implementation details always change faster than the thoughts behind them" and he fully expects that "in a few years from now we'll have learned even more about where microservices fit, and how to use them well".

After covering an introduction to microservices, including some key benefits and downsides, Newman discusses the architect in the context of microservices, followed by modeling microservices, integrating microservices, splitting monolithic systems, designing systems, and scaling microservices, as well as deployment, testing, monitoring, and security. The most heavily weighted chapters are the ones on integrating microservices and scaling microservices, which consume about 32% of the text, followed by the chapters on splitting monolithic systems, deployment, and testing, which together consume about 31% of the text. While I personally would have liked to have seen the development lifecycle chapters at the end of the book, the reader can simply read these last.

The "Microservices and SOA" sidebar of Martin Fowler's "Microservices" article indicates that the "common manifestation of SOA has led some microservice advocates to reject the SOA label entirely" and "others [to] consider microservices to be one form of SOA, perhaps service orientation done right", but "the fact that SOA means such different things means it's valuable to have a term that more crisply defines this architectural style". Newman instead clarifies the microservice approach by explaining it "as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development", which "has emerged from real-world use, taking our better understanding of systems and architecture to do SOA well".

The author also wisely points out that "microservices are no free lunch or silver bullet, and make for a bad choice as a golden hammer. They have all the associated complexities of distributed systems,and while we have learned a lot about how to manage distributed systems well (which we'll discuss throughout the book), it is still hard. If you're coming from a monolithic system point of view, you'll have to get much better at handling deployment, testing, and monitoring to unlock the benefits we've covered so far. You'll also need to think differently about how you scale your systems and ensure that they are resilient. Don't also be surprised if things like distributed transactions or CAP theorem start giving you headaches, either!"

As a consultant architect, I especially appreciated Chapter 2 ("The Evolutionary Architect"), because of the sections entitled "An Evolutionary Vision for the Architect" and "Governance Through Code", Chapter 4 ("Integration"), because of the summary that the author provides on integration technologies in the context of microservices, Chapter 5 ("Splitting the Monolith"), because it appeals to my recurring project role as data architect, and Chapter 11 ("Microservices at Scale"), because of the summary it provides with regard to what happens when microservice architectures grow from simpler, more humble beginnings to something more complex in the long-term.

That said, I do agree with other reviewers of this book that there is some overlap between the content provided by the author and what is available elsewhere, although my only real qualms relate to the development lifecycle chapters, which probably would have been better placed in appendixes at the back of the text or minimally as concluding chapters. And while the author does point out example by example throughout his discussions, a bulk of these examples are either text descriptions or explained via high-level diagrams, and it would have been helpful if real-world examples were provided at a lower-level technical level of detail, even if, as Newman notes, this space is moving fast.

Subscribe to Erik on Software

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe