> Serverless is all about outsourcing the infrastructure for scaling a micro service.
Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests.
Of course, that is not tradeoff free. Scaling to 0 brings you right back to the old problem of slow initialization once a request does come in, which was the primary driver for why we moved to hosting the server in the application in the first place.
> Technically, it is all about removing the server from your application.
Technically its about removing the server from my list of responsibilities. There is still a server running my app, it just isn't managed by me and likely comes with auto-scaling features.
> Technically its about removing the server from my list of responsibilities.
Not necessarily. Back in the serverless CGI days you would still typically manage Apache. What you say is probably why would you choose serverless in 2025, but not always. This is not the technical differentiation.
> There is still a server running my app
There may be a separate server (e.g. Apache) that runs your app, but that is someone else's app, not your app. Calling someone else's app your own would be rather silly. Your application is less a server, which is a change from how these applications had normally been written over the past couple of decades. At least since the death of CGI, you would traditionally see your application become the server (possibly proxied through another server, but that is ultimately immaterial to the discussion). That is what goes away with serverless.
Scaling to 0 is pretty much the only benefit you get. Which is not much of a benefit at any reasonable scale. Fargate is same firecracker VMs as Lambda they just don't scale to 0.
And even then it is not strictly necessary. Cloud Run comes to mind as offering the ability to scale to zero, yet allows (maybe even requires?) maintaining the server in the application. The real benefit of "serverless" is that you no longer have to worry about the server, it being removed. Granted, that is not a big worry much these days with all the great server frameworks available.
I’d much rather write 20 lines of boilerplate code and a Dockerfile than deal with 100s lines of CDK code, distributed tracing, and the associated observability challenges.
Why? Just throw your program executable in the cgi-bin directory like we did in the olden days, go wash your hands, and then call it a day. Simple. Serverless!
Serverless doesn't have to be over engineered-garbage, even if some bored technologists looking for a promotion and/or to pad their resume try their best to make it so.
Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests.
Of course, that is not tradeoff free. Scaling to 0 brings you right back to the old problem of slow initialization once a request does come in, which was the primary driver for why we moved to hosting the server in the application in the first place.