Hacker News Reader

Comment by davidw | Hacker News Reader

Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

View on HN

In almost all cases, there's a significant difference in the sort of risk that comes from B/FaaS dependencies and the sort of risk that comes from PL lock-in. The former leads to technology lock-in and vendor lock-in, while the latter almost never[1] leads to vendor lock-in.

Technology lock-in without vendor lock-in isn't that huge of a liability. A popular PL under an appropriate license isn't going to disappear tomorrow, and its creator doesn't have the power to hold your business at gunpoint. Conversely, B/FaaS providers upon which you truly depend definitely can extract (or by disappearing simply destroy) much more value than you originally anticipate.

[1] If you use Wolfram Language or Matlab then your choice of PL causes vendor lock-in, but most PLs aren't like this.

I agree - "vendor lock-in" seems like a valid point, although I don't know the details of many of these services. "Locked into a programming language" is something that will probably happen kind of naturally anyway.

> Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

The difference is one doesn't have access to Lambda infrastructure itself. IF I write an entire app in XYZ lang, I can still run it on my own server or make it an executable and call the code through RPC. If I base all my work on a third party vendor infrastructure I can't replicate it requires an even more massive effort to migrate to something else, because now I basically have to re-write my app from scratch. FAAS may have killed BAAS but isn't going to kill PAAS.

Why would you have to re-write your app from scratch? I'm assuming most of your actual business logic is in the Lambda code and the data model. Lambda wraps things pretty tight anyway, so just write a shim layer, and lift-shift your code to a new platform.

Completely agree with this. There is one project[1] we're working on which aims to provide said shim, but it's still early days. Developer tools will emerge to solve the major issues around serverless.

[1] - https://github.com/iopipe/turtle

I don't follow. You can write other modules in different languages. The data sources are language agnostic. Nobody forces you to do use a specific programming language in the first place unless the platform is close sourced. The point is that with a close source BaaS you have no control on the tools or costs or availability(i.e. deprecation policy) of the service.

Locked in maybe, but not vendor locked in if the language is open source.

Yeah, I guess less so now, but before C# was open sourced the only viable option was Windows servers and people usually used SQL Server with it. So in that case many people chose to lock themselves into that vendor and stack. So in my mind Lambda as a back end is no worse than that in terms of vendor lock-in. I suppose that Amazon will be able to provide support for many years given how much of the internet currently runs off of them.

Reply on news.ycombinator.com