Every time someone reaches for serverless to build a simple backend, a container dies inside me.
“Serverless” promises simplicity, scalability, an...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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 :)
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.
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.
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.
Hmm, couple things:
Serverless doesn't just mean lambda functions. ECS Fargate, for running containers, is also serverless for example. So is DynamoDB etc. All it means is the server is completely abstracted away. Lambda is only one of many tools for a serverless approach.
Even passing the AWS certification exams requires knowing when those issues you listed make lambda a good idea vs containers. AWS doesn't recommend you use containers for complex long running tasks or insist you should add all that complexity to get around their limitations.
So I don't see how it's a scam if you
A) Aren't defining serverless correctly
B) Aren't even following AWS's recommend approaches
To me this article title should basically be:
Serverless is a misunderstood term and people often use tools like Lambda incorrectly!
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!
Have you tried Cloudflare Worker? They have managed to mitigate many of the issues you mentioned, they have zero egress fees, no cold start, clear pricing with a large free plan and if you use something like HonoJS, your code can be deployed pretty much anywhere, so no lock in. They tend to use open standards for their services, so if others are also doing that, then even if you do integrate with their services, it's usually pretty simple to switch to something else if you move.
Also you could use Hexagonal Architecture when integrating.
Otherwise, I feel you made lots of good points. Containers still have a place, and are often a good choice.
As someone else mentioned, there are extra management with them, such as updates, but if you're doing that anyway, I guess that's not a big deal.
And you run your stateful app with a database inside your container? Don't forget to patch your container... Strange one sided article that ignores the downsides of containers and the upside of Serverless.
Interesting thoughts! I don't like the Serverless approach, of course, but, well, that's also it.
I forgot one, always hated serverless in a visceral fashion, not knowing why I did so. So I agree with Jonas here. Not because I know, but because he brings out my inbuilt prejudices and gives reason to my fears.
Somebody
Else's
Rather
Very
Expensive
Rack
Leveraging
Engineer's
Stupid
Sloth
LMFAO
It just sounds like you're either using serverless services incorrectly or using the wrong serverless services. I've deployed containers to Cloud Run that seamlessly serve tens of thousands of requests per day and cost less than $100 per month. I've also spun up cloud run service that have like 10 requests per month and cost almost nothing. If you use it right serverless works quite well and is pretty cost effective and is certainly not a scam.
I've worked with companies that spend millions per year maintaining their serverless infrastructure — not because serverless is "cheaper" or "simpler," but because every microservice ends up needing:
At a certain scale, the dream of "just write functions" becomes a nightmare of orchestration. And yes, sure, it’s technically easy to switch, but migrations across cloud setups and architectures are never cheap or smooth.
That said, serverless has its niche. But calling it a scam is probably a clickbait here :) It's more like a power tool, extremely useful in the right hands, potentially dangerous in the wrong ones. Use it for what it’s good at, but don’t pretend it’s the right tool for every job.
Sanity !
Give to this wise man a cookie !
Thx for your work !
In the past you got a username and a pass you connected to an FTP server, uploaded your files and pressed a button on a website. Config was a HTTP address and credentials, and an FTP address and credentials.
Now, you have to maintain that 16000 lines of configuration.
good old ftp days :D
As mentioned serverless can't fit for all use cases. So be cautious when you choose serverless. I have been part of a project where we implemented webhook that would share realtime updates to consumers. Data volume is unpredictable per minute. So aws lambda function helped to knock out. Ofcourse it deals with few saas to achieve the usecase. But it takes care the scalability. With a complete understanding of serverless like limitations and benefits you can go for serverless
oh yeah webhooks is a good usecase for serverless, agree!
Really interesting article. Actually going through something almost exactly like what you described. Tried Azure, and I started paying like $80/month (0 users. Just me testing right now). I looked into AWS, but couldn't find straightforward pricing.
So, I decided to split things up. Backend I'm railway, database and storage with digital ocean, frontend with vercel.
Now at least I have some pricing I can predict
Pretty wild how using serverless sounds easy at first but ends up like buying a toy with a million tiny pieces you gotta put together. Sometimes simple is just better.
Isnt pre-warming basically free when you just ping your lambdas to keep them up? Provisioned is what costs a lot
Yes he is right serversless is not for everyone if you have a small project then a vps will be best option for you , as it's easy to set up and once done it's doesn't require that much maintenance.
I don't entirely agree, but nice write-up!
Quite a one side article but statelessness makes using lambda in any relational data flow a royal pain.
just use fargate(> 15min) then, lambda is really cheap and easy to use not overcomplicated. Also easily distribute load by producers(dynamodb, sqs or ...)
Well written article, I enjoyed reading it but you are a bit biased in your comparison.
I don't think Google Cloud Run has most of those issues
Everyone is entitled to their opinion, but this feels like a thought leader piece that's really disguised marketing for sliplane.io. 🤷
not trying to disguise anything here :D
nice
$56 a month (probably more now) for a serverless database cluster that has zero activity sounds more like a server that is leaving me with less money in the bank.
Have you tried building on cloudflare? You might find it a different experience.
I found How I Managed to Take My Laravel Application to the Serverless World a very insightful post.
If you test enough anything can be optimised.
Stateless is how the internet is build, so a stateless way to process requests is not that big a stretch.
I don't agree that by using containers you understand how the system works. You can pick a container from docker hub and add the application. As long the application works do you need to know what the image contains?
While I agree a serverless application requires multiple services. That is the way applications are evolving anyway. I started with application code, file storage and database all on the same server. The first thing that moved was the database. And now many applications use a DAM service or cloud file storage.
A serverless application might be an extreme case of separating responsibilities. But having the possibility to do it, gives us options.
I think the starter question to ask is, do you want to dig into services or dig into OS packages to have more performance and/or reduce costs. Both are a skill on their own.
Maybe the author has had a bad experience (or as they admitted, trying to plug their own service), but we've used a couple different serverless providers and they have both been refreshingly simple:
In the first case, we were running a complex FastAPI docker container from our home server (Debian), but one day the server went offline because the internet went down. We knew then serving from a physical box at home wasn't a good idea for production, so we put it on Fly.io. It literally took us less than an hour to read the docs and run the necessary CLI commands to migrate our API to Fly.io. So far, no billing surprises. Most serverless providers have an alert feature in case you're worried about surprises, so it's really not a problem.
We've been using Cloudflare Workers to handle custom API calls and webhook processing for years. No problems with them either. Even though the free tier supports our app with over 1M users, we liked them so much we paid for the $5/mo plan even though it's not really necessary.
@code42cate you 100% correct.
Server-less claims by design to log everything. But in practical scenarios, you have to pay more for their popwritery logging systems.
This article resonates deeply with my experience. Serverless architectures often promise simplicity and scalability, but in reality, they introduce hidden complexities and costs. The pricing models are opaque, state management becomes a juggling act, and you end up stitching together multiple external services just to match the flexibility you once had.
In contrast, containers or bare-metal setup provide a clearer path—more transparency, control, and predictability. Thanks for calling out the hype and starting an honest conversation that this industry really needs.
Cloudflare doesnt fall into the this Serverless stupid pricing...