I remember the exact moment I decided to break up with my server.
It was 2018. I was sitting in a coffee shop, staring at a terminal window, watching a sudo apt-get update crawl by on a $5 DigitalOcean droplet. I was managing SSL certificates manually using Certbot. I was configuring Nginx reverse proxies by hand. I felt like a mechanic covered in grease, keeping an old reliable sedan running.
Then, I saw the light. Or rather, the marketing.
“Go Serverless!” the headlines screamed. “Scale to zero! Pay only for what you use! No more patching! No more SSH! infinite power at your fingertips!”
It sounded like paradise. The promise was seductive: If nobody uses my app, I pay zero dollars. If a million people show up overnight, the infrastructure magically expands to hold them, and I just pay a fraction of a cent per request. It felt like the future. It felt like moving from a manual transmission car to a teleportation device.
So, I migrated. I tore down my monoliths. I shattered my beautiful, cohesive codebases into dozens of tiny, ephemeral Lambda functions. I wrapped everything in API Gateways. I embraced the “Modern Stack.”
And for the first three months, it was glorious. My bill was literally $0.04.
Then, the honeymoon ended. I launched a new feature—a simple background image processor—and woke up three days later to an alert from my bank. My “pay for what you use” model had decided to use my entire rent money.
But the financial cost was just the tip of the iceberg. As I dug deeper into the wreckage of my bill, I realized that the true cost of Serverless wasn’t just on the invoice. It was in the complexity, the cognitive load, and the realization that sometimes, renting a boring, predictable chunk of metal (or a virtual slice of one) is actually the smartest financial decision you can make.
Here is the story of how I fell out of love with the hype, and why I’m seeing more and more of us drifting back to the warm, reliable embrace of a VPS.
The Seduction of “Scale to Zero”
Let’s be honest: “Scale to Zero” is the best marketing slogan in the history of cloud computing. It appeals to the frugal developer in all of us. It appeals to the indie hacker who has ten side projects, nine of which will never see a user.
The logic is sound. Why pay $5, $10, or $20 a month for a server that sits idle 99% of the time? It feels wasteful. It feels inefficient.
When I started my first serverless project, I felt like a genius. I had a portfolio site, a small SaaS tool for resizing images, and a personal blog. On a VPS, I’d have to size the server for the peak traffic, meaning I was paying for capacity I rarely used. On Serverless, I was paying per millisecond.
I felt nimble. I felt efficient.
But here is the trap: “Scale to Zero” implies that your traffic is the only variable in the cost equation.
It ignores the architecture tax.
To make my application “serverless,” I couldn’t just upload my files. I had to architect it. I needed a database that played nice with ephemeral connections (which, back then, meant paying a premium for managed databases because standard Postgres hates 1,000 simultaneous Lambda connections). I needed a caching layer. I needed a separate service for queues.
Suddenly, I wasn’t just paying for “compute.” I was paying for:
- API Gateway requests (which can get surprisingly expensive).
- Data transfer between services.
- CloudWatch logs (oh my god, the logs).
- Managed NAT Gateways (the silent killer of AWS bills).
The “Scale to Zero” promise blinded me to the “Scale to Complexity” reality. I had traded a single $10 bill for a ledger containing 45 different line items that totaled $12… until they didn’t.
The “Infinite Loop” Nightmare
This is a rite of passage for every serverless developer. If you haven’t had it happen yet, it’s coming.
On a VPS, if you write a bad loop that spins the CPU to 100%, your server slows down. Maybe it crashes. Your site goes offline. You restart it. You feel bad. You fix the code.
In Serverless, a bad loop doesn’t crash the server. It scales.
I had a function designed to trigger when a file was uploaded to an S3 bucket. The function would process the image and save a thumbnail back to… the same bucket.
You can see where this is going.
I uploaded one image. The function fired, created a thumbnail, and saved it. That save event triggered the function again. Which created a thumbnail of the thumbnail. And saved it. Which triggered the function again.
Because Serverless is “infinitely scalable,” the cloud provider didn’t say, “Hey, this looks like a mistake, let’s throttle this.” It said, “Wow! Look at all this traffic! Let’s spin up 1,000 concurrent instances to handle this load! We are crushing it!”
I went to sleep.
I woke up to a bill for thousands of dollars.
Now, sure, you can set billing alerts. You can set concurrency limits. But on a VPS, the “limit” is physics. The CPU hits 100% and stops. The wallet damage is capped at the monthly rental fee. On Serverless, the limit is your credit card limit. That anxiety—the background hum of terror that a typo could bankrupt me—is a cost I hadn’t factored in.
The Hidden Cost of “Glue Code”
We need to talk about the development experience.
When I’m working on a VPS, the environment is usually a mirror of my local machine. I run Docker. It runs on my laptop; it runs on the server. If I need to debug, I SSH in, tail -f the logs, and watch the traffic hit in real-time. It’s visceral. It’s immediate.
In the Serverless world, I found myself spending 40% of my time writing application code and 60% of my time writing “Glue Code.”
YAML files. endless serverless.yml or Terraform configurations. IAM roles. Permissions policies. Configuring VPCs so my Lambda could talk to my RDS without exposing it to the world.
I wasn’t a developer anymore; I was a cloud plumber.
I remember spending an entire weekend trying to debug a “Cold Start” issue. My API response times were erratic. Sometimes 50ms, sometimes 3 seconds. Why? Because the cloud provider was spinning down my containers to save resources (Scale to Zero!). When a new user arrived, the system had to boot the container, load the runtime, load my code, and then execute.
To fix this, I had to pay for “Provisioned Concurrency.” Which essentially means paying to keep the server running.
Wait.
If I’m paying to keep the instance running 24/7 to avoid cold starts… didn’t I just reinvent the VPS with extra steps and 4x the cost?
That was my first major “Aha!” moment. I was jumping through hoops to emulate the behavior of a server that is always on.
The “Nickel and Dime” of Managed Services
The biggest lie we tell ourselves about Serverless is that it removes operations. It doesn’t. It outsources operations to the vendor, and they charge a premium for it.
Let’s look at a database.
On a $20 DigitalOcean droplet or a Hetzner dedicated box, I can install Postgres. I can tune it. I can run it. It costs me nothing extra.
In a purely Serverless environment, running a persistent database inside a function is a bad idea. So, you use the Cloud Provider’s managed database. Amazon RDS Proxy, or Aurora Serverless.
Have you looked at the pricing per ACU (Aurora Capacity Unit) lately?
I built a small SaaS that tracked uptime for websites. It pinged URLs every minute. A constant, predictable workload.
On Serverless, this was a financial disaster. Every “ping” was a function invocation. Every result storage was a database write. The database had to be “awake” constantly because the traffic was constant.
Aurora Serverless billed me for every second it was active. Since my app ran 24/7, I was paying premium “on-demand” pricing for a 24/7 workload.
I did the math. The database alone was costing me $150/month.
I migrated that entire workload to a single $10 VPS running a Go binary and SQLite (and later Postgres). It ran faster. It ran smoother. And the bill was flat. Ten dollars.
The “Managed Service” premium is real. You are paying for the convenience of not managing the OS. But eventually, you have to ask yourself: Is sudo apt-get upgrade once a month really worth paying a 1500% markup on compute?
The Mental Shift: Predictability vs. Possibility
The argument for Serverless is usually about “Possibility.”
- “What if you go viral?”
- “What if you get on the front page of Hacker News?”
The argument for a VPS is about “Predictability.”
- “I know exactly what I will pay this month.”
- “I know exactly how my code executes.”
I realized that my anxiety about “going viral” was mostly vanity. Most of my projects—and honestly, most B2B applications—don’t need infinite scalability. They need consistent performance for a known number of users.
If I do go viral? A $40 VPS can handle a lot of traffic if you aren’t using bloated frameworks. And if I really, truly crash the server? That’s a good problem to have. I can scale then. Optimizing for “Google Scale” when you have 100 users is the most expensive form of procrastination I know.
The Vendor Lock-in Trap (It’s Not What You Think)
People worry about vendor lock-in because “What if I want to move from AWS to Azure?”
I don’t care about that. I rarely switch providers.
The real vendor lock-in is Architectural Lock-in.
When I write code for a VPS (using Docker, or just standard binaries), I own the architecture. I can run it on AWS EC2, on Google Compute Engine, on a Raspberry Pi in my closet, or on a bare-metal server in Germany.
When I wrote for Serverless, my code was infested with vendor-specific libraries. My architecture was defined by the limitations of the platform.
- “I can’t run this job for more than 15 minutes because Lambda times out.”
- “I can’t write to the local filesystem because it’s ephemeral.”
- “I have to use this specific queue service because it’s the only one that triggers the functions natively.”
I wasn’t writing standard software anymore. I was writing AWS-ware.
Escaping that is incredibly hard. Refactoring a distributed, event-driven serverless mess back into a cohesive monolith is painful. I’ve done it. It feels like trying to put toothpaste back into the tube.
When Serverless Does Win (Because I’m Not a Luddite)
I don’t want to sound like an old man yelling at the cloud (pun intended). I still use Serverless. But my relationship with it has changed. I treat it like a garnish, not the main course.
Serverless is amazing for:
- Gluing things together: A webhook receiver that fires once a day? Perfect.
- Bursty processing: Users uploading profile pictures that need resizing? Perfect. I don’t want a server idling just waiting for an image upload.
- Experimental APIs: If I need to mock up an endpoint in 10 minutes to show a client? Amazing.
But for the “Core” of my application—the thing that handles the business logic, the persistent connections, the heavy lifting—I have returned to the VPS.
The Joy of “Boring” Tech
There is a profound sense of calm that comes with “Boring” technology.
Last month, I launched a new project. I provisioned a shiny new VPS. I set up a firewall. I deployed a Docker container. I set up a cron job to backup the database to S3.
It took me about an hour.
I know that if 10,000 people hit the site, the CPU will spike. The site might slow down a bit. But my credit card won’t melt. I know exactly where the logs are. I know that the filesystem is persistent.
I feel like I own my stack again.
The tech industry is obsessed with complexity because complexity sells. Complexity requires consultants, managed services, and enterprise support plans. Simplicity doesn’t make money for cloud providers. A $5 server running a binary doesn’t buy Jeff Bezos a new rocket.
But it might buy you peace of mind.
So, if you’re looking at your cloud bill and wondering why your “cheap” serverless architecture costs as much as a luxury car payment, maybe it’s time to take a step back. Maybe it’s time to rediscover the power of a dedicated machine.
Sometimes, the most “modern” thing you can do is choose the technology that lets you sleep at night. And for me, right now, that looks a lot like ssh root@192.168...
Leave a Reply