What’s the real point of Microservices? – should I start with Monolith

In my view, most of the hype around microservices got the concept totally wrong.

The point of microservices

is that we want to organise code in such a way that we have small independent systems that each do well-defined job. The original microservices post said that microservices were “organised around business capabilities”, which is a term of art from service oriented architecture, where we look for the things that a business does.

You can identify business capabilities by building a flow chart showing how your organisation generates value, and the key activities that happen at each step. You draw circles around the activities that cluster together neatly, due to required knowledge or resources, and those are business capabilities: Billing, Shipping, User Management, etc.

The point is that when you need to modify code that relates to a particular business activity, it’s in one well-segregated codebase, and that codebase can evolve according to the pressures of that business capability without affecting anything else. That’s really handy as your org gets larger, and you need to have individual teams who look after the Shipping function, or the Billing function, but it’s also a sensible way to build software generally once it gets past a certain size.

The teams at Thoughtworks who named the microservice style were deeply influenced by Domain Driven Design, and by the earlier “Guerilla SOA” approach, also pioneered at Thoughtworks, that emphasised messaging and ReST to connect discrete services, without centralised authority.

In the software community

What happened is that the wider software community heard about this microservice thing, and didn’t have the background understanding of DDD or message oriented systems, and misapplied it to mean “make lots of tiny things that communicate over RPC”.

This is a disaster. Big tech companies wrote insane blog posts where they bragged about the 10,000 microservices they were running in their k8s clusters with a fancy RPC lib written by a central platform team. Reddit swarmed with excitable engineers who wanted to know how to build a graphql backend-for-frontend for their 50 tiny rpc services, so that their React app wouldn’t suck so much. After a while everyone realised this was an insane thing to do. Uber, famously, wrote a blog post where they said that they were moving away from microservices to adopt “Domain Services”, in which they rediscovered things like bounded contexts, and autonomous components, and all the other stuff they’d ignored the first time around.

Where does that leave us?

Pretty much where we’ve always been. Start with a monolith. When you realise that you need to introduce another axis of change, because of throughput, or stability, or release velocity, or sheer bigness, separate services out. Build those services around business capabilities, prefer smart endpoints and dumb pipes, and pay attention to boundaries and contract evolution. Don’t build a thousand tiny things. Don’t mistake autonomous components for standalone services. Don’t use RPC.