The post you are currently reading is a lot of facts, but also a lot of my opinions. It is addressing this post:
...
For further actions, you may consider blocking this person and/or reporting abuse
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... :)