I’ve heard many good things about microservices but have had only limited opportunities to try them out. I wanted to learn more and Microservices Patterns by Chris Richardson was the perfect opportunity.
I know there are no silver bullets in software development and Richardson reminds us immediately. Architecture is all about tradeoffs and microservices architecture is no different. The best part of this book is that every pattern is presented with the benefits and drawbacks of that pattern.
In fact Richardson suggests that you start off with a monolithic approach – not microservices. For most applications, this is all you need. This is a core point of microservices – you may not need it – and its one I don’t see enough practitioners pay attention to. However I’ve wondered if it’s worth taking that idea to the extreme – that you never need microservices. This book convinced me otherwise.
There’s not a clear point when microservices is “better” to use than a monolithic architecture, but this book outlines the signs that it may be time:
- Your application keeps growing in code and developers
- Complexity increases to where no one person can keep the application in their head any more
- Development velocity slows down
- Changes take a very long time to test because you don’t know what parts of a test suite to run
- You’re feeling a “lock-in” to old technology but a rewrite would take too long
Richardson convinced me – there are definitely cases where microservices make sense! At the very least, it seems inconceivable to run an internet-scale technology like Amazon without microservices. And since microservices sometimes make sense, I wanted to learn more about the situations where they help, and more importantly, why they help.
The central premise is that smaller pieces, even if not “micro”, give you more degrees of freedom. If an application has four major pieces, it’s difficult to get all four pieces coordinated for lock-step deployments. It’s much easier if any decision only affects one-fourth of the whole – whether that decision is an implementation detail, a testing detail, or a runtime detail.
Still separation is never that pure and even if you focus on one component it can still affect the others. My concern with microservices is that it can be difficult to coordinate design, implementation, and test across services. Many people have noted that microservices moves complexity from the implementation code to the deployment runtime. I shudder at the thought of debugging a production issue that touches four different services. But after reading this book I realize that it would still be difficult to debug (and fix) an issue in a monolithic application if the issue had that many elements.
Microservices doesn’t claim to solve this cross-service issue. The implicit argument is that the cost of difficult cross-service issues is balanced by the other benefits from having smaller, independent services. I’ve not worked on a system large enough to require this, but I can appreciate the argument.
The biggest challenge in moving to microservices is changing the development mindset. You have to re-think how transactions are implemented. Rather than having atomic transactions with ACID (Atomicity, Consistency, Reliability, and Durability), you have distributed sagas with BASE (BAsic Availability, Soft State, Eventual Consistency). This improves scalability and availability at the cost of thinking through how to deal with eventual consistency.
The two biggest challenges I see in microservices are first designing the right service boundaries, and second understanding how to program with BASE instead of ACID.
One thing I had not realized was that microservices may have to use data replication to reference data not in their service. The book uses an example including Order and Delivery microservices, where Delivery depends on Order. The Delivery service may end up replicating an Order table in its own datastore to support efficient queries, rather than using Order’s API every time. Several chapters in the book describe messaging and data replication strategies that help with managing distributed state, while still allowing (mostly) independent services.
Lastly, a microservices architecture adds a lot of concerns that need to be handled including distributed tracing, service discovery, partial failure modes, load balancing, and more. I came to appreciate this is why service meshes, like Istio, have emerged. Instead of heaping dozens of more responsibilities onto service developers, service meshes are introduced to pick up part of the load.
Overall this was a very insightful book. Every solution is presented with benefits and drawbacks and this is the essence of architecture. I now understand many of the design points in my own IBM Cloud and other applications I’ve worked with. Thanks Chris for a great book!
2 Comments