From what I recall about that situation, they had a really stupid architecture that was using S3 as intermediate storage and processing video multiple times on multiple stages.
For the same amount of compute Lambda is priced far higher than Fargate which itself is priced higher than ec2. People run large workloads on k8s with base workload compute fully covered by dedicated ec2 instances not because it's fun, but because it saves you a lot of $.
Python is super slow, inefficient and let's say that the build environment is not so nice.
However, it's so easy to write functioning software in python that the alternative sometimes is not more efficient code, it's no code.
Lambda, in theory, follows a similar paradigm, if you can click a button and have a service that scales to zero (with logging and monitoring) then you're more likely to make toy webhooks and tiny services. If I have to make a build pipeline and a docker container and wrangle some yaml, configure service accounts and a service definition with the right labels and annotations.
Well, that's a decent chunk of work that means I'm probably going to think a bit longer about even deploying my little toy service that might see one request a day.
Going to reiterate though: I do not advocate for serverless in production. If you seriously think you're building something that will scale, it's fiscally illiterate to use a managed serverless provider.
If you under the impression that CI/CD and observability is easy with lambda I have a bridge to sell you. I worked on a large scale pure serverless project we wrote more CDK code than application code.
Serverless is more of a billing philosophy than a design philosophy in my opinion.
Serverless is all about outsourcing the infrastructure for scaling a micro service. How you design the service itself, or the system its a part of, can vary widely.
There are definitely dedign constraints of going serverless, but I'd argue those are largely just the constraints of going with microservices rather than a monolith.
> 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.
the pricing is different for the same amount of compute is that news for you? Lambda is priced an order of magnitude higher than fargate which is priced significantly higher than EC2. For small scale workloads your TCO might be lower with higher level abstraction.
In fact, the solution still used serverless afaik: https://www.youtube.com/watch?v=BcMm0aaqnnI
(take that u/UltraSane! https://news.ycombinator.com/item?id=42506205)
It likely could have been solved by serverless too, by using local storage and having the pipeline condensed into a single action...
FD: I'm not a fan of serverless for production anything.