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.

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.

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.

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.

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.

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

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.

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

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

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 which supports most Go web frameworks.

Edit: We also use DynamoDB and there lies the real vendor lock-in with AWS imho.

Your lambda function can be a container

Why would you want to put it in Lambda then when there are better options?

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.