I agree, but in my experience, the lock-in with using Lambda is that you become integrated with other Amazon services (like S3 and DynamoDB) that are harder to replace if you abandon AWS entirely.

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.

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

> 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.

To me, that's the opposite of lock-in. You can leave AWS because you can move away from any one service easily without affecting the others. There are even vendors who directly implement (for example) S3's API so you have almost no code to change.

Traditional vendor lock-in is when you can't move away from (e.g.) your Oracle database because you've got a dozen different applications that will need simultaneous rearchitecting if you ever want to get away from it.

If anything — 50 LoC seems like it might even be an overestimate. I use a wrapper function around all my lambdas that deals with translating from the aws http headers to an application standard, asynchronously retrieves a config object, and converts promise based business logic to the aws callback format. The actual business logic is then written almost entirely in terms of the business domain. The wrapper is less than 50 lines and extremely easy to write. Making an equivalent wrapper for another cloud function provider would be easy ...

Someone thinking the need to adapt the input parameter format to achieve provider portability is by itself enough reason to add docker to the application stack is making a huge mistake in accessing the relative cost of these components ...

I don’t think deploying containers to different providers is anymore standard than the differences involved in deploying cloud functions to different providers so it’s not as if using docker would actually give a more uniform multi-provider deployment model ...

Is your wrapper code open source? If so, mind sharing a link?

EDIT: I'm actually less curious about the code, and more curious about how you're sharing code between different Lambda functions. Did you publish an npm package? Are you just repeating the code? Symlinks?

The wrapper isn’t open source. The project is node (typescript) and uses serverless [serverless.com] for packaging and deployment.

Serverless allows deploying multiple lambdas with entry points exposed from an npm package using cloud formation with standard code sharing practices applying — that is it’s easy to share code between entry points if all the entrypoints are defined in one serverless config file (one serverless config file corresponds to one cloud formation stack)...

It’s a bit more work to share code between stacks with serverless tho ... You either have to put shared code into a separate npm module and depend on that module everywhere you need the shared code (often incidental complexity for simple or unstable code!) or use symlink patterns that work with the grain of how the serverless bundling process works...

I actually created an issue suggesting a serverless feature to ease this a few months ago https://github.com/serverless/serverless/issues/4124. In that somewhat long feature request I describe the symlink pattern I’m using for easily sharing code and compilation contexts between stacks... I’m still using that pattern — it’s not terribly fun to explain to new developers on the project but it works well without a lot of gotchas so far ...

Why functions over Docker or Elastic Beanstalk? There's more than one PaaS path.

On vendor lock-in, I'm moving between clouds now. Serverless did not translate well at all. We would have saved a ton of time, and frankly had an easier operational experience, if we went with Docker from be beginning.

"Ok Jill, next we need to determine how Azure Storage Account bucket calls differ from AWS S3. Oh, S3 doesn't have queues so we need to use SNS which changes the transaction model...Yeah, we've gotta handle different guarantees"

Product at most places "doesn't have the time" for developers to abstract the serverless hooks. You have to change the interface that runs your app instead.of the interface your app provides.

Wait does Azure Storage finally have events? Personal project of mine I moved from Azure to AWS simply because Azure Storage didn't have events...

Yeah, Azure Storage Accounts have events now.

https://azure.microsoft.com/en-us/blog/announcing-azure-blob...

Thanks!