| 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. |