Infrastructure in 2035: Steve Wade on Making Infrastructure Boring Again

Terraform has been my go-to for one reason: it's boring, and boring is good for infrastructure. I've done 50+ migrations. The successful teams used Terraform for one thing – managing cloud resources declaratively.

But here's where it breaks down: state management at scale. I've seen a £2M project nearly fail because someone corrupted the state file. Another client had 47 different state files because they feared the blast radius. That's not sustainable.

This is precisely why I created my "CNCF Reality Check" assessment – to help teams avoid these £2M mistakes before they happen.

I've seriously evaluated the alternatives. Crossplane? Brilliant idea – Kubernetes managing infrastructure. But after watching three enterprises try it, I'm skeptical. The problem? Your team now needs to be experts in both Kubernetes AND infrastructure provisioning. One financial services client spent 4 months trying to get Crossplane working before calling me to rip it out.

Pulumi? I love using real programming languages for infrastructure. But developers treat infrastructure like application code. It's not. Plus someone always writes "clever" infrastructure code that no one else can understand.

This is where I get controversial: Kubernetes operators for infrastructure are solving the wrong problem.

The promise sounds amazing. Infrastructure that heals itself. Continuous reconciliation. GitOps everywhere. But here's what actually happens: Your PostgreSQL operator decides to "reconcile" your production database at 3 AM. It sees a config drift as the desired state. Suddenly, you're explaining to the board why the infrastructure "fixed itself" into an outage.

This is precisely the kind of expensive mistake I help teams avoid in my monthly masterclasses, where I show which parts of your infrastructure should use operators and which shouldn't. This one decision can save you thousands.

I've successfully implemented operators for stateless infrastructure. Load balancers, DNS, certificates – these work well. But for stateful infrastructure? It's a nightmare. One telecom client had their Kafka operator "helpfully" rebalance partitions during Black Friday. That cost them £500K in lost sales.

The model makes sense for cattle infrastructure – things that can be destroyed and recreated without consequence. However, most enterprise infrastructure is comprised of pets pretending to be cattle. Until we accept that, operators will cause more problems than they solve.

This question hits at something I see every week: we've made infrastructure so complex that only a priesthood of experts can manage it. This complexity is why 73% of Kubernetes migrations fail – a stat I share in my newsletter along with how to avoid being part of that statistic.

I'm watching System Initiative closely. The real innovation isn't the visual interface – it's the real-time feedback loop. When an architect can instantly see that their beautiful design will cost £50,000 per month, that's powerful. However, my concern is that every visual tool eventually encounters the "escape hatch" problem. What happens when you need something the tool doesn't support?

I've seen Brainboard demos that made executives understand their infrastructure! However, when the team attempted to implement their existing Terraform modules, they encountered wall after wall.

The future isn't visual OR code – it's both. Visual for reasoning and planning, code for precision and repeatability. The tools that will win are those that allow you to transition between both modes seamlessly. Think Figma for infrastructure – you can design visually but drop into code when needed.

By 2035, most infrastructure work will be conducted conversationally. Not chatbots writing YAML (please no), but infrastructure engineers having actual dialogues with AI systems that understand context, trade-offs, and business requirements.

This shift is why I now focus on teaching pragmatic simplification. The engineers who'll thrive in 2035 aren't the ones who can write the most complex Terraform – they're the ones who can simplify complexity into business value.

Picture this: "I need a Kubernetes cluster for our new payment service. It needs to handle 10K transactions per second, comply with PCI DSS, and cost less than our current setup."

The AI responds: "Based on your requirements, I recommend a 15-node cluster across three zones. This exceeds your TPS requirement by 40% for burst capacity. For PCI compliance, I'll enable encryption at rest, network policies, and Pod Security Standards. Total cost: £8,500/month, 23% less than the current rate. Should I show you the trade-offs if we reduce to 12 nodes?"

However, and this is crucial, the AI shows its work. Every decision is traceable, every trade-off explicit. Because when that cluster fails at 3 AM, you need to understand WHY those decisions were made.

The engineers of 2035 won't write HCL. They'll be infrastructure architects who understand business requirements, compliance, and cost optimization deeply. They'll guide AI systems that handle the implementation details while they focus on the complex problems: What should we build? Why? What are the trade-offs?