The problem isn’t cloud or microservices: it’s the illusion of scale

After discussing how cloud doesn’t solve team immaturity in previous articles, an almost inevitable question comes up: if it’s not the technology, then where is the problem?
The answer is usually less comfortable than it seems. Most of the time, the problem lies in how we think about scale.

The rush to look big

There’s a pattern that repeats across many teams. Before even getting the basics right, there’s already a push to scale: distributed architecture, elastic infrastructure, complex pipelines, full observability. All of this before having clarity about the product, business understanding, domain knowledge, and most importantly, the delivery flow itself.

It’s like trying to optimize a system that doesn’t even work properly yet. Only now, with more technology involved.

• Scale what, exactly?

This is a question that rarely comes up. When we talk about scaling, what are we actually talking about? Users? Requests? Teams? Complexity? Or are we just replicating a model we’ve seen in companies that were already at a completely different stage?

Because there’s a huge difference between scaling volume and scaling problems. And many teams end up doing the latter without realizing it.

• Architecture becomes the goal (and now AI does too)

At some point, architecture stops being a means and becomes the end. Microservices start being adopted not because there’s a clear need, but because they represent a modern standard. Cloud follows the same pattern: not as a strategic decision based on context, but as an expected move.

This is one of the clearest signs of the illusion of scale. The system becomes more sophisticated, more distributed, more technological. But the value delivered doesn’t grow at the same pace.

In practice, the team starts spending more energy maintaining the structure than evolving the product. And at that point, architecture stops being an enabler and becomes a burden.

Scale is not the natural next step

There’s an implicit narrative that every system needs to scale. But that’s not true. Many systems need, first and foremost, to work well, to be predictable, and to be easy to maintain.

Scale is a consequence of real need, not a mandatory stage.

Before any technical decision, there are other things that should scale first: domain clarity, decision-making capability, ownership within the team, and delivery quality.

Without that, any attempt to scale technology only increases the surface area of the problem.

Cloud is not the problem. Microservices aren’t either. They just make more visible a decision that was made too early. The real problem is the illusion that scaling is always the next step, when in reality, most teams still need to evolve their foundations.

Before growing outward, you need to grow inward. Otherwise, scale doesn’t amplify success. It amplifies failure.