I haven’t written anything in Books category this year, so it’s time to fix this. I have found Building Microservices by Sam Newman when browsing shelf of mini library next to the kitchen in our office, while waiting for my coffee. What caught my attention was a new and shiny book among bunch of uhm… mature ones. Besides, amongst all that noise regarding microservices in the industry, I thought it’s good to read some damn book instead of watching random talks from people shouting, “hey we did microservices in our company too, we are so cool and trendy!”. I like books, I’m old school.
Quoting the book cover itself:
“Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic applications to smaller, self-contained microservices. But developing these systems brings its own set of headaches. With lots of examples and practical advice, this book takes a holistic view of the topics that system architects and administrators must consider when building, managing, and evolving microservice architectures”
Yes, we can hear that everywhere now. You might have an idea that everyone has migrated to microservices or is in the process of it, but it’s bullshit. Most systems I’ve seen recently are nowhere near that, and it doesn’t seem to change anytime soon. So perhaps it’s good to rant about this on and on, but also investigate the topic a bit further that “hey we have to do this, everyone is doing it, let’s do this!”. There are pros, there are cons and there are traps that you should be aware of.
The author explores the topic in twelve chapters, let’s have a look.
Chapter 1: Microservices
Introduction and general ideas of what is going on in the book. Explanation of main benefits of microservice architecture, namely: technology heterogeneity, resilience, scaling, ease of deployment, organizational alignment and other things. It is not a silver bullet to solve all your problems though.
Chapter 2: The Evolutionary Architect
More about people than technology. The evolutionary architect has several key responsibility areas: vision, empathy, collaboration, adaptability, autonomy and governance. It’s no easy task! I like the idea of The Coding Architect, introduced alongside, as opposed to a detached from reality guy, with long white beard, that sits on top of ivory tower and silently drops uml diagrams on those below him.
Chapter 3: How to Model Services
Knowledge how to cut your business domain into particular services is often crucial. You want to balance skillfully around proper sizes and places to cut, in order to benefit from high cohesion and low coupling as well as proper alignment of your business and technology.
Chapter 4: Integration
That’s a long one. Your beautiful shiny services need to talk to each other, that’s the point of all that fuss. And boy, oh boy there are gazillion of ways how to do that. Synchronously, asynchronously, using shared database (don’t), RPC, REST, HATEOAS, HAL, JSON, SOAP… There are choreography, orchestration, versioning issues, spaghetti, strangers, stranglers, and lots of stuff to think about. My head hurts.
Chapter 5: Splitting the Monolith
So you have a rotting piece of sh… I’m sorry, a monolith, and you want to get your hands dirty and split it into a bunch of little nice services chatting happily among themselves? You will find a handful of useful techniques and ideas to keep in mind here. It’s all about seams.
Chapter 6: Deployment
We developed something, that hopefully works, and are trying to push it into production now, or at least somewhere outside our local machine. Let’s talk about continuous integration and delivery, artifacts, environments, configuration, automation, virtualization and the big fat blue whale with some boxes on its back, everyone is so hyped with nowadays.
Chapter 7: Testing
Different types and scopes: acceptance, explanatory, property and unit test. Pyramids, trade-offs, brittleness, stories, journeys. Also about smoke tests, blue/green deployments and chocking the poor canary for the greater cause.
Chapter 8: Monitoring
Is it dead, alive or both? Logs, metrics, correlations, synthetic vs semantic monitoring discussion and various tools and infrastructure to get insight from the noise of endless data. The author talks about Logstash, Kibana, Graphite, Varnish, Nagios, Zipkin, Riemann and Suro. Do you know all of them? No? Maybe you will find something new and useful then.
Chapter 9: Security
Don’t implement your own cryptography, stupid. Unless you have a PhD and few years of experience in it, then… still don’t. Read about authentication, authorization, SSO, perimeters, SAML, OpenID, certificates, HMAC, confused deputy problem, firewalls and remember that in the end, the weakest link in it is always between keyboard and chair.
Chapter 10: Conway’s Law and System Design
“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. How to use this law to your advantage? Chapter describes alignment of technology with communication pathways, service ownership, internal open source, custodians and people behavior in general.
Chapter 11: Microservices at Scale
So your software product turned out to be extremely successful and the traffic is booming? There are many ways to deal with it, as well as with failures that, with scale, becomes statistics rather than incident. We can read about degrading functionality, antifragility, circuit breakers, bulkheads, load balancing, scaling databases, CQRS, cache poisoning, CAP theorem, Zookeeper, Consul, Eureka and more.
Chapter 12: Bringing it All together
Summary of the book, culture of automation, decentralization, independence, isolation, observability and ideas when we shouldn’t use microservice architecture.
Recently I was reading mostly books on one particular technology (like Hadoop, Spring, Hibernate, Angular, Git…), so holistic topic is a nice variety for me. I needed some good, coherent and rich story on microservices from the beginning to the end and I think I got one. The author explains various aspects of the topic, provides options, pros and cons, examples, tool and ideas to think about. All of that in a clear and pleasant narrative from someone who feels like he knows what he is talking about. If you work with an older system, want to change something, perhaps been to talk or two on the subject and need more extensive and organized information, this book is just for you.