5 ms·

All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and

by koluna 6y ago

All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows and sleep much better (and at lower maintenance cost). [0]: https://news.ycombinator.com/item?id=25268049 https://news.ycombinator.com/item?id=25268049

landerwust 6y ago
Your lambda function can be a container
- koluna 6y ago
  Why would you want to put it in Lambda then when there are better options?
  - deleted 6y ago
    [deleted]
  - landerwust 6y ago
    There is no better option for temporally sparse compute. If your job can run all the time there is no benefit to these systems, but if it wastes money by being provisioned all the time when not in use, there is no alternative. Lambda is neither "worse" nor "better" in any general sense. It's just another option that might apply given a particular scenario, and one that got significantly cheaper today.
gpmcadam 6y ago
After using lambda quite a lot recently I think the vendor lock-in argument is overstated, especially with things like Serverless framework. The lock-in comes more with the other AWS products you end up using such as CloudFormation and DynamoDb, but not Lambda which in most cases can be wrapped around an Express server or similar and could be hosted anywhere
- acdha 6y ago
  There's definitely a balance. I tend to be more concerned about things which store or update data durably — testing a Lambda function is relatively easy, and if you're calling other services but your code isn't a complete mess that's a relatively manageable problem, but something like DynamoDB poses both a migration challenge (especially for a running system) but also questions about correctness if you aren't really careful about how you handle things like concurrent access. That doesn't mean they're not worth using but it definitely tells me where you want robust validation, testing, etc. since it's a lot harder to recover from missing/corrupted data than it is to resolve a 500 error on a particular endpoint.
zild3d 6y ago
https://www.serverless.com/ https://www.serverless.com/ abstracts a bit, so there's less lock in, but agree typical lambda workflows aren't just plain code you can move to a different vendor. A big perk is easy triggers to glue things together like new S3 file -> run lambda
- scrollaway 6y ago
  I use Serverless framework even when I only want to deploy on Lambda. It's such a wonderful tool.
munns 6y ago
That is not at all what my words say and I won't reply to that thread which was started by a former competitor to troll this convo today. The perceived lock-in is really no different than consuming other technologies. You make a trade-off on what you want to manage vs. handoff to a managed service. For many customers the benefits are well worth it. It's fine that Lambda wasn't for you, but you aren't being clear here about what issues you saw, just waving the lock-in boogey man so many misunderstand.
- koluna 6y ago
  Cost, lack of debugging capabilities, terrible developer tools, cryptic documentation that misses some key scenarios, I can go on. Now, I get it, you’re at AWS so you would never openly and bluntly come out and say that what you -really- want is to lock in your users, because that brings AWS money. But that’s the reality. See my earlier comment as to why it made sense for our company to move away from Lambda.
  - orf 6y ago
    What even is your point here and in this thread? Acquiring customers and giving them an incentive to stay is a cornerstone of any enterprise. Saying lambda is bad because of lock-in is like saying their VPC offering is bad because of lock-in, or IAM is bad because of lock-in. It's not a generic component that you can flip between providers, they usually respond to a specific event from an AWS service and nobody really gives a rats about deploying their specific lambda to a cloud they don't use. So yeah it seems like a real awesome idea to avoid vendor lock in for a small python function that responds to S3 change events from a SQS queue and updates a DynamoDB table with some values. If you want "generic" lambdas go check out serverless.com.
blantonl 6y ago
I'm pretty sure we've reached an inflection point with some "technical architects" where they spend more time worrying about vendor lock and doing technical gymnastics to reach portability nirvana instead of just shipping decent code and products that make money.
- koluna 6y ago
  YMMV, of course. The problem with lock-in is that you start designing code that is for a given vendor, AWS in this case. Once you find that the vendor either is prohibitive cost or functionality-wise, you will have to spend your development resources untangling the mess rather than shipping value.
hbbio 6y ago
We use λ with Go and the change between the service and its λ counterpart is really minimal. FYI, we're using https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy which supports most Go web frameworks. Edit: We also use DynamoDB and there lies the real vendor lock-in with AWS imho.

by koluna 6y ago

landerwust 6y ago

Your lambda function can be a container

koluna 6y ago
Why would you want to put it in Lambda then when there are better options?
- deleted 6y ago
  [deleted]
- landerwust 6y ago
  There is no better option for temporally sparse compute. If your job can run all the time there is no benefit to these systems, but if it wastes money by being provisioned all the time when not in use, there is no alternative. Lambda is neither "worse" nor "better" in any general sense. It's just another option that might apply given a particular scenario, and one that got significantly cheaper today.

gpmcadam 6y ago

After using lambda quite a lot recently I think the vendor lock-in argument is overstated, especially with things like Serverless framework. The lock-in comes more with the other AWS products you end up using such as CloudFormation and DynamoDb, but not Lambda which in most cases can be wrapped around an Express server or similar and could be hosted anywhere

acdha 6y ago
There's definitely a balance. I tend to be more concerned about things which store or update data durably — testing a Lambda function is relatively easy, and if you're calling other services but your code isn't a complete mess that's a relatively manageable problem, but something like DynamoDB poses both a migration challenge (especially for a running system) but also questions about correctness if you aren't really careful about how you handle things like concurrent access. That doesn't mean they're not worth using but it definitely tells me where you want robust validation, testing, etc. since it's a lot harder to recover from missing/corrupted data than it is to resolve a 500 error on a particular endpoint.

zild3d 6y ago

https://www.serverless.com/ https://www.serverless.com/ abstracts a bit, so there's less lock in, but agree typical lambda workflows aren't just plain code you can move to a different vendor. A big perk is easy triggers to glue things together like new S3 file -> run lambda

scrollaway 6y ago
I use Serverless framework even when I only want to deploy on Lambda. It's such a wonderful tool.

munns 6y ago

That is not at all what my words say and I won't reply to that thread which was started by a former competitor to troll this convo today. The perceived lock-in is really no different than consuming other technologies. You make a trade-off on what you want to manage vs. handoff to a managed service. For many customers the benefits are well worth it. It's fine that Lambda wasn't for you, but you aren't being clear here about what issues you saw, just waving the lock-in boogey man so many misunderstand.

koluna 6y ago
Cost, lack of debugging capabilities, terrible developer tools, cryptic documentation that misses some key scenarios, I can go on. Now, I get it, you’re at AWS so you would never openly and bluntly come out and say that what you -really- want is to lock in your users, because that brings AWS money. But that’s the reality. See my earlier comment as to why it made sense for our company to move away from Lambda.
- orf 6y ago
  What even is your point here and in this thread? Acquiring customers and giving them an incentive to stay is a cornerstone of any enterprise. Saying lambda is bad because of lock-in is like saying their VPC offering is bad because of lock-in, or IAM is bad because of lock-in. It's not a generic component that you can flip between providers, they usually respond to a specific event from an AWS service and nobody really gives a rats about deploying their specific lambda to a cloud they don't use. So yeah it seems like a real awesome idea to avoid vendor lock in for a small python function that responds to S3 change events from a SQS queue and updates a DynamoDB table with some values. If you want "generic" lambdas go check out serverless.com.

blantonl 6y ago

I'm pretty sure we've reached an inflection point with some "technical architects" where they spend more time worrying about vendor lock and doing technical gymnastics to reach portability nirvana instead of just shipping decent code and products that make money.

koluna 6y ago
YMMV, of course. The problem with lock-in is that you start designing code that is for a given vendor, AWS in this case. Once you find that the vendor either is prohibitive cost or functionality-wise, you will have to spend your development resources untangling the mess rather than shipping value.

hbbio 6y ago

We use λ with Go and the change between the service and its λ counterpart is really minimal. FYI, we're using https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy which supports most Go web frameworks. Edit: We also use DynamoDB and there lies the real vendor lock-in with AWS imho.