Notes on Production-Ready Microservices
I recently read Susan Fowler’s book, and found it really helpful working in microservice architecture and in thinking about my own startup’s engineering culture. As a little background for where I’m coming from, my company runs all our workloads in containers, uses Kubernetes as our cluster manager, have completely separate development, staging, and production environments, and our main web application is written in NodeJS with a Postgres database.
The book provides a helpful summary at the end of each subsection outlining major points, so I won’t give a full book review here. Instead I wanted to produce a list of things that weren’t clear or didn’t make sense to me. Maybe the internet will help me out.
P10 & P34 — Susan advocates not versioning internal API’s of microservices. I get the argument that a service is organic, and that you can get clients using old versions. But by the same token, wouldn’t rolling out a new RPC endpoint to replace an old one (say with an additional parameter) have essentially the same problem?
P53 — On downstream dependent services. The most confusing thing around microservices for me is around initial development. Especially when breaking up a monolith, how does the process of simulating out all the downstream dependencies happen in development? With a monolith (say a webapp), its pretty easy for a developer to run (maybe in a container) a database, cache, etc. Do developers have a mini-sized full suite of services running locally to develop against? Or are just simple mocks used? Does that mean there is no end-to-end testing for the developer?
p93 — It was quite surprising to me to hear that load testing ought to be run against production systems. The part I don’t understand is from a reporting perspective, how do you separate load-testing traffic from true-user traffic? That may just be a service-level concern where an app must be instrumented properly.
p124 — I am sold on the need for proper runbooks so on-call developers have somewhere to start debugging a service, but I still think that this is an area where an example would be really helpful. I realize that a runbook is very service-dependent, but a little more descriptive format would be rally nice to see.
Overall, there are numerous ideas in the book that had me saying to myself “Oh, I need to do this,” or “That is a great point, I need to start doing it that way.” Most of the ideas and recommendations apply to organizations not running microservices, although I think the argument is well-made for it. For anyone serious about bringing their operational process to a new level, this book is a must-read.
