What Even Are Microservices?
This article argues that microservices are primarily an organizational solution rather than a purely technical one. It suggests that companies adopt them to manage team autonomy and ownership as they scale, rather than to solve specific technical bottlenecks.
Why it matters
Understanding the organizational drivers behind software architecture helps engineering leaders make better decisions about when to adopt complex distributed systems.
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.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in