New Book Review: "Microservices vs. Monoliths"

New book review for Microservices vs. Monoliths: The Reality Beyond the Hype, by Chris Richardson, Dan Haywood, Mike Gehard, Matt McLarty, Mark Little, and Adrian Cockcroft, C4Media (Publisher of InfoQ.com), 2017, reposted here:

This book brings together several previously published articles, blog posts, and presentations by individuals who have implemented successful, maintainable systems across the spectrum of monoliths to microservices. The first entry by Chris Richardson lays out guidelines for building a microservice architecture around the concepts of aggregates, event sourcing and CQRS (command query responsibility segregation). The second entry by Dan Haywood discusses "modular monoliths" and why they are a better option than microservices when working within a complex domain that does not need to support internet-scale traffic. The third entry by Mike Gehard walks through a recent migration from a monolith to microservices that is intended to help enable readers to make smart decisions around this type of endeavor. The fourth entry by Mark Little presents a Q & A dialogue with a panel of 5 developers and architects that discusses microservices in practice. The fifth entry by Adrian Cockcroft focuses on some underlying technology advancements that are creating a shift to event driven functions and improvements in time to value. Sandwiched in-between the third and fourth entries of this book is a brief 3-page article (in the form of a CA advertisement) that addresses the need for a common language for microservice architecture.

If you are looking for a place to start understanding some of the decision making will be required in your microservice architecture journey, I recommend starting here, but reading in a different order if you have never previously tackled this subject matter. Start with the second, third, and fifth entries entitled "In Defense of the Monolith", "The Journey from Monolith to Microservices: A Guided Adventure", and "Evolution of Business Logic from Monoliths through Microservices, to Functions", followed by the first entry entitled "Developing Transactional Microservices Using Aggregates, Event Sourcing, and CQRS", the fourth entry entitled "Virtual Panel: Microservices in Practice", and the 3-page article entitled "A Common Language for Microservice Architecture". The idea here is to read about the spectrum of monoliths to microservices in order so-to-speak, and then look to start looking at some specific ways to build microservices as presented by Chris Richardson (the founder of the original CloudFoundry.com) as well as getting a feel for what the community is saying about the place of monoliths and microservices and the direction things seem to be going. While most of the articles in this text are relatively technology agnostic, I like the fact that Mike Gehard (from Pivotal Labs) presents within the context of Spring Boot and Spring Cloud, and that the panelists explicitly mention technologies in the microservices space.

In my opinion, the first three entries of this book are especially well done (pointing to a possible reason why these are included first), as is the panel discussion that presents a lot of discussion points in a small amount of space. Some of the discussion coverage especially of interest to me are the challenges that developers face when writing microservices, the importance of using DDD (domain-driven design), how event-driven architecture can solve data consistency issues, how to choose between monoliths and microservices and the timing of this choice, how to best structure code projects to help enable a migration to microservices down the road, and the very opinionated do's and don'ts listed by the panelists. Some of my favorite don'ts: "Don't fall for vendor snake-oil – that's why SOA originally died a death" (James Lewis), "Don't throw away the years of developer experience and business logic already written. It's an evolution, not a new paradigm" (Martijn Verburg), "Don't approach microservices as a way to cut costs; Microservices is about enabling innovation and business outcomes through technology, not as a way to minimize operating costs, like traditional IT has been treated for decades" (Christian Posta), and "If you have trouble with CI/CD, APIs, DevOps, self-service platforms, or self-service teams, then don't force a microservices architecture; get the principles, practices, and organizational learning systems down first. Doing microservices isn't the goal; fast moving, innovative teams is the goal. Get the foundational pieces in place first" (Christian Posta).

Some of my favorite do's: "Prefer rapid remediation and canary deploys over integration testing" (James Lewis), "Build three prototype services that communicate with each other and figure out how to do all of the nonfunctional requirements like security, service discovery, health monitoring, back pressure, failover etc., before you go and build the rest" (Martijn Verburg), "Put developers and feature teams as close to their customer (or even in their customer's shoes) so they see the pain directly from the systems the teams build" (Christian Posta), and "Do pay attention to data. Data is the lifeblood of a company. When building services, pay attention to use case boundaries, transaction boundaries, consistency issues, and data processing (stream, storage, etc.)" (Christian Posta). Outside these do's and don'ts, I also appreciated the following comments: "Splitting a bloated monolith into smaller overcomplicated monoliths will only make the situation worse. In brownfield projects it is crucial to remove the cargo cult based patterns first, and re-learn the domain concepts. Splitting a lean monolith into independent units becomes a fully optional task." (Adam Bien), and "Forget about all modularization attempts from the past. Keep your code simple. Thin WARs are the ultimate module. Be paranoid and assume that the whole infrastructure around your service can and will fail. Test the behaviour in failure case. Provide the simplest possible solution (should be classes, not frameworks)" (Christian Posta). One of the only areas of the panel discussion with which I disagree are the references to the Gartner Hype Cycle, as technologies should not be expected to follow the curve over time, since many technologies come and go after making a relatively brief appearance.