New Book Review: "Migrating to Microservice Databases"
New book review for Migrating to Microservice Databases: From Relational Monolith to Distributed Data, by Edson Yanaga, O'Reilly, 2017, reposted here:
This book addresses a much-needed topic in microservices architecture: the database in the context of microservices. However, after reading several other books on microservices architecture, I found that much of the early content here does not really cover what will likely be expected by readers, based on the title. In my view, the one exception is the fact that the author addresses the monolith-first approach (also called the strangler pattern), and quotes Martin Fowler as writing that "almost all the successful microservice stories have started with a monolith that grew too big and was broken up", and "almost all the cases I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble".
Yanaga furthers these thoughts: "Having a stable monolith is a good starting point because one of the hardest things in software is the identification of boundaries between the domain model – things that change together, and things that change apart. Create wrong boundaries and you'll be doomed with the consequences of cascading changes and bugs. And boundary identification is usually something that we mature over time. We refactor and restructure our system to accommodate the acquired boundary knowledge. And it's much easier to do that when you have a single codebase to deal with, for which our modern IDEs will be able to refactor and move things automatically. Later you'll be able to use these established boundaries for your microservices."
"The usual candidates for the first microservices in your new architecture are new features of your system or changing features that are peripheral to the application's core. In time, your microservices architecture will grow just like a strangler fig tree, but we believe that the reality of most companies will still be one, two, or maybe even up to half-dozen microservices coexisting around a monolith." And following this train of thought, the author explains that the challenge of choosing which piece of software is a good candidate for a microservice requires Domain-Driven Design (DDD) knowledge, a discussion which also helps set the stage for the material presented later in the book.
Readers like me who have been using database change management tooling such as Liquibase for quite some time can safely skip Chapter 3, but one thing worth mentioning here is that the author provides a good sidebar at the end of Chapter 1 around the topic of nonrelational database products. As Yanaga comments, while nonrelational database products have often been successfully implemented and used, he still recommends that readers begin their microservices journeys on the safe side by first using the existing relational databases around which their monoliths have been built, and then determining whether use of another type of database technology might be better after integrating a first microservice. Simply stated, the microservices journey is not trivial and probably will not be the best time to introduce a new database technology.
In my view, Chapter 5 (in combination with Chapter 4, which discusses CRUD and CQRS) was the most beneficial for my microservices journey. In this chapter, the author presents 9 different database migration strategies: (1) shared tables, (2) database views, (3) database materialized views, (4) database triggers, (5) transactional code, (6) ETL tooling, (7) data virtualization, (8) event sourcing, and (9) change data capture (CDC). Across this presentation, the author provides quite a few helpful considerations that need to be made as part of the decision making process. Potential readers might be interested in knowing that the author introduces a new open source project called Debezium as part his discussion on CDC. As a PostgreSQL user who experimented last year (2016) with an open source project called Bottled Water, I was particularly interested in this solution after discovering that PostgreSQL support was added just a few weeks ago (February 2017) with version 0.4.0.