The post you are currently reading is a lot of facts, but also a lot of my opinions. It is addressing this post:
Be sure to drop a comment and tell me what you think!
“Every time someone reaches for serverless to build a simple backend, a container dies inside me.”
Such begins the post of Jonas Scholz (@code42cate), titled “Serverless is a Scam.”
Every time I see a post like this, a serverless deployment dies inside of me 🥲
Actually, every time I see a post like this, I feel like serverless and containers are misrepresented. In this post, I want to address a lot of things about both serverless and containers, but particularly some claims made in Jonas' post. Of course, no disrespect is meant towards Jonas. 🙂
What Even Is Serverless?
Original article:
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.
The author defines serverless as “you deploy individual functions.” That's FaaS (Function-as-a-Service), which is one kind of serverless. Serverless providers, like Vercel, Netlify, Cloudflare, and more, have gone way beyond just functions. For example, many support things like Fluid Compute, edge middleware, long-running background functions (although admittedly more tricky), full web apps, and more.
Now, one fair critique is that many of these are "patches" on top of the core FaaS limitations. For example, long-running background jobs often require an integration or separate service because native FaaS platforms generally don’t support persistent or scheduled tasks well. This is a real limitation, and you should consider the tradeoffs when designing your system.
Containers…
Original article:
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-appBoom — 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.
Containers are great, but managing them is not free of complexity! You still have to set up CI/CD pipelines; manage load balancing, auto-scaling, monitoring, etc.; and handle failures and rollbacks.
And before you tell me, “but there are tools that do that hard stuff for you”, stop. There are tools that do that for containers and there are tools that do that for serverless, too. But you can't complain about vendor lock-ins and configs for serverless providers and then offer me a vendor locked-in container manager.
That said, vendor lock-in is for sure something to think about with serverless providers. Once you are using their storage, background jobs, and queues, migrating can be hard. It might require rewriting parts of your app, which is pretty annoying.
I wish it was as simple as docker run -v my-data:/data my-app, but I've been through this with my website and it is not. You often wind up writing long and complicated Dockerfile files and using things like docker-compose just to solve simple problems.
Serverless Pricing = Confusing?
The original article had a heading which read “Serverless Pricing: Designed to Confuse You”. What actually happens is that Serverless pricing is designed for how serverless works. It can be complex because it scales with usage. Compare that to containers running 24/7, regardless of traffic.
Original article:
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.
For startups and freelance devs, serverless is really awesome because many platforms provide serverless deployments 100% free (for example, Netlify).
As far as predictable billing, it can be predictable. You can easily set spending limits on most serverless providers. And Egress pricing it true for all cloud providers, not just serverless.
Well, I should be fair. If you aren't on the free plan, you might have a quite different experience. If you get a LOT more traffic than you expect and use up a lot of function invocations without a spending limit, you might get a rather surprising bill!
Serverless = Spaghetti Architecture?
Original article:
“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: 5Or throw it behind a load balancer. You get scalability and control — without rewriting your app into a spaghetti of disconnected functions.
Well, firstly, serverless does fine as far as all the points listed. But whether serverless is “spaghetti” depends on how you build your app. If you design each function like a microservice, yeah, you can make spaghetti. But that's the point of a framework, like Next.js, Remix, etc. You write full apps with API routes, background jobs, and frontend all in the same codebase. It's very organized and not spaghetti at all.
Plus, it's not uncommon to make a “spaghetti of disconnected functions” in an app, regardless of whether your app is serverless or containerized.
Stateless isn't necessarily bad!
Original article:
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.
As my heading suggests, the first misconception to clear away here is that “stateless is bad”. Stateless might be annoying at times, but it encourages best practices. It:
- Makes scaling easy
- Prevents sticky-session problems (yes, no sticky-sessions is a good thing)
- Encourages durable storage, Redis, etc.
And by the way, maintaining sessions in memory or in a Docker volume is a bad idea for a lot of reasons. It's not secure and not durable.
You especially shouldn't keep important data in a container's memory, either. That is not safe or scalable. Docker volumes don't magically make things distributed or reliable.
Despite all this, it's true that making stateless systems work often means you end up stitching together multiple external services. This can be over-engineering for simple use cases and does introduce more moving parts. Serverless shines with proper tooling and planning; not for everything.
“You Don't Want to Manage Servers? Use X Instead!”
Original article:
“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:
[list of tools removed]
You still get Git-based deployments, rollbacks, logs, metrics — but you decide how things run, and you can actually understand the system.
The author says “just use X/Y/Z”, which are abstractions. You can't complain about serverless being an abstraction and then offer me an abstraction, you need to judge both by the same standards!
Another note: Rollbacks on non-serverless architecture are horrible. With serverless, you can spin up any previous deployment in literally a few seconds; often even shorter! In a container, unless you are storing all the previous build outputs, you have to rebuild at a specific version or commit which takes time, usually a long time. A lot longer than a few seconds.
Containers do offer a lot more control, especially if you want to customize your deployment pipeline, use your own CI/CD tooling, or run workloads that don't fit into the serverless execution model; it really depends on the project.
Serverless is cheaper
Well, this one actually depends on your use case. But for most cases (the ones for which serverless is designed), serverless is cheaper.
On many providers, you can deploy 200 or more projects, over 50 domains, and you get unlimited deployment retention. For $0. Both are very good pricing, and it shows how efficient serverless is.
Original article:
“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
5 invocations a day is ridiculously misrepresenting serverless. On the Netlify or Vercel free plan, I can get over 30,000 middleware invocations a day.
Serverless handles consistent and inconsistent traffic well, because it scales. But yes, serverless costs can grow pretty fast once you're doing heavier compute, using more memory, moving a lot of data, etc. And since platforms abstract away a lot of internals, it can be harder to optimize performance or costs at that point.
I would like to point out, though, that containers (specifically hosted on a VPS etc.) do charge you per time and not per usage. So “Don’t charge you per millisecond” is technically right… but only because they usually charge you per month or year.
When Serverless Actually Makes Sense
Original article:
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.
Uh… what? The list, “event-driven functions, webhooks, PoCs, lightweight tools, stuff that truly needs to scale”, is most startups, MVPs, internal tools, and JAMstack websites. Serverless is designed for that.
If you are building YouTube or some real-time game server or something, or perhaps something with WebSockets, containers are probably a better choice. But for portfolios, blogs, eCommerce, MVPs, etc., serverless is the best.
Summing it all up
To conclude:
Serverless isn't perfect, and neither are containers.
Containers are great when you need full control, persistent workloads, etc.
Serverless is unbeatable when you want speed, simplicity, scalability, and zero ops.
You don't have to pick one side. Use the right tool for the job.
The future is not "serverless v.s. containers"; it is hybrid, and platform-agnostic devs will win.
Afterward
I have two main suspicions about the original article.
The first is that the original article was written by AI. I wasn't sure if it was worth my time to make a response article, but I decided to just because I haven't written in a while and was thinking a lot about serverless anyway.
The top comment by @muos12 nicely sums up my second suspicion:
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.
I hope you learned something reading this! I would love you hear your opinion in the comments!
Top comments (21)
good article 👍
😂
The original post is clearly clickbait, and I took it mostly as a joke. But your response here honestly reads more like a Vercel ad than a balanced rebuttal.
Serverless (FaaS) is a decent approach for very specific use cases, mainly bursty, stateless workloads. The problem is that it was marketed as a universal solution. VC money poured in, the hype cycle took over, and suddenly serverless was being used for things it was never meant to handle. A lot of the “problems” you see in the OG post are exactly the result of that mismatch.
Even in your example of “long-running background functions,” you’re essentially bringing in a third-party service just to patch a core limitation of FaaS.
Stateless isn’t inherently bad, but pushing everything into distributed systems just to avoid state creates new problems. Long-lived connections like WebSockets are a perfect example of something that’s far more painful in serverless environments.
Also, vendor lock-in is a huge and very real concern. Once you start using a platform’s built-in job queues, storage, background workers, edge functions, and deployment pipelines, it becomes incredibly hard to move away. You’re not just locked into the pricing. You’re locked into the architecture. And unlike Docker or a VPS, where you can usually lift and shift, serverless platforms often require rewriting large chunks of your app to migrate.
As for pricing, serverless is expensive. The free tier is a marketing funnel, not a reflection of real-world cost. Once you move past those limits, you’re dealing with complex pricing models, vague metrics, and unpredictable bills.
Serverless has its place, but it’s not a magic bullet, and acting like it is helps no one. So yeah, both posts are clickbait, just coming from opposite sides of the hype spectrum.
As I said:
As far as it's sounding like a Vercel ad, I reference Vercel a lot because that's my primary experience with serverless (although I have tried other places) 😅
I do agree that WebSockets are a huge pain in serverless, as well as SSE. I usually use a separate backend in such cases.
So, my preference (if it wasn't clear in the article) is to use serverless as much as I can and use containers when I need to.
I will update my article to be clearer and try to be more balanced, thank you for your feedback ❤️
Should read less like an ad now. I just updated, thanks for the feedback 👍
Serverless FaaS on the edge coupled with DDoS protection and straightforward pricing is the true serverless. A number of vendors are not willing to take the responsibility of DDoS for their serverless offerings which is unfortunate.
With edge computing (which relies on FaaS heavily) you can offload a number of concerns (e.g. authentication, rate limit etc) on the edge which improves latency significantly and eliminates the need of having dedicated api gateways / reverse proxies in front of every application.
Running a bunch of services in an isolated network is quite easy to achieve with kubernetes but I don't see how it is even possible with Serverless CaaS. You can't create one vpc per environment per application.
Hyperscalers and other players offer managed compute offerings (e.g. EKS, GKE) where you need NOT to patch any server. You go for VM offerings when you want to use a specific OS, instance size, underlying hardware etc. With Serverless you have no idea what is running under the hood.
Serverless CaaS/FaaS offerings are definitely more expensive (3-4 times) for consistent traffic. Try to run a single container application on a VM and a Serverless CaaS offering with heavy traffic and you will realize it it no time. Also a simple look at the pricing of Serverless CaaS offering confirms this because someone need to run the underlying infrastructure continuously and it costs money.
The fact that every serverless vendor has their own way of writing functions is a serious vendor lock-in concern.
We have been using edge computing with VMs from two different vendors and it offers best of both worlds.
Thank you for your insights, and thanks for reading 👍
Interesting discussion on serverless! While there are valid concerns, we've seen great success using Next.js API routes for serverless functions in our production apps. Simple, scalable, and surprisingly cost-effective for many use cases.
Yep, Next.js works great :)
Have you had any issues with serverless?
The funny thing is, all code is abstraction. It's abstractions all the way down. Serverless is essentially just abstracted containers. There are use cases for both, and if you're a control freak, you can run your own containers that provide serverless type functionality. Or, like you said, take a hybrid approach with a service like Terraform and abstract your entire infrastructure.
Spot on 💯
Thanks for reading!
great opinions. i never really cared for serverless but i dont see any reason why not to use it, like if it works for you good.
Thanks for reading 🙌
Summary: Serverless is not a scam, but it is false advertising, Serverless uses a server process or serval server processes that are all dynamically scaled, but it is STILL ON A SERVER! Its false advertising, no changing my mind about it.
True, it does run on a server, but you don't have to manage the server(s) or scaling.
I don't think I've seen a serverless provider that markets serverless as not requiring a server at some level in the architecture; the point is you just write functions and the platform handles running them and scaling.
Just like with “the cloud”, people understand (hopefully) that data is really on somebody else's server. And “cloud” services don't market their products as actually running in a cloud in the sky.
Server*less* less means without, so server*less* implies that it is without a server
Yes, taken literally. I don't think it's false advertising, though. I have not seen a serverless provider that marketed their product as not having a server.
You will be shocked to learn that your wireless internet also has wires somewhere.
Exactly 💯
The phrase "Serverless" implies that is does have or need a server.
I was reading through the serverless thread and came across this dissing, quite fun, but also solid points from both sides.
The term “serverless” gets thrown around a lot, but it covers everything from tiny cloud functions to full-on container orchestration. That range makes it easy to talk past each other.
I shared some of my own thoughts on it too, especially from the provider landscape side, if anyone’s up for one more take: dev.to/fabcairo/serverless-for-con... :)