EXPEDIA GROUP TECHNOLOGY — SOFTWARE
Microservices Are Not a Technical Solution, They’re a Teamwork Solution
The first answer to “make this more reliable” isn’t “make it a set of microservices”
Here in Expedia Group™️, we’ve developed a short 2-hour introductory session on reliability engineering. The session has a short exercise at the end with a simple architecture, and we ask the students for suggestions to make it more reliable.
Inevitably the first suggestion is to break up the large central service into microservices. It’s not surprising. Microservices seem to be touted as a benefit for so many reasons. But the answer is wrong. It’s very simple to see why. Take a set of components all working together in a service, and do nothing other than break them up into separate services so that each component is now a service communicating with the other services. All you have done is introduced many more points of failure into your system — each inter-component communication (which would have an incredibly low failure rate) has now become an inter-service network call (or at minimum inter-process call), with a much higher though still low chance of failure.
So why the microservice hype? Don’t they have all those other benefits, like being able to scale parts of your system independently, loose coupling, etc.? Actually, all of that can be done relatively straightforwardly in a large monolithic service, with greater reliability. Microservices are primarily a solution to people’s inability to rigorously maintain separation of concerns. As you build your system, you use what is simple and quick and useful for the feature you are developing, and it doesn’t really matter during development whether lots of other things use a component or how they use it. Indeed, that simple and quick implementation is exactly what microservices are about. But do those simple and quick implementations a lot and when you combine them all you end up with a spaghetti service, everything linking internally to everything else. Which is fine if that’s a small enough bowl of spaghetti; you can still figure things out and fix problems.
But here’s what happens when teams and codebases grow:
- Code gets to be a huge tangled web that’s too extensive for anyone to understand.
- It takes days to figure out just a small subset of the system because it’s so intertwined with so much.
- That leads to difficulty in debugging a new issue that has cropped up in code you haven’t seen before.
- Changing code causes unforeseen bugs in other parts of the code that depend on the behavior you changed.
It’s when you’ve reached this point with your monolith that you see the benefit of microservices. Using microservices keeps things small and single-purpose enough to be easily understandable and maintainable. You can work your way through a microservice and understand how the inputs get transformed to the outputs.
Microservices are the answer to teams getting too big or too many teams working on the same code, and throwing too much code into one big mix. The only realistic way to maintain a huge amount of code is to have the code separated into digestible chunks. And that’s what a microservice is. Everything else microservice-related, whether benefit or disadvantage, is secondary.
Images are from Unsplash, from Christine Sandu (the uncooked spaghetti), Chang Duong (the nice spaghetti dish), and Wilhelm Gunkel (the massive tangled web of strands).
