The Shift Away From Serverless: Taking Back Control
Your no-BS weekly brief on software engineering.
Join 100,000+ developers
Serverless was supposed to be the future—scalability, cost savings, simplicity. Instead, companies are waking up to a different reality: rising costs, hidden complexity, and vendor lock-in. Even the biggest names in tech are backing away. One of them? The company that practically invented serverless—and even they couldn't justify it at scale. More on that in a moment.
If you don’t have massive traffic, a bare-metal server or VPS will handle your workload just fine. Have high traffic? Your infra bill will likely exceed what a dedicated server would cost.
Let’s break down why more developers are moving away from serverless—and what to do instead.
1. Serverless Isn't Actually "Serverless"
The first illusion of serverless is in the name. There are still servers—just ones you don’t control. The problem? You end up trading direct management for black-box infrastructure that can be unpredictable, expensive, and hard to troubleshoot. Need to debug a performance issue? Good luck tracing logs through a labyrinth of AWS Lambda invocations.
When you control your own VPS or dedicated server, you know exactly what’s happening. You can optimize for performance, debug in a familiar environment, and aren’t subject to the whims of your cloud provider’s architecture changes.
2. The Hidden Costs of Serverless
Serverless is often marketed as a cost-saving solution. Pay only for what you use, right? In reality, companies frequently discover that their cloud bills balloon as their workloads grow. The fine print of data egress fees, execution time pricing, and additional costs for services like managed databases quickly add up.
There is, however, one valid argument for serverless: handling high-burst traffic. Serverless can be beneficial in cases where workloads are highly unpredictable or experience significant traffic spikes. Auto-scaling serverless functions might be the simplest way to handle extreme loads without over-provisioning infrastructure. But this is the exception, not the norm.
For most applications, the premium you pay for the ability to scale instantly is not worth it. Instead of assuming serverless is the answer, first analyze whether a well-provisioned bare-metal server or VPS could handle even the busiest traffic. A solid VPS setup? Straightforward. No weird surprises, no unpredictable costs. Many workloads can be accommodated with traditional infrastructure at a fraction of the cost, without introducing unnecessary complexity.
Compare this to a VPS or a bare-metal server where pricing is predictable. You pay for a fixed amount of compute and storage, and you’re not charged for every individual request or execution cycle. The predictability of self-hosted infrastructure makes budgeting and cost management far easier.
3. Complexity Breeds Downtime
One of the most frustrating aspects of serverless is its complexity. Configurations become a nightmare, dependencies grow exponentially, and security concerns multiply.
Consider how many services need to be stitched together in a typical serverless setup: Lambda functions, API Gateway, IAM permissions, event-driven triggers, and managed databases. Each component adds another point of failure. And when something does go wrong? Finding the root cause in a distributed serverless architecture can be a nightmare.
By contrast, a well-configured server on a VPS is straightforward. Set it up once, lock it down, and move on. No surprise outages, no sudden pricing hikes, and no debugging through abstracted layers of cloud infrastructure.
4. Vendor Lock-in and the Cloud Flywheel
One of the biggest criticisms of serverless is vendor lock-in. Companies that go all-in on AWS Lambda, Google Cloud Functions, or Azure Functions often find themselves trapped. Migrating off these platforms isn’t easy—the more services you use, the harder it becomes to leave.
This isn’t an accident. Cloud providers have every incentive to keep you in their ecosystem. Just like traditional PaaS, serverless creates an environment where developers become specialists in AWS, GCP, or Azure rather than in underlying technologies. And when leaving the cloud becomes too costly or complex, businesses have no choice but to keep paying whatever the provider demands.
By moving back to self-hosted infrastructure, developers regain control over their stack. They can use open-source tools, deploy on their own terms, and avoid being held hostage by a single vendor.
Don't Believe Me? Good.
We should always view every solution with a skeptical eye. That’s why I look at those who have made the switch.
Take Basecamp, for example. They famously moved off the cloud and projected savings of \$7 million—then later revised it to \$10 million. They realized that self-hosting their infrastructure gave them more control, better performance, and massive cost reductions.
And they aren’t alone. More companies are beginning to rethink their reliance on cloud-based architectures, realizing that while serverless and managed platforms promise convenience, they often lead to hidden trade-offs in cost, reliability, and long-term flexibility.
Oh, and that company I mentioned earlier? It’s Amazon. Even they moved away from serverless and microservices because it simply didn’t make financial sense.
The Future: Taking Back Control
The shift away from serverless isn’t just about cost or complexity—it’s about autonomy. Developers are realizing they don’t need to depend on massive cloud providers to run their applications. With the right tools and knowledge, you can deploy, scale, and manage infrastructure in a way that’s predictable, cost-effective, and secure.
We’ve talked before about how Rails 8 is pushing against the PaaS model, making it easier than ever to deploy applications without relying on cloud providers. Tools like Kamal make deploying applications—whether running Rails or not—far simpler, allowing developers to take full advantage of self-hosted infrastructure while maintaining an easy deployment process.
If serverless is costing you time, money, and sanity, ask yourself: who’s really benefiting? You, or your cloud provider? Maybe it’s time to take back control.