Parent post didn't say anything about abstracting away "serverless". Lock-in refers to (as the OP article discusses) the fact that if you use AWS Lambda, you are tied to their APIs and deploy mechanisms. If you want to move to Google's FaaS offering, you have a lot of work to do, and may need to restructure your app logic as well.

And that's wrong; a complete misunderstanding of how both serverless in general and Lambda specifically works.

You provide an entry point to your application. AWS provides you with an `event` and `context` object, both of which are nonstandard. You extract, out of those objects, the data you care about... and you pass it down to whatever it is you want to run.

The extraction is very simple. Here, take a look at a SNS-triggered lambda:

https://github.com/HearthSim/HSReplay.net/blob/e12a6b8217b3b...

One line of code is vendor-specific. I could move to a different vendor in a heartbeat. Yes, bits and pieces are using SNS/S3; some of which are already abstracted away, the rest which can be easily replaced.

And frankly, when dealing with platforms as large as AWS, the vendor you choose is a big deal. You're not supposed to change every week... so it doesn't matter if it takes a little cleanup to move to another vendor. If it's taking you more than a few hours, your code is making assumptions it shouldn't about the underlying architecture and that's your fault, not amazon's.

I don't think your code example supports the point you're trying to make. Of 3 lines of non-logging code, one of them is AWS-specific, and so would need to be refactored to use another FaaS platform. That's what lock-in refers to. It's not saying you cannot migrate at all, it's just saying that there's a refactoring cost to swap out the platform APIs.

If you can get the same message-delivery semantics from Google's message bus, then the refactor would end there, but if you happen to be depending on a feature that's not implemented on your new platform, then you might have to refactor your application logic further.

Furthermore, you still have to get your code into production, upgrade it, monitor it, and ensure that the other functions that it, and all of that currently tends to depend on platform-specific tooling.

Much of this is also the case in the VM-based PaaS world. But, there you have projects like libcloud that can abstract some of the differences away. That feature gap is pointed out in the OP article, which makes it clear that the lock-in issue isn't a fundamental defect with the functional paradigm, just a side-effect of the FaaS offerings being young.

I agree with this

If you've designed your client-side javascript (or swift or whatever it is) properly, you've abstracted out the API calls to say, AWS Lambda, and wrapped them such that the implementation is not tightly coupled to the calling code. Eg you write a generic Storage class and call Storage.Save, which wraps whatever API you use to save stuff, be it Lambda or otherwise. Change vendor and you just change your Storage class's implementation without needing to alter client functions..

You can run all the Python 3 code you want. Just execute it from the Python 2.7 environment. The AWS Lambda environment does support it as the AWS environment is just the basic Linux AMI, and then you can include anything you want into your Lambda code zip file. You can exactly replicate the Linux image they use for Lambda and create your own custom environment that will run your code. What more could you ask for?

I know, and this is far slower as it involves a serialization/deserialization pass on the data as well as a subprocess.

> What more could you ask for?

Native support. Was that not obvious?