3 ms·

That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. On top of that, many of AWS's services use standard API's

That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways... If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using RabbitMQ.

zapita 9y ago
> That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't. Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.
np_tedious 9y ago
There are a finite set of this to trigger the function and they become central to API Gateway, kinsesis, s3 change/addition... It definitely has more lock in potential than more "vanilla" offerings like EC2, RDS, S3. You could name a replacement/competitor service for each of the above, but if the Lambda is triggered by S3 changes then that's a big barrier to putting your static files elsewhere