Microservices are often presented as an inevitable evolution of software architecture. The rationale goes something like this: once your codebase reaches a certain age or size, gravity itself pulls you toward service boundaries, containers, and a mesh of APIs because that’s the only way for to survive.
Monoliths, they say, are the past. Microservices are the future.
The framing of this rationale is convenient. It suggests progress without forcing to evaluate cost.
One way to think about microservices is as a patchwork road. You can absolutely get where you’re going. The road technically connects point A to point B. But every few meters the surface changes: asphalt gives way to gravel, gravel to concrete, concrete to something poured by a different contractor with different tools and assumptions. You’re constantly adjusting your speed and expectations.
From a distance, the road looks impressive. From the driver’s seat, it’s exhausting.
All Roads Lead to Rome
Roman roadbuilding is still admired today because the Romans optimized their process for durability and clarity of purpose. They were absolutely over-engineered, brutally simple, and designed to last. They assumed that coordination and planning up front would pay dividends for decades. The result was infrastructure that vastly outlived the empire that built it.
Modern software infrastructure, by contrast, often rewards local autonomy above all else. Microservices promise that each team can move independently, deploy independently, fail independently. In theory, this sounds like resilience. In practice, it often looks like replacing a single well-understood system with a loose federation of partially understood ones.
We have traded a Roman road for a thousand goat paths and called it scalability.
Each microservice is small, clean, and easy to reason about… when viewed in isolation. The problem is that production systems do not run in isolation. They run as complex graphs. And graphs have emergent behavior that no single service owner fully understands.
The Romans understood something modern software teams often forget: infrastructure is not about components, it’s about continuity.
The Illusion of Modularity
Microservices sell modularity as their core virtue. Change one service without touching the others. Scale one bottleneck without scaling the world. Deploy fearlessly.
But this modularity is largely illusory. Business logic does not respect service boundaries, failure situations even less. And above everything else, latency compounds aggressively, regardless of how elegant your API contracts look in a diagram.
Jimmy Bogard has a great presentation “Avoiding Microservice Megadisasters” focusing on Bell Computer’s all-in web service rewrite, achieving maximum efficiency and development velocity through microservices. For a pre-production launch, the system was started up… and the front page took over 9 minutes to load.
Each team had assumed zero latency. The tens of thousands of individual calls across services compounded into a system that ground to a complete halt when used.
What actually happens is that complexity migrates. The system becomes less complicated in any one place, but more complex everywhere. Simple issues become:
- Network behavior
- Retry logic and circuit breakers
- Distributed tracing systems required just to answer “what happened?” (see the linked lecture above for a good example of this)
This is the patchwork road again: a single segment looks great, but the ride as a whole is rougher than expected.
Complex tracing of issues is key for e.g. maintaining VFX render farms. Since they often comprise of hundreds of physical servers, storage systems, varying high-speed networking conditions, sometimes the only way to see where things are bottlenecking or outright going wrong is to create a real-time visualization of the data stream.
I once had the pleasure of creating such a visualization system, using thousands of SNMP data points gathered every few seconds from hundreds of sources, with multiple frontends. One was a complete 3D model of the server room, with network ports and CPUs lighting up as they got utilized. This ran on a large TV on the wall of the maintenance team. If you saw everything go to red, then turn off, you knew within seconds something was up.
The same concepts of troubleshooting become increasingly important if a system is completely built out of microservices. As a developer, you may want to think ahead and provide endpoints for important service metrics from day one.
When Microservices Make Sense
None of this is an argument that microservices are “bad” in any sort of way. They solve real problems – just not the ones they’re very often adopted for.
They make sense when:
- Organizational boundaries already exist and are hard to change
- Failure isolation is more important than global correctness
- Teams are mature enough to operate infrastructure, not just write code
They do not make sense as a default response to a large codebase, or as a premature optimization for “future scale” that may never arrive.
Monoliths can be built to scale too. That’s how everything used to be built. That’s why we have load balancers in the first place. That’s why people used to learn to optimize. That’s why developers used to be memory conscious.
Microservices for the sake of scaling are almost always the wrong answer.
Microservices might be the right answer for other reasons.
A well-structured monolith with clear internal boundaries often behaves more like a Roman road than a microservice mesh ever will. Sure, It’s boring and predictable. But it’s also easy to repair. And above all, understandable.
Infrastructure as Archaeology
One day, someone else will inherit your system. They won’t care how modern it was when you built it. They’ll care whether they can trace a request without needing six dashboards or pulling someone from a skiing holiday.
Roman roads survived because they were built with a clear mental model of how people would use them. Patchwork roads exist because each segment was built to solve a local problem.
The real question isn’t whether microservices are the future. It’s whether we’re building roads meant to last, or just something that technically gets us there, no matter how bumpy the ride.
Leave a Reply