Comment by scrollaway | Hacker News Reader

Comment by scrollaway | Hacker News Reader

Parent Full thread

I like to think that vendor lockin is something I care greatly about, for the correct reasons. In the case of AWS Lambda however, it doesn't apply.

Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app.

When I hear people say they're trying to "be generic", "abstract away serverless architecture" or some such, I'm replacing "serverless" with "asynchronous", or "functional", and it sounds bloody ridiculous, because it is.

If competitors to AWS lambda arise, I do hope they'll have a similar architecture available because that's where the power of Lambda resides. The "lock in" is only whatever those fake WSGI objects lambda is passing to the function are, as well as internal triggers for the servers (SNS, S3, ...). Those things can be abstracted away if competitors offer similar mechanism.

Trying to abstract serverless+serverful together is ridiculous. If you're successfully doing this, it sounds like your app doesn't belong in a serverless environment in the first place.

PS: There's plenty of drawbacks which are vendor-specific, not tied to the serverless design itself. For example, the Amazon API Gateway is atrociously bad. AWS Lambda doesn't even support Python 3, only Python 2.7 (get your shit together Amazon). Those are things I'd switch to a different vendor for in a heartbeat... if there was actual competition.

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

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.

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?

Reply on news.ycombinator.com