The servers still exist.
They have simply become AWS’s problem, which may be the healthiest delegation decision you make this week.
AWS Lambda runs your code when triggered, without requiring you to manage the underlying servers.
It works well for APIs, automation, event processing and scheduled tasks.
But not every workload belongs in Lambda.
Serverless is an architecture choice, not seasoning that must be sprinkled onto every application.
#AWSWithoutTheFluff #AWSLambda #Serverless

Ezile Mdodana

Serverless doesn't eliminate servers — it delegates their management to AWS. AWS Lambda executes code on-demand without server provisioning, making it suitable for APIs, automation, event processing, and scheduled tasks. However, serverless is an architectural choice with tradeoffs, not a universal solution for every workload.

Day 11/30: Serverless does not mean there are no servers

Exactly, but a lot of people fails to understand this simple thing.

the real tell for ‘not lambda’ isn’t vibes, it’s whether the workload needs a warm resource (db pool, browser instance, model in memory). those pay a cold-start tax every time on FaaS that never amortizes.

There’s a lot of things I love serverless for, particularly things that just aren’t running most of the time.
One of my favorite lambdas is I have one that whenever an image file is uploaded to a particular S3 bucket, a routine that goes and makes an optimized version of the same image that’s good for web stuff. Only needs to happen when something is uploaded which is not all the time, no reason to be pa ying to run a server that sits idle 90% of the time.
The flip side of this equation is if you have something that is running all the time, your cold start tax as <a href="https://daily.dev/pdfopsdev" data-mention-id="orjMeK8QKaaVZwGq7ScPz" data-mention-username="pdfopsdev" translate="no">@pdfopsdev</a> points out is particularly bad, and it can quickly become more expensive to run as well.
There’s also a big danger of making a costly mistake.
When someone created a version of the lambda I outlined above, I saw them make a critical failure that ended up costing hundreds of dollars in minutes. S3 bucket, upload an image, triggers a lambda to make an optimized version of the image and upload it back to the S3 bucket. Sounds great… except they didn’t put logic in place to make sure that when it uploads the image back to the bucket… that triggered the same lambda to run AGAIN… which then triggered it to run again… and again… and again… Next thing people are asking me why our lambda usage is spiking so high.

The decision is usually about workload shape, not whether servers are visible. I would compare burstiness, execution duration, concurrency limits, warm state, retry semantics, and cost at p95 traffic before choosing Lambda. Event processing fits well when handlers are idempotent and bounded; long-lived connections, large models, or expensive startup state often need a container or durable worker. The operational burden moves to limits and observability even when patching the host disappears.

I think Lambda fits workloads that spend most of their time idle. The quiet minutes stop showing up on the bill.