AWS Lambda “lock-in”
Slightly confused how a service that takes *native code* (in a variety of languages) and executes it in response to events, then charges in 100ms increments, with no minimum commit, constitutes the worst lock-in in history?
Contrast this with some legacy providers that use multi-year agreements and “surprise” audits, minimum spend, etc. to make sure you don’t leave their Platform.
I understand the concern people have who argue that Serverless is a form of architectural lock-in, but even that is a form of FUD - the argument goes that you’re locked in to proprietary tech on a specific cloud vendor platform, ignoring the fact that *every* tech choice has some sort of lock-in issue, whether in software, database, language, knowledge, architectural patterns, etc.
If you follow best practices for architecting a Serverless application, then you’ll break down your app into a series of micro services. Each of these has the potential to be ported without impacting the rest of the app. Yes, this takes time, but you balance that (hopefully low) risk against the benefits of agility and delivering services quickly on your chosen platform.
In my experience, the reason people use Lambda (or Azure/Google functions) is that it allows you to focus on the business problem being solved, not worrying about the underlying infrastructure. Is Serverless suitable for every use-case - no, it isn’t - but in *many* cases it provides a far more flexible, secure, responsive environment than traditional architectures.