It happened again last week. I was at an architecture review meeting when a fellow architect eagerly started another debate about *microservices*. Within minutes, eyes glazed over and we were knee-deep in an absurd discussion about something that should have been a means to an end, but had morphed into the end itself. At that moment, I realized: I’m done. I’ve finally sworn off talking to architects about microservices. Why? Because these conversations usually go nowhere productive.
I’ve boiled my frustration down to three problems:
This is the most obvious problem. There’s no formal definition of what a microservice is, so when people talk about them, they often end up talking at cross purposes.
Here are some definitions out there:
While some of these overlap significantly with one another, the differences of emphasis combined with the loose way we discuss them, we end up with the "blind men and the elephant" scenario: everyone’s correctly describing something slightly differently, so no-one is ‘wrong’, but we’re certainly not aligned.
(I discussed this confusion about what a microservice is here when talking about Amazon Video’s so-called microservices to monolith move.)
After enough of these debates, I’ve found it simpler to ban the term “microservices” altogether. If a term causes this much confusion, maybe it’s outlived its usefulness.
Instead of arguing about what to call our architecture, we could be talking about concrete challenges, or specific trade-offs: how to deploy new features faster, how to reduce coupling, how to scale parts of the system. In other words, microservices (whatever you decide they are) are not an end in themselves, but a by-product of achieving some other goal.
This isn’t just a microservices issue: it’s a broader problem in our industry. We throw around big words that sound impressive but mean wildly different things to different people. Consider these terms, and their histories:
Each started with a well-defined intent, but over time they’ve been stretched and contorted to mean whatever the speaker wants to advocate or criticise. With such sloppy definitions, is it any wonder our conversations go in circles?
(As an aside, I’d like to give props to GitOps. This term has been relatively stably used, thanks mainly to a clear original definition (now, sadly, gone from the internet along with the term’s creators, Weaveworks) that was not easily perverted for commercial purposes.)
Closely related to the first problem, discussions about microservices are often detached from any tangible business goals. If you ask "What business problem are we actually solving?" you’re often met with vague responses like:
If you listen closely, many of these conversations about microservices are not actually about architecture, but about wanting to work for a different company, where technology is cutting-edge and problems are theoretically interesting, rather than legacy-ridden and constrained by real-world trade-offs.
The sad reality is that many teams embarking on a microservices migration would be better off staying with a well-structured monolith until their scaling needs genuinely demand a different approach. Sam Newman, author of Building Microservices, frequently warns that most organizations should not start with microservices unless they have a compelling reason.
Again, it would be far better to stop talking about microservices. Start talking about reducing cycle time, improving reliability, and solving concrete business bottlenecks. If breaking up a system into smaller services is the best way to achieve those outcomes, fine, but angels on a pinhead discussions among architects about microservices are not the way to get there.
Another critical consequence of engineers discussing microservices in isolation from the business context is that they more often than not ignore the organisational changes required to make microservices work.
Microservices don’t work in a vacuum. They require teams to be structured in a way that supports them. That means:
If your organisation isn’t willing to make these changes, microservices will only make things worse. Adding technical complexity while keeping all the old organizational inefficiencies. In short, tech should follow business needs, not the other way around.
Most people that discuss microservices either don’t appreciate this, or don’t appreciate how hard this is. Changing your organisational structure is far harder than changing your software architecture when your business is over a trivial size. This is why small startups can ‘pivot’, and change their software architecture so quickly: their organisation structure can be changed as soon as everyone agrees on the architectural changes.
I’m well aware of the irony here: I’ve talked about how I’m not talking about microservices anymore. And with that, I'll shut up, and never speak of it again.