Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud-Native Startups Are Going Back to Simpler Infrastructure
Transcript
- Lucas: Luna, I want to talk about something I keep hearing from founders and CTOs at early-stage companies — and it almost feels like a dirty secret. Luna: I'm intrigued. What's the secret? Lucas: They're pulling back from cloud-native complexity. Not abandoning the cloud — but deliberately choosing simpler infrastructure. Think plain old virtual machines instead of Kubernetes clusters. Single-region deployments instead of multi-cloud. Even some teams moving off serverless back to long-running processes. Luna: That sounds almost heretical given the last decade of cloud-native evangelism. What's driving it? Lucas: Cost — but not just the dollar figure on the AWS bill. It's the cognitive cost. I was talking to the CTO of a Series A company — about forty engineers — and he walked me through their infrastructure stack eighteen months ago versus today. Luna: What were they running before? Lucas: They had Kubernetes on EKS, three service meshes, a serverless data pipeline, and about a dozen microservices each with its own database. Total monthly cloud spend: around $85,000. Their infrastructure team was four people — and they were still drowning in YAML and on-call alerts. Luna: Four people for forty engineers sounds like a lot of overhead. Lucas: Exactly. So they made a bet. They consolidated everything onto a handful of EC2 instances — big ones — in a single region. They killed Kubernetes entirely. They moved from microservices back to a modular monolith. And they dropped the serverless pipeline for a batch job system running on cron. Luna: And the result? Lucas: Infrastructure costs dropped to about $56,000 a month — a 34 percent reduction. But the bigger win was that they eliminated one full-time infrastructure role. The remaining three people now spend more time on product features than on cluster management. On-call incidents went from about twelve a month to two. Luna: That's a dramatic improvement. But I wonder — are they losing anything in terms of scalability or resilience? Lucas: That's the obvious question. And the honest answer is: for their current scale, no. They're doing about $5 million in annual recurring revenue. Their traffic is predictable. They don't need to spin up hundreds of containers at a moment's notice. The complexity they shed wasn't serving any real business need. Luna: So it's not that Kubernetes is bad — it's that it was the wrong tool for their stage. Lucas: Right. And I think that's the key insight. The cloud-native ecosystem has become a kind of one-size-fits-all default. If you're a startup today, there's enormous pressure to adopt the same stack that Meta or Netflix uses. But those companies have totally different constraints. Luna: What about the argument that you should build for scale from day one — that refactoring later is even more expensive? Lucas: I hear that a lot — and it can be valid for certain types of businesses. But there's a growing body of evidence that premature scaling of infrastructure introduces its own costs. I've seen startups spend six months building a platform that could handle ten million users — while they only have ten thousand. That's six months they could have spent on product-market fit. Luna: So what's the alternative? Just run everything on a single server like it's 2005? Lucas: No, not that extreme. But there's a middle ground. I think the trend is toward what some people call 'just enough infrastructure.' You pick the simplest setup that meets your current needs, and you have a clear plan for evolving it when you hit real scale. Luna: Can you give me an example of what that looks like in practice? Lucas: Sure. Another company I've been following — they're a B2B SaaS, about 25 engineers — they run on a single PostgreSQL database and a handful of application servers behind a load balancer. They use a managed Redis cache for session storage. That's it. Their entire deployment is a script that runs on a virtual machine. No containers, no orchestration. Luna: And they're comfortable with that? No fear of downtime? Lucas: They have a disaster recovery plan — a warm standby in another availability zone. But they're not trying to achieve five-nines uptime. Their customers tolerate occasional brief outages because the product is good and the price is low. And the engineering team sleeps through the night because they're not chasing phantom alerts from a hundred microservices. Luna: That's actually really refreshing. There's been this arms race in infrastructure sophistication, and it's created a lot of burnout. Lucas: It has. And I think part of what we're seeing is a maturation of the industry. The early cloud-native hype was about what you could do. Now people are asking more seriously about what you should do for your specific business. Luna: I've also noticed that some of the loudest voices in the DevOps community are starting to advocate for simplicity. You see blog posts titled 'Why I Miss the Monolith' or 'Kubernetes Is Not for Everyone.' Lucas: Yeah, and those used to be contrarian takes. Now they're becoming mainstream. I think the pendulum is swinging — not all the way back to bare metal, but toward a more pragmatic middle. Luna: You know, it reminds me of something a senior engineer once told me: 'The best infrastructure is the one you don't have to think about.' Lucas: Exactly. And for a lot of startups, that means fewer moving parts, not more. Luna: This conversation is exactly the kind of thing that makes this show valuable — real trade-offs, not just vendor talking points. Lucas: And that's actually the reason we keep this show ad-free. We don't take money from cloud vendors or tool companies, so we can be honest about what's working and what isn't. Luna: Right. We want to be a resource you can trust. And if you find value in that, the best way to support us is a small contribution at buy me a coffee dot com slash fexingo. Lucas: It's a simple way to keep these conversations going without any sponsor influence. So, back to the trend — I think this simplification wave is going to accelerate, especially as more founders come from engineering backgrounds and realize they can build lean. Luna: Do you think this will change how cloud providers market themselves? Lucas: I think they're already adapting. AWS launched what they call 'simplified compute' options. Google Cloud has their 'GKE Autopilot' as a more managed Kubernetes. But the real shift is cultural. The next generation of startups might not default to Kubernetes. They might default to a single virtual machine with a good backup strategy. Luna: That's a big change from the 'cloud-native or bust' ethos of the past five years. Lucas: It is. And it's healthy. It means we're finally treating infrastructure as a means to an end, not as an identity. Luna: So for a founder listening right now, what's your advice? Lucas: Start with the simplest thing that works. Use a managed database. Use a single application server. Only add complexity when you feel real pain — not because a blog post told you to. And when you do scale, do it deliberately, not by default. Luna: I like that. It's almost a minimalist approach to infrastructure. Lucas: Yeah, and I think we'll see more of it. The cloud gave us infinite flexibility — but infinite flexibility has a cost. The next wave of smart engineers will figure out how to get the benefits without paying that cognitive tax. Luna: It's a good reminder that the best tool is the one you don't notice. Lucas: Exactly. So maybe the future of cloud isn't more layers — it's fewer, better-chosen ones.