News for hackers. Stuff that matters.
Re:Announcing Go Support for AWS Lambda by philliphaydon on Tuesday January 16, 2018 @12:32AM (#16156051)
There is no lock-in... you can write an agnostic function for both AWS lambda and azure function.
Re:Announcing Go Support for AWS Lambda by benatkin on Tuesday January 16, 2018 @01:06AM (#16156174)
I'm aware of tools like Serverless. They help remove the lock-in in some situations. That doesn't mean there's no lock-in to speak of at all.
Re:Announcing Go Support for AWS Lambda by philliphaydon on Tuesday January 16, 2018 @02:03AM (#16156347)
In regards to C# functions, there is no lock-in to AWS, it's a piece of code, you can run that function on AWS Lambda, or in ASP.NET Website, or Azure Function, or console app...

It's literally a method which has a single parameter class, and a single class returned...

Even if you're using node, java, golang, python. Other than the packaging. How is there any lock in?

Re:Announcing Go Support for AWS Lambda by hueving on Tuesday January 16, 2018 @02:33AM (#16156447)
Aren't you spending resources setting up your CI/CD pipeline /deployment tooling to talk to Amazon's APIs?

Unless all of the providers have the same API to deploy functions, they are all trying to lock you in.

So not lock-in at the code level (unless your serverless app talks to S3 or whatever Amazon services), but lock-in of your whole devops process.

Re:Announcing Go Support for AWS Lambda by philliphaydon on Tuesday January 16, 2018 @03:04AM (#16156542)
So first it's all "Oh you're locked into IIS" and "You're locked into Windows", then "You're locked into AWS" now it's all "You're locked into your CI/CD pipeline"

It sounds like, no matter what you do, you're locked in. Using Docker? Ah you're locked into Docker. Wrote your app in PHP, on you're locked into PHP now.

I just don't understand this whole 'lock-in' mindset, it's just absurd now.

Re:Announcing Go Support for AWS Lambda by hueving on Tuesday January 16, 2018 @04:05PM (#16162578)
>I just don't understand this whole 'lock-in' mindset, it's just absurd now.

If you don't understand it, then it's probably not absurd.

Look into the whole free software movement and the history behind it (e.g. the evils of Microsoft in the 90s).

If a vendor can change a price on something that forces you to pay up or lose your system, you are locked in.

This isn't just some open source ideology without impacts either. It should be immediately obvious to anyone with any business acumen why making yourself beholden to the decisions of a single vendor is a bad position to be in.

Re:Announcing Go Support for AWS Lambda by Nullabillity on Tuesday January 16, 2018 @04:29AM (#16156856)
The vital difference being that Docker and PHP aren't subscription-based, and aren't controlled by a single corporation.
Re:Announcing Go Support for AWS Lambda by philliphaydon on Tuesday January 16, 2018 @05:16AM (#16157081)
Replace Docker and PHP with anything and the same is true tho.

If you write your application in any language, or use any framework or library, you're locked in, by today's standards.

Re:Announcing Go Support for AWS Lambda by hueving on Tuesday January 16, 2018 @03:59PM (#16162506)
The difference is that you can't be screwed by a single company deciding to change prices. When people refer to "lock-in", they are referring to being able to be screwed by a single vendor.

Nobody cares if they are locked into x86, tcp/ip, and http. If you don't understand this difference as an engineer, you end up causing a big risk to your company (or clients) without even knowing it.

Re:Announcing Go Support for AWS Lambda by philliphaydon on Tuesday January 16, 2018 @08:39PM (#16164741)
Oh so now it’s paying for something that’s lock-in. This lock in sure keeps changing.
Re:Announcing Go Support for AWS Lambda by benatkin on Tuesday January 16, 2018 @03:12AM (#16156562)
If you look at the amount of work Serverless has to do, packaging can generate quite an amount of lock-in. It is hardly any lock-in in the simple cases of grabbing a single function and deploying it where you want.