Article URL: https://var0.xyz/posts/what-even-are-microservices.html Comments URL: https://news.ycombinator.com/item?id=49081594 Points: 18 # Comments: 25

It's almost impossible to have a conversation about software architecture without someone bringing up microservices. Just look at the discussion over my last post. They have become the default example of both "good architecture" and "over-engineering," depending on who you ask. What's interesting is that everyone seems to recognize a microservice when they see one, yet almost nobody can explain what actually makes something a microservice. How small is micro? Should a service do exactly one thing? Two? Is there a maximum number of lines of code? A thousand? Ten thousand? Nobody has convincing answers, because there aren't any. The industry has spent years trying to define microservices by technical characteristics, but those characteristics are surprisingly vague and fuzzy. The boundaries aren't measured in responsibilities or number of deployments per day. They're measured somewhere else entirely. And that's the important realization: microservices aren't primarily a technical abstraction. Listen to the reasons people usually give for moving away from a monolith: deployments are slow, tests take too long, builds are painful. These are real problems, but none of them require microservices. Every single one can be improved while staying inside a monolith. As companies grow, dozens or hundreds of engineers need to work independently. Teams need ownership. They need to release on their own schedules without constantly coordinating with everyone else. Microservices create boundaries that mirror organizational boundaries. That's their real value. You gain autonomy, but you lose centralization. Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.