Every time someone reaches for serverless to build a simple backend, a container dies inside me.
“Serverless” promises simplicity, scalability, and zero maintenance. In practice, it gives you time limits, vendor lock-in, surprise billing, and complexity disguised as convenience. You end up duct-taping together SaaS services just to do what a Docker container can do out of the box.
Let me break it down — and preempt the counterarguments along the way.
What Even Is Serverless?
Serverless means you deploy individual functions to a cloud platform, and it handles provisioning, scaling, and execution. You don’t manage the server — you just drop your code in and go.
At least, that’s the dream.
Here’s what you actually get:
- Strict runtime limits (e.g., 15-minute max execution on AWS Lambda)
- Zero state retention between runs
- Cold starts (unless you pay extra, and "pre-warm" your functions)
- Opaque debugging
- Vendor-specific quirks and configs
- A lot of YAML
And if you want to do literally anything non-trivial — long-running jobs, background processing, persistent connections, file uploads — it falls apart fast.
Containers: Simple, Powerful, Boring (In a Good Way)
You know what works?
A container.
- Starts fast
- Runs anywhere
- Keeps state (just add a Docker volume!)
- No arbitrary time limits
- You can attach a debugger, use your favorite runtime, and run locally or in prod — no magic, no special rules
Example:
docker run -v my-data:/data my-app
Boom — stateful workload, works on your laptop, your VPS, or your edge node.
No vendor lock-in. No hidden costs. No rewriting your app to fit someone else’s constraints.
Serverless Pricing: Designed to Confuse You
Serverless pricing is a dark pattern.
- You pay per invocation
- Per memory used
- Per execution duration
- Per GB transferred
- Per region
- Per secret accessed (yes, really)
The pricing page is five layers deep, full of made-up terms like:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
And the kicker? You don’t know what you’re paying until the invoice arrives.
Bandwidth is especially overpriced. $0.55/GB egress in 2025? Why?
Compare that to a $5/month VPS with predictable flat pricing and full control. Containers win by a mile.
“But Serverless Scales!”
Sure — technically. But for what? Your app with 4 users?
Most apps don’t need “infinite scalability.” They need:
- Predictability
- Observability
- Reasonable resource limits
- A working dev/staging environment
You know what’s great for that? A container.
Horizontal scaling is trivial (thats Docker Swarm):
replicas: 5
Or throw it behind a load balancer. You get scalability and control — without rewriting your app into a spaghetti of disconnected functions.
Stateless by Design = Artificial Problems
Serverless forces statelessness. That means:
- No in-memory caches
- No temporary files
- No sticky sessions
- No long-lived connections
So now you need:
- An external database
- A distributed cache
- A file storage bucket
- An event bus
- A state machine to orchestrate your state machines
Suddenly your “simple” serverless app depends on six SaaS platforms (each with their own billing, APIs, and failure modes).
Meanwhile, in a container:
- You can cache in memory
- Write to disk (Docker volume)
- Maintain sessions
- Run as long as you need
You know — like a normal program.
“But I Don’t Want to Manage Servers!”
Cool. You don’t have to.
There are tools that give you container-based platforms without ever SSHing into anything:
- Sliplane (shameless plug)
- Railway
- Coolify
- Even just Docker + systemd on a VPS doesn't require much management these days!
You still get Git-based deployments, rollbacks, logs, metrics — but you decide how things run, and you can actually understand the system.
“Serverless Is Cheaper!”
Is it?
Maybe, for 5 invocations a day. But the moment you:
- Have consistent traffic
- Need more memory
- Do actual compute
- Transfer data
...the costs spike. And you can’t optimize much because the platform abstracts everything away.
Meanwhile, containers:
- Run full-time on cheap hardware
- Can be colocated with storage or caches
- Are easy to benchmark and tune
- Don’t charge you per millisecond
When Serverless Actually Makes Sense
Alright, let’s be fair — serverless has its niche:
- Event-driven functions (e.g., image resizing)
- Infrequent tasks or webhooks
- Lightweight internal tools
- Proof-of-concepts
- Stuff that truly needs to scale up and down quickly
If your workload is truly intermittent and stateless, and you want zero operational effort, serverless can work.
But for real apps? You’ll hit a wall. And that wall will cost money, time, and brain cells.
Containers FTW
Containers give you:
- Portability
- Control
- Simplicity
- Transparency
- Flexibility
You can deploy one container, or ten. Scale them. Monitor them. Keep state. Run background jobs. Use your own database. Move providers without rewriting code.
And you’ll actually understand how your system works.
TL;DR
Serverless is cool — in theory.
In reality, it’s:
- Opaque
- Overpriced
- Overcomplicated
- Overhyped
Before you fall for it, ask yourself:
“Could this just be a container?”
The answer is probably yes. And if it is — you’ll save yourself a lot of pain by just starting there.
Got Burned By Serverless?
Drop your horror stories in the comments. Surprise bills, broken workflows, YAML nightmares — I want to hear them all.
Let’s stop overcomplicating the simple stuff.
Cheers,
Jonas, Co-Founder of sliplane.io
Top comments (68)
This is just a marketing article from sliplane.io founder.
Sort of feel sorry while reading it as it's simply one sided. Doesn't explain about challenges with managing servers at all. OS patches, maintaining high availability while scaling etc.
There are major companies such as Netflix already using serverless for years. There are lots of white papers Ted talks about it as well.
This article is just for marketing.
Thanks! I won't waste my time reading it
fair enough, this is more personal ranting than marketing tho haha. I wouldve written the same anonymously
Not every schmuck can set up a service application figure out Lambda commands to make these things work on an AWS Cloud Server. Let's be honest spinning up a docker container is about a hundred times easier. So SlipKid does have some points.
However, let's be realistic: if you can't run your program from the CLI with a cURL command, what are you really doing? Authorized Rest based API calls require stateful workflows so you need to bake these concepts into your design to keep your software app easy to integrate.
SlipKid is a good one
What’s wrong with telling about your product if it’s true and helpful?
I think lambda functions are good for very specific heavy calculations that fluctuate like repeatedly sudden peaks where you need to absorb all requests in a tiny squeezed fraction of a second. and cannot afford to loose anyone. Or yo I need extremely large RAM for short AI computation etc. But of course for most services the standard and simple monolith is perfect. Why even go serverless? If you can write your own server, do it. Don’t pay for any of those giant clouds. In fact I got curious about this sliplane service and clicked to read about it and I guess I’m not the audience for it as I didn’t understand at a glance what is it about exactly and I assume it is related to the article so I’ll be glad to get more details here. What’s the innovation? What does it solve?
Fair enough, but why would he talk about managing OSes? His argument was against serverless technology, not cloud technology entirely. Towards the middle of the article he listed 3 different cloud container services. AWS ECS and EKS come to mind. Where I work, someone set us up with render.com, which allows for deploying containers. So there are already infrastructure platforms that allow for deploying containers, without having to manage patches.
This shameless plug aside, I'm more interested in whether or not the comparison is all that accurate. Also, I'm quite out of practice on this stuff, and trying to get back into it - but I thought there was some strong arguments for why stateless was a useful design pattern, and all I'm seeing is that the alternative allows for maintaining state. But is that a good thing? Does that make it better?
In tech we get so pseudo-religiously dogmatic about our choices. It doesn't need to be that way, use the tool that works for you and acknowledge that other people will use what works for them, and that it might be different. Share rational comparisons not emotive dogma. Articles like this don't help people to make rational, reasoned judgements about what tech to choose, and I'm so tired of them on all sides.
The clickbait title (I fell for it, granted) generally denouncing serverless (or anything for that matter) because it didn't work out for you is your n=1 and doesn't mean a lot in the context of the wider community.
For balance, and from my own perspective - our company has numerous B2B applications, deployed all over the world for many many users. All of which run on serverless, work brilliantly with single digit minute downtime in the last 5 years, run by a very small team. This is very cost effective for us, highly performant and therefore our customers benefit from great pricing and availability.
Yes, there are trade-offs but in our case they're stacked well in our favour. Is it for everyone?
No, but do I personally miss having to build and configure servers, networking, and hire expensive DBAs and server administrators etc. Or being called in the middle of the night because a RAID array failed. Not in the slightest.
I've managed containers too, the reality is, the complexity of management beyond very simple applications gets high and quickly but do I shout "Containers are a Scam!! (I don't) because they work well for some use cases. Maybe your tool helps with this complexity, great, more power to you but denouncing a highly valid way of building value to attempt to promote your own product just puts me off taking a look at it.
Hah yea, this was clickbait. I tried to make it clear that there are very real usecases, I was just "pissed" that serverless (in marketing by a lot of companies) is displayed as the only superior solution
Fair enough. Like I say, horses for courses. Use what works for you, the rest is marketing ;-)
"horses for courses" is a nice saying. stealing that :D
Right, having not used serverless or docker for 3.5 years, I'm operating on some faint memories, but I find myself asking whether having state is better. And I also recall the docker services could be done statelessly. All I saw here was that no state is a disadvantage, rather than acknowledging that there's a design pattern behind that concept. That also makes me think that his counter argument about containers could potentially lead people into an anti-pattern. I don't think serverless functions are stateless because of some limitation - I think it's an intentional choice (even if there might simultaneously be a limitation).
A lot of serverless isn't even really serverless. For example, Azure functions, at least in nodejs runtime, doesn't have an isolated state per function invocation, so you can actually cache in-memory (by accident) 😂 which becomes really problematic if you do anything with authorizations 😂
It is serveless, but it is not stateless. You mention it in the next sentence.
But that is bad, I would expect functions to be stateless.
I agree that serverless is a bad name. For me serverless is giving the responsibility of server maintenance and scaling to a hosting platform. The only thing that serverless does that other hosting packages don't provide is scaling.
If stateless would be a feature of all serverless services you could not have serverless cache and serverless databases.
You can do the same for Lambda, but having some state can be a good thing. E.g. If you need to call another service for a token, as long as it isn't per user, you may as well call it before invocation and store it, then the next few invocations can use it.
That being said, knowing subsequent invocations on the same instance has some state means you also need to be careful you don't keep state you don't need it will cause issues
Could you link documentation if there is any? I'm curious what the cut off point of the state is. If there is state between function calls it should be reliable to be sure the next call receives the state value from the previous call.
I would send the value to the next function call to be 100% sure.
I'll try and find it, but basically the instances can hold state as they are just a server with your application running. It just depends on your language how best to store these, but in general it is fields declared outside of your handler method
There's some info here.
docs.aws.amazon.com/lambda/latest/...
wait thats funny, i didnt know that :D
I had to cry a little 😅
serverlesshorrors.com/
Oh my.
I'm going to look into at this site, but from the outset, just seeing the title, my thought from reading years of stack overflow comments, I'm inclined to believe that most of the people reporting these horror stories went into it with the wrong understanding. Like when I started using docker, I was trying to recreate virtual machines. I wanted containers that I could log into. I wanted containers that did multiple things, not separate services - I didn't even know about compose at the time. I just started learning the technology going into it with what I wanted it to be.
Any technology can be misused like this. I have to think some of the horror stories are legit, but some are just trying to use the wrong tool for the job, when perhaps there's some context where serverless is the right tool.
Depends,
Have 6-7 serverless projects.
One is make me like "I don't want to do development anymore".
Now I know how to use it, Using free serverless options, mostly the when I really needed, Like: I have an project which Uses Next.js as frontend, and I have an a backend on Laravel + many other things there. But the project is Up & running while getting 10K users daily.
No need to manage anything now, Its been a Year in production, and its working fine.
I know what you are saying is true, Serverless is like a Romantic story which turns out to be horror.
Nonsense. The answer to any stack is 'it depends'.
This is marketing to advertise sliplane. Serverless has its place and depending on the situation, makes sense against managing containers.
Next time, consider your audience aren't fools before giving your opinion.
The answer to all software engineering decisions is “it depends”, but that’s boring. Anything specific you consider nonsense?
I think serverless is really good to start, it's free so I don't need to pay for a server for each one of my side projects until they start making money.
Yeah that's fine, just don't forget to add a billing limit :)
Serverless is not a scam, but a specialized model that offers unique advantages: automatic scaling from zero to thousands of instances in seconds for unpredictable loads (ideal for massive events or IoT), pay-per-use pricing (cost-effective for sporadic traffic like webhooks), and a reduction in operational debt by eliminating the need to manage servers, patches, or clusters. Although it is not optimal for long-running or stateful processes, advances such as extended execution times (up to 60 minutes on Azure), mitigation of cold starts (Lambda SnapStart), and managed services (serverless databases) make it robust for event-driven architectures. Its value lies in enabling small teams to deploy quickly with enterprise-level infrastructure, as long as it is used in its niche: ephemeral microservices, native cloud integrations (S3, API Gateway), and scenarios where prioritizing speed over full control is key.
This is mostly a marketing article or author mentioned he is just ranting out his thoughts which is kinda biased i would say,
We built and manage a music distribution saas , built of top of cloudflare pages + few additional set of Apis on workers,
It's been 2 years , that's rock solid and our infrastructure handled a great amount of traffic and a range of 10k-15k MAU,
Serverless has costed us very very very low, in terms of invocations cloudflare has a pretty good limit, we are on a basic paid plan, that's it.
We are saving on a hassle of managing vps and also being closer to user using serverless,
No doubt we have few dedicated audio processing apis on Golang based servers (VPS), due to nature of limited support of node and Golang(via webassemly) in workers,
But managing the entire website and all the routes with so so many functions - serverless has been pretty great,
We have paid more for additional APIs servers then compared to cloudflare.
In essence it depends on how you implement, your target audience and having a rough estimate for number of invocations that can lead to per user.
One other use-case I've come across for serverless is running AI/ML models (e.g. an image segmentation model or a real estate value prediction model) that need to be run infrequently and would cost a lot to have running consistently on a dedicated GPU server. There is a use-case for serverless, but it's important to be realistic with your goals and expectations vs. outcomes.
yeah true, also good usecase!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.