Review: Building Microservices

Building Microservices
Sam Newman
ISBN: 978-1-491-95035-7

Scale out where you can, scale up where you must.

Someone, somewhere, should probably start a collection of “where you can, where must” sayings, as these rules of thumb (thumbs were used by carpenters instead of a ruler to measure an inch, apparently) are important to remember, even if they’re imprecise. Route where you can, switch where you must — really refers to using layer 3 versus layer 2 networking as much as possible — for instance. Scaling out, from the perspective of network engineering, is all about repeatable modules, spine and leaf fabrics, and distribution of the control plane (didn’t think of that last one, did you?).

But what does scaling out mean in the application development world? It means splitting services into modular pieces which interact over the network. The ultimate goal of splitting services is to get to the microservice.

But what is a microservice?

To answer this question, you need to turn to the first chapter of Scaling Microservices, which says, “Microservices are small, autonomous services that work together.” Sam Newman, in the rest of the first chapter, explains the concept well, from a number of different angles, including the benefits of building microservices, the relationship between the service-oriented architecture, and other decomposition techniques that can be to pattern microservices. You won’t just learn about software development in reading this book, however — many of the principles and concepts are applicable to developing network designs, as well. For instance, the Single Responsibility Principle, which states —

Gather together those things that change for the same reason, and separate those things that change for different reasons.

If this sounds familiar, it should — it’s one form (with some modifications and additional precision) of the old rule of thumb — use failure domain boundaries to separate complexity from complexity.

In chapter two, the author examines the role of an architect in the world of software development. This is one of those “must read” chapters for anyone pondering what an architect is, and how the concept of architecture applies to information technology systems.

Thus, our architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.

The network is one of those systems, and a system in its own right. We need to stop seeking the perfect network, and seek a good set of frameworks within which networking systems can be built. We’re not quite that mature of a field of study. Chapter 3 discusses one of my favorite topics, models, and how to use them to model services. The more models you can stuff into your head, the more you’ll be able to deal with unknown situations in the future.

Chapter 4 discusses integration, chapter 5 how to split a monolithic application into microservices (sounds a lot like deploying a new routing protocol, or deploying a new technology in an existing network), chapter 6 on deploying microservices. Chapter 7 returns to material that will be of more interest to network engineers (though you should read all of them!), working through models and systems for testing. One thing we’re not very good at in the networking world is testing, and this chapter is a trove of good concepts and ideas. Chapter 8 covers another useful topic, monitoring. Again, the author has a lot of good thoughts and models the network engineer can apply from the software development world.

Overall, this is a really good book for network engineers to read. Not only are there good ideas that can be directly applied to the world of network engineering, you’ll also learn something about building and deploying software in the modern business environment — and I’ve added this one to my 60 books page.