A Comically Complex Cloud.

The Promise of the Cloud

Once upon a time, the cloud was sold as a minor miracle. Racking hardware and dealing with midnight failures was replaced by logging in, spinning up some servers, and scaling effortlessly as your next disruptive idea conquered the market.

Developers were promised freedom, and businesses were promised speed, flexibility, and lower costs. And to be fair, the cloud largely delivered. Launching digital products became dramatically simpler.

Infrastructure stopped being the main blocker to getting things live, and developers could go from zero to production without begging an ops team for favours. For a while it genuinely felt like the future had arrived, and it was pleasantly low maintenance.

When Simple Became Sophisticated

But things began to change as adoption grew. At first it was subtle, with a little more configuration here, and an extra cloud service there. Eventually though, even deploying a modest web application started to involve many cloud technology decisions in a lot of organisations, each with its own terminology, obscure config, and strongly worded best practices.

Some of this sophistication was justified. Security standards, compliance regimes, and customer expectations are much stronger than they were 15 years ago, and aren’t optional in many environments. But even so, unnecessary complexity has built up, and what was once a straight line to getting things live has slowly turned into a maze.

The Comedy of Complexity

The farce becomes obvious when trying to get work done. Development changes that could once be made quickly now require planning sessions, architecture diagrams, permission reviews, pipelines, and documentation updates. Developers joke about it amongst themselves, but that’s largely because the alternative is weeping quietly into their backlog.

Some of these steps are genuinely useful, especially in larger teams, but others exist mainly because the complexity of cloud infrastructure requires them to. The distinction is rarely clear in the moment, and so process accrues by default.

Non-technical colleagues feel the effects too, even if they cannot easily name the cause: meetings multiply, timelines stretch, and the senior engineers are saying “It depends” even more than usual.

Convenience Isn’t Free

Convenience always has a price, and in the complex cloud it’s rarely paid upfront. Engineers deal with poor local development environments, increased cognitive load, constant context switching, and the low grade anxiety of knowing one wrong step in a deployment plan could cause real damage. Iteration slows, not because people are lazy, but because the systems they operate demand constant care.

Businesses feel it too. Cloud bills can be eye-watering, but the quieter costs are often more significant: longer onboarding, fragmented ownership, and fewer people who truly understand how their systems work. The convenience is real, but the costs compound.

Who Is All This Actually For?

Much of this complexity makes perfect sense if you are operating at planetary scale, where downtime costs millions and traffic graphs look like mountain ranges. Optimising for resilience, compliance, and blast radius reduction at that size is entirely rational.

Most businesses are not planetary, though. They are shipping fairly ordinary CRUD software to fairly ordinary numbers of users, under real but limited constraints. They still need backups, security boundaries, and safe deployments, but they are often optimising far ahead of their actual risk profile. Problems that might one day exist are paid for every day, in both money and momentum.

How We Got Here

Nobody deliberately set out to make things this complex, but incentives nudged us in this direction. Vendors sell solutions designed for their biggest most valuable customers, and smaller organisations copy them thinking those solutions must be right for them too.

There’s also fear to contend with. Fear of getting things wrong, fear of audits and outages, fear of being seen as unprofessional, and fear of lack of career advancement without experience in every cloud service under the sun. Complexity becomes almost a kind of institutional armour for development teams. It offers protection, but it is heavy, it slows you down, and it prevents people from delivering excellent software.

Simpler Doesn’t Mean Reckless

Somewhere along the way, cloud complexity became synonymous with maturity. In reality, simpler approaches often require more judgement. They require understanding which risks actually matter, which standards truly apply, and where it makes sense to just keep things simple.

Building what you truly need is not reckless, it is intentional. There is nothing impressive about infrastructure nobody fully understands, regardless of how many obscurely named cloud services it uses.

A Different Kind of “Modern”

A more grounded approach is entirely possible. It favours fewer moving parts, clear ownership, and systems a developer can reason about end to end, while still meeting real security and compliance needs. Modern does not have to mean maximalist.

This is about principles rather than nostalgia. Aim for clarity over cleverness, proportionality over abundance, and technology that supports the work, rather than becoming the work itself.

The cloud is not broken, and complexity is not inherently evil. Every cloud service has its use cases, and removing them blindly is just another kind of irresponsibility. The problem is complexity that accumulates by default, without anyone stopping to ask what it is buying them.

Often, the most powerful infrastructure decision a team can make is simply to pause, take stock, and decide what they can do without.