One selling point is “free” horizontal scaling possibility. Contrived example: you’ve a parallelizable workload but the work arrives sporadically. 600 pieces of 10 minutes work arrive. In theory, instead of waiting 10 hours to process the batch on a single instance - lambda will fire up 600 instances completing the batch in 10 minutes. And 1 cloud CPU for ten hours costs the same as 600 for 10 minutes.
In practice, you spend more time writing lambda specific code and changing an obvious workflow to avoid DB access becoming a bottleneck or debugging why published events did not trigger the correct function, etc. that you wonder whether throwing cpu/memory/disk resources at a single instance tuned for the workload with dedicated local SSD storage might have been a better option especially as tasks around logging, persistent storage, debugging, profiling, error handling and getting stack traces are so much easier.
Yeah, I don't really see the appeal, either. I thought part of the point of something like this was that you no longer had to manage or think about the environment you're deploying to in the same level of detail.
But clearly you do, except now the resources, permissions, versioning, and costs you have to think about are all specific to various parts of AWS, which are locked in, probably more expensive, and probably less familiar than their counterparts on operating systems or in containers.
Seems like a lot of work for a kind of scalability that leaves you with little insight into how it works, idk
The expense depends on your use-case. I think that some SaaS products would be cheaper to host on Lambda. We have short bursts of high load, which led to quite a bit of waste with provisioning of traditional application servers and database.
After moving from traditional servers to Lambda, we had lower hosting cost. After switching, it is easier to deploy new back-end features. It is easier to provision a sandbox for development.
In our case, the cost savings were significant. More important, we have operational improvements: safer delivery of new features, comprehensive metrics, and comprehensive alerting.
Of course, there are many ways of achieving these goals. Kubernetes has great ways of doing the same with less vendor lock-in, but requiring more knowledge and care with the system components.
Vendor lock in is a non issue. Prices have been dropping across the board for basically all cloud services across all providers as long as cloud has been a thing. While the hosting itself might be 5x more expensive, you can generally run a large scale app on serverless infra with 20% of the SRE/platform headcount, and for nearly every engineering company the savings in salary costs and focus on product instead of platform will pay for themself very quickly and become a huge asset in the long run.
From a skills perspective, the vendor lock-in still bothers me on a personal level.
What's interesting about learning to push the right buttons on one company's black box, especially when I know it's likely powered by or equivalent to familiar F/OSS?
It’s not about what is interesting; it’s about what is productive. Kubernetes is interesting but I would not launch a project in it at a scale smaller than say 20M USD/year hosting costs because you’ll probably be able to make a higher quality project in a faster time if you use hosted/3rd party solutions
Security, ability to outsource pretty much everything ops-related besides cloud resource provisioning and deployments to the cloud provider and developer focus on business logic.
I don't know a better dev environment than a (possibly scaled down) personal replica of production environment in the cloud. With proper tooling (e.g. Serverless Stack or SAM) you can achieve very fast code updates so the old argument of slow feedback due to having to deploy changes to the cloud on each iteration is getting less and less true as well.
With more traditional models already keeping your OS, possible container images, web server and any other middleware secure and up-to-date is pretty expensive if you want to do it properly.
Going all-in on serverless might not make much sense for a large software product company but when building bespoke business software it allows small teams to do wonderful things very cost-effectively.
In practice, you spend more time writing lambda specific code and changing an obvious workflow to avoid DB access becoming a bottleneck or debugging why published events did not trigger the correct function, etc. that you wonder whether throwing cpu/memory/disk resources at a single instance tuned for the workload with dedicated local SSD storage might have been a better option especially as tasks around logging, persistent storage, debugging, profiling, error handling and getting stack traces are so much easier.