For years, serverless was sold as the future.
No servers to manage. Just write a function, deploy it, and let the platform scale it for you. AWS L...
For further actions, you may consider blocking this person and/or reporting abuse
Literally every point listed here is solved for serverless in exactly the same way as for traditional server apps (except #2).
Vendor lock-in is a totally valid point though - but it's the only one I can relate to.
My point isn't "you can't." It's that forcing full apps into a FaaS model often means more complexity, worse DX, and deeper lock-in, all while you're essentially rebuilding (often poorly) what servers already did well.
Sure you can stich together state with external caches, bring in hyperdrive to handle database connection pooling, build a complex job system to bypass the max function execution time, and setup cron jobs to warm up a few instances which goes against the whole "scale to zero" mantra. All to end up with a unpredicatable latency, relying on proprietary glue to make it work, worse DX, almost impossible to debug.
Even the platforms are showing this: Deno cut regions because global FaaS wasn't the magic bullet, Vercel built Fluid to get closer to server-like behavior, Cloudflare added stateful Durable Objects. They're all rebuilding the server, just with more proprietary layers.
You're essentially ignoring the nuance in my post by just saying, "Well, FaaS can do that too."
I'm also not sure what point the poster is trying to make. FaaS can do all of these things just like any other solution. I guess it's a lack of experience with the technology.
tl;dr: "Just because you can doesn't mean you should."
You prove my point exactly with this comment, thanks.
Are you actually completely missing, or deliberately ignoring the entire point of the article? Can't tell which it is, lol.
To me the article doesn't make sense, it's lack of experience with the technology.
For instance, you talk about stateless being something bad or exotic while it's completely normal. State is kept in a database, not in the memory of your application. What would happen if your server goes down?
It's fine if you don't like FaaS or Serverless in general but the reasons you mention are not facts, it's just your opinion based on your own experience.
More info:
1 more addition; you tried one of the available solutions and assume they all work the same. Lambda for instance can run globally at edge (Lambda@Edge) for specific tasks but my serverless apps just run in a single region. Could it be that you are shooting down FaaS/Serverless compute for the wrong reasons perhaps?
Totally agree that trying to build complex, stateful apps on serverless always turns into a headache. Curious if you’ve found any tools that actually make region-pinning and state easier - or does it just feel like recreating servers anyway?
Yeah, that's exactly the problem. Once you start needing region-pinning and stateful logic, you're already halfway back to just running a server.
Some tools try to help with this (like Durable Objects on Cloudflare or Deno's upcoming compute-bound state), but in practice they come with their own trade-offs and lock you into that platform’s way of doing things. You're not really avoiding complexity, just shifting it somewhere else.
For most apps, I’ve found it’s easier to just pick one region close to your users and colocate everything there. You avoid most of the pain without giving up too much performance.
Yeah, this hits home for me - always felt like building real stuff on serverless turned into a mess, but it's still clutch for all my quick jobs.
Same here. I still reach for serverless when I need to run something fast, stateless, and event-driven, it’s great for that. But the moment you try to build anything with real complexity or state, it stops being simple. It’s best used as a sharp, focused tool, not the whole toolbox.
🪦
Interesting, I'd say the biggest problem with serverless is a lot of people don't know how to use it properly. Don't get me wrong, serverless is a tool just like any other tool, but it hurts to read all these articles of people using it wrong.
Serverless services is yet another great example of a purpose built tool being used for right everything without understanding the fit.
I recently built a registration form on Azure functions and this is pretty much word for word my own thoughts on it. It worked reasonably well but it was clear we were pushing against the limits of what it was reasonable to do with it.
been cool seeing steady progress in this space - always make me think if picking the “right tool for the job” is really about the tech itself, or just how much headache i’m willing to deal with long run
What are the ideal use cases for serverless today?
Thanks for sharing !!!
Serverless should work for the following:
And other "quick tasks".
Great points, Hammed! 👏
You could also add a few more ideal use cases for serverless:
All these scenarios benefit from serverless scalability and cost-efficiency. 🚀
let's connect
github.com/astrod333