[mikhmha]

I work at a enterprise SAAS startup that uses lambda for backend. I agree with a lot of what you say.

But I also disagree with you. Lambda ends up being very cost effective at the place I work at. Its a payment processor so lambdas are only ever run in response to approved transactions. For this sort of SAAS the economics of lambda work very well. I'm not sure what would be better. Of course if I were running a public facing free web service I would not use lambda, but for something where every user is a paying customer? I think Lambda is very cost effective. And if it ever got to the point where moving to k8's would result in a massive cost-savings, I would just pay a guy like you to handle the migration. At that point its probably not a small startup anymore.

[jpgvm]

Yeah that is fair. I think the contention I have with it is those runtimes generally don't save time or money but come with more constraints - constraints that usually lead to poor architecture decisions.

Examples I have seen include:

Massive/mono-lambda - this is caused by the overhead of managing many functions so instead everything gets packed into one with some sort of router logic. The usual cause of this one is managing many Lambda/FaaS things becomes too hard, especially if you are also using API Gateway and friends.

Resource misuse - the nature of these FaaS runtimes is they are essentially glorified cgi-bin, in all the worst ways. Namely they tend to mask memory leaks and other poor programming habits until they start leaking through as spurious failures.

Poor observability - because FaaS results in unpredictable lifetimes you end up making concessions in your observability stack. Can't do in-process rollup, can't do pull model metrics, i.e Prometheus, etc. You can somewhat get away with this with doing full tracing and sampling on the collector side instead but you have just made the whole thing inefficient for...what exactly?

Unnecessary cron-like things - this usually comes from places that try to go all-in on FaaS and squeeze everything into FaaS shaped boxes. Something that would much better be a daemon that spreads it's work over time cleanly becomes a cron-like thing that fires every minute, usually spawning 1000x of sub-FaaS things to accomplish some maintenance task paying huge amounts of overhead. Again... for what?

Poor DB connectivity options - again linked to unpredictable lifetimes and "unlimited scale" you don't have as many options for DB connectivity, you have to invest in bouncers immediately even if your application would actually be fine running on just 10 connections or so... if you had 10 containers instead of potentially 100s of lambdas.

Poor resource sizing options - sometimes you just need a fk-ton of RAM to solve your problem. Most of the FaaS providers limit not just your max runtime but also max resources you can grant said function. Leading again to sub-optimal work splitting for memory hard problems.

The list keeps going on tbh, this is far from exhaustive.

At the end of the day the tradeoffs aren't worth it. The only thing of value you get in return is "unlimited scalability" which is easily approximated with k8s primitives.

I really don't see why k8s shouldn't be the default option for anyone considering these FaaS things given GKE/AKS/EKS exist and do 99.99% of the work for you and are WAY less complicated than the FaaS runtimes and their associated requirements.