'Lambda and serverless is one of the worst forms of proprietary lock-in we've ever seen in the history of humanity'

Toward the end of this month, CoreOS CEO Alex Polvi expects Amazon will introduce a managed Kubernetes service at its AWS re:Invent event. If so – CoreOS CTO Brandon Philips cites some Kubernetes bug reports from Amazon as evidence – it will be an admission of what most people focused on software containers already know: that …

[Anonymous Coward]

AWS Lambda “lock-in”

Slightly confused how a service that takes *native code* (in a variety of languages) and executes it in response to events, then charges in 100ms increments, with no minimum commit, constitutes the worst lock-in in history?

Contrast this with some legacy providers that use multi-year agreements and “surprise” audits, minimum spend, etc. to make sure you don’t leave their Platform.

I understand the concern people have who argue that Serverless is a form of architectural lock-in, but even that is a form of FUD - the argument goes that you’re locked in to proprietary tech on a specific cloud vendor platform, ignoring the fact that *every* tech choice has some sort of lock-in issue, whether in software, database, language, knowledge, architectural patterns, etc.

If you follow best practices for architecting a Serverless application, then you’ll break down your app into a series of micro services. Each of these has the potential to be ported without impacting the rest of the app. Yes, this takes time, but you balance that (hopefully low) risk against the benefits of agility and delivering services quickly on your chosen platform.

In my experience, the reason people use Lambda (or Azure/Google functions) is that it allows you to focus on the business problem being solved, not worrying about the underlying infrastructure. Is Serverless suitable for every use-case - no, it isn’t - but in *many* cases it provides a far more flexible, secure, responsive environment than traditional architectures.

[Adam 52]

Re: AWS Lambda “lock-in”

Lambda locks you into the AWS event model and deployment model. Yes you could move elsewhere by reimplementing the event model on top of some other messaging system and a scalable node.js runtime but it's a lot of work.

I tend to take the view that if you didn't use Lambda then you'd have had to do that work anyway, so in the event of a move you're no worse off and if you never have to move then you've saved.

[Anonymous Coward]

Re: AWS Lambda “lock-in”

" reimplementing the event model on top of some other messaging system and a scalable node.js runtime"

Stopped reading at this point, mentally consigned the rest of the comment in the bin. Anyone who considers javascript to be a serious backend language doesn't belong in IT.

[SpaceAlienMagician]

Re: AWS Lambda “lock-in”

Considering that javascript is currently the most widely used programming language and thousands of companies successfully use node.js on the backend I would say you're spot on wrong. Can people write bad JavaScript code? Sure. Bad Go code? Sure. Bad C? 98% guaranteed.

Node.js is one of the most successful open source projects ever. To write off node.js devs is pretty naive on your part, but I guess that should be expected from someone who can only pay attention long enough to read 1 line of someone's comment and then type a poorly thought out 2 line response. :shrug:

[Anonymous Coward]

Re: AWS Lambda “lock-in”

"Slightly confused how a service that takes *native code" - it's not 100% native code - you have to use Amazon specific APIs.

[Anonymous Coward]

Re: AWS Lambda “lock-in”

Lambda is really not an example of platform lock-in; it's more an application architecture.

On the server side, it's relatively painless to run your code in different Lambda-style platforms. It is, after all, just a python function or javascript function which takes an input, does stuff, returns a result. You can wrap it in a web server if you prefer.

On the client side, it's easy to have a thin wrapper which call functions in AWS Lambda, or Google Functions, or via JSON-over-HTTP, or whatever.

[patrickstar]

Re: AWS Lambda “lock-in”

Why would you ever want to write anything that's actually important in either Python or JavaScript?

They are, beyond reasonable doubt, two of the worst languages for the purpose.

I know you can compile other languages to JS, but still...

[FIA]

Re: AWS Lambda “lock-in”

Why would you ever want to write anything that's actually important in either Python or JavaScript?

They are, beyond reasonable doubt, two of the worst languages for the purpose.

How do you know what the purpose is??

If you make choices like that without understanding the problem then more fool you.

[Anonymous Coward]

Re: AWS Lambda “lock-in”

"Why would you ever want to write anything that's actually important in either Python or JavaScript?"

Python can be ok for small to mid sized projects, but javascript is a joke. Why would you? Professional server side coders wouldn't - they'd use C++,C# or Java. But our ranks have been infiltrated by former web and/or "app" coders who know the square root of bugger all about 24/7 uptime requirements or anything to do with efficient CPU usage or frankly even decent coding. The only thing they know is javascript so they've brought their toy language over from the browser world and are now trying to use it to do business critical systems programming with. If it wasn't so worrying it would be funny.

[patrickstar]

Re: AWS Lambda “lock-in”

I wouldn't consider a language where you don't even have to declare variables for anything where actual important things are at stake...

[Destroy All Monsters]

Re: AWS Lambda “lock-in”

Python can be ok for small to mid sized projects, but javascript is a joke. Why would you? Professional server side coders wouldn't - they'd use C++,C# or Java. But our ranks have been infiltrated by former web and/or "app" coders who know the square root of bugger all about 24/7 uptime requirements or anything to do with efficient CPU usage or frankly even decent coding. The only thing they know is javascript so they've brought their toy language over from the browser world and are now trying to use it to do business critical systems programming with. If it wasn't so worrying it would be funny.

Printed out, framed, put into a little Shinto shrine I keep in the server room, with a glass of Sake. White paper decorations rustle in the ventilator breeze.

[Shameless Oracle Flack]

Re: AWS Lambda “lock-in”

You can keep making excuses for AWS, but it's not complicated: the API's are Amazon-specific and you cannot run this code elsewhere. Larry said it best: AWS is more closed than the IBM mainframe. At least mainframe hardware was produced by companies other than IBM.

[ExampleOne]

public cloud == someone elses server.

serverless == someone elses server with new hype word.

The article even touches on the problem with running your operations like this in the last paragraph.

[John Smith 19]

The 90's called. They'd like Tivoli back.

So it's enterprise management, without an actual enterprise, 'cause y'know, "The Cloud." Blah blah.

[Anonymous Coward]

Re: The 90's called. They'd like Tivoli back.

Yuck - Tivoli - Perl based and the buggiest platform I ever worked on.

[Anonymous Coward]

Re: The 90's called. They'd like Tivoli back.

You can also add any Java EE or CORBA application server - they were designed for the same requirements, ease of deploy, management, resource sharing, load balancing, etc etc.

Just you write applications that believes to be standalone ones, and try to perform all the needed tasks below them, so you can still use cheap developers to write cheap applications and hope to manage them in some sensible way - for a given meaning of sensible.

[Whitter]

I may not be in DevOps, but this looks a killer quote (if true...?)

"We've heard from our customers, if you cross $100,000 a month on AWS, they'll negotiate your bill down," said Polvi. "If you cross a million a month, they'll no longer negotiate with you because they know you're so locked that you're not going anywhere. That's the level where we're trying to provide some relief."

[K]

Re: I may not be in DevOps, but this looks a killer quote (if true...?)

"but this looks a killer quote (if true...?)"

Basically, what he's saying is his brother heard from a friend, who has an acquaintance, who's daughter worked with somebody who read something online..

I'm personally a cloud hater, you can see it in my previous posts. So I have no wish to defend AWS (always preferred my own tin). But I work for one AWS's biggest European customers (does that make me a hypocrite?!! Hmm), but this guy is talking shit, they give surprisingly good discounts if you ask nicely and negotiate properly.

In addition, if you've got an enterprise agreement, you'll get a hell of a load more, including service credit (think money off vouchers, to use where you want).

[Anonymous Coward]

Re: I may not be in DevOps, but this looks a killer quote (if true...?)

Yeah, we spend well north of $1m a month and often compete directly with AWS. Amazon's sales guys are much like any others. There are quotas to be met and discounts to be had. They know that we're all keen to avoid lock in so they try to make the process of locking us into AWS as painless as possible.

This wasn't always true - for a long time there simply wasn't an AWS sales team, and heaven help you if you needed some support. Now? Bollocks.

[Anonymous Coward]

I'm wondering on how efficient this all is

I see a number of layers added to running an application here which strikes me as adding to stack complexity and operational overhead. Has anyone done a compare between a service on a platform and one that appears to be running through various interpreters/emulators?

I accept this may save bodies if you have a large number of these services to run, but it would be nice to find out a cross-over point - and efficiency counts towards the whole ecological aspect.

(note: I'm a newbie when it comes to cloudy stuff but oldtimer when it comes to make things work that must. not. fail. - usually because it would cost lives otherwise - so I'm looking at cloud services only in the context of "stuff we won't miss when it falls over" :) )

[Pascal Monett]

Re: I'm wondering on how efficient this all is

I think the point here is about the $million cloud customers. They're the ones paying the big bucks that make the cloud seem to be a viable platform for everyone.

Push a button and it drives itself ? Sure, once a hundred IT techs have slaved away at building all the conditions and checks and verifications that allow that button to exist. Big Corp has access to the manpower and the knowledge, small businesses do not. The Cloud can work for small businesses, but it is made for Big Corp.

That is why I have trouble with the sentence : "the open-source community has to provide alternatives". With all the faith I have in the coding abilities of Open Source volunteers, they are working from home and I doubt they have access on a personal level to the amount of hardware required to test an open source solution to AWS. And even if code could feasibly be written, the Cloud is hardware and software both, and Open Source doesn't have the hardware.

I don't see that happening. Not without major investment by Red Hat or something similar in any case.

[dajames]

Re: I'm wondering on how efficient this all is

... I have trouble with the sentence : "the open-source community has to provide alternatives". With all the faith I have in the coding abilities of Open Source volunteers, they are working from home.

Not all of them work from home. An awful lot of them work for big companies like IBM, Microsoft, Google, Facebook, Oracle, and Amazon ... not to mention the likes of Red Hat, Canonical, and SuSe ... and not forgetting the Linux Foundation!

I think that it is mostly to companies like these that the article refers when it speaks of an Open Source community.

[Anonymous Coward]

"An awful lot of them work for big companies"

So don't call it a "community" - say "the big open-source contributors and beneficiaries have to provide alternatives..."

[Anonymous Coward]

"I see a number of layers added to running an application"

I see things that should be added to the OS level being implemented with layers and layers atop the OS, usually with a lot of slowing-down technologies, a true house of cards.

One day someone will awake, implement all of this at the OS level, and the layers will go away, with most of the companies built atop them.

[cdegroot]

Nothing new...

I think what you describe is called a "mainframe". Which seems to me what Sillicon Valley is very busy reinventing. Now including proprietary hardware.

[Anonymous Coward]

Re: Nothing new...

I can't help but notice that these "serverless" gizmos have exactly the same execution model as CICS transactions...

Mainframe reinvented, indeed!

[John Smith 19]

"these "serverless" gizmos have exactly the same execution model as CICS transactions..."

I read a book on CICS ages ago and thought "WTF is this about?"

Then it hit me.

COBOL had (has?) no concept of interactive I/O through a terminal.

CICS is how you do interactive I/O in IBM COBOL.

It took a lot pages before I got to that place.

[Anonymous Coward]

Re: "these "serverless" gizmos have exactly the same execution model as CICS transactions..."

CICS is a lot more than the user interface, it's a transaction manager. Meaning it lets you do operations across multiple databases, files, and such in an atomic fashion. All based on a request/response model which happens to have regained fashion as various buzzwords, 'serverless' 'microservices' blah blah. You can even hook it up to web services or whatever nowadays, it's not all 3270 green screens

[Anonymous Coward]

Re: Nothing new...

*Technically* the original mainframes also carried proprietary hardware.

[JulieM]

Re: "I see a number of layers added to running an application"

Been there already!

The Linux kernel used to have its own internal httpd server, but that was removed a few versions ago.

Still, the code could be updated and reinstated into the tree -- or even rearchitected for a full-on modular system of kernel-level server plugins with native socket interfaces, so your applications literally see the client end as something like a file.

(Then, somebody will inevitably say This server code could more profitably be moved from the kernel into user space and the whole thing will repeat .....)

[itsbruce]

Re: "I see a number of layers added to running an application"

The web server never made it into the mainstream kernel, for good reason. It was a hack, created in panic when benchmarks showed that Windows NT servers (back then) had higher throughput. It wasn't something to tout as a glorious example of anything. It was and remains a dumb idea (unless you're running a unikernel, which is a whole different story).

[Anonymous Coward]

Re: "I see a number of layers added to running an application"

I've seen this cycle, jumping up and down on the layers to collapse them, in hardware and software several times, in order to simplify things. Then we start building up layers of abstractions to simplify things anew. Rinse, lather, repeat.

[Milton]

Re: I'm wondering on how efficient this all is

Grotesquely inefficient, if your metric is Work Done vs CPU Cycles Utilised, but that's only part of the picture.

Yes, it is kind of horrifying when you look at the staggering amount of resources that folks spin up to achieve simple tasks these days—hey, let's import this 373Mb library code so I can use it for that (one) function for my 21Mb applet—but everyone in the industry knows perfectly well that we are producing unconscionably bloated software to run on ridiculously powerful systems with labyrinthine layers of management and stratospheric levels of abstraction ... BUT, it's *also* true that, often enough, this allows relatively clueless coders to make things work fairly reliably: look at the number of clumsy developers, who don't even understand optimisation (and often don't really understand what they're doing), churning out business applications that still manage to work ok and perform within acceptable time constraints. You're buying their ability to be "useful" by giving them levels, layers, error checks, CPU and RAM beyond the dreams of avarice, and hand-holding to a fare-thee-well.

From a corporate management point of view, if you don't want to pay for lots of really skilled developers, and if you couldn't care less what a weighty millstone of dependency you're hanging round your successors' necks long after you've taken your "cost-saving" bonus and fled, then this massive inefficiency and waste just does not matter. What matters is you can reduce the headcount while increasing the proportion of cheap monkeys therein, and still get barely acceptable results.

The sting in the tail, of course, is that your business ultimately becomes little more than a host, bled more and more by its IT providers as the dependency becomes entrenched and irreversible, and not even constant price hikes, major outages, data loss and theft and consequent damage to your business—much of it, at root, the result of excessive complexity bringing you ever more points of failure and vulnerability— is sufficient motivation to dig you out of the situation you're in. The cost of changing providers, who will have done everything to lock you in while constantly pretending exactly the opposite, is simply too high: you have neither the skills, the knowledge, the experience, nor even the ability to create the architecture to jump ship. We've seen this model so frequently with "simple" outsourcing—whereby a company's systems and data become hostages to your outsourcing company and you cannot sack them no matter how bad they are—that it should be surprising that executives are not *incredibly* careful and sceptical about "cloud" ...

... but, as anyone paying attention during the last 100 years has undoubtedly noticed, greed drives all virtues and common sense right out the window.

[Gordon Pryra]

Living in a buble

"in the history of humanity"

This makes it sound like its actually important. What the guy ACTUALLY meant is

"will take a few days work to sort things out if we move"

[John H Woods]

Re: Living in a buble

first Xmas Freudian typo?

[K]

Re: Living in a buble

Sir +! for you..

I'd give +2 if I could, as I have a Buble-impersonator singing at my wedding soon..

[thegroucho]

Dismiss things at your own peril

Famous last words:

"I think there is a world market for maybe five computers"

Interpret this however way you wish ...

[Doctor Syntax]

It looks as if we're getting about as far as the pendulum swings on this particular cycle. Then a few people realise that the lock-in has made it difficult to get anything done without consulting the resident Kubernetes or whatever wizards or break the hold the beancounters have on the AWS account and it would be a lot easier to sneak in a PC or two...

[My Alter Ego]

Lambda - great on paper

My experience with AWS Lambda was that it looked like it was exactly what I needed. Until I tried using it...

The documentation for the particular function I wanted to use was horrific. There was a single page on the internet that described its used, and much of the information was missing or incorrect. With 18 hours Amazon had to make three changes to the documentation, while I tore my hair out wondering why I was getting unexpected data passed to the function.

Then there's the cold start times - I had a function that took <600ms to run, but if not run for a while would actually take >20s* to run. Seeing as the AWS service calling that function mandated that it would timeout after 5s, I realised that it's pointless to rely up it. Unless of course I decided to dedicate an EC2 instance to the function, but then I'm paying for 750hrs a month (which I'm sure Amazon would love).

I learned that biggest barrier to using Lambda isn't the vendor lock-in (I was aware of it when I started the project), it's Lambda itself.

* 4 s of that was used to deserialize 500 bytes, ffs

[Anonymous Coward]

Re: Lambda - great on paper

> Then there's the cold start times - I had a function that took <600ms to run, but if not run for a while would actually take >20s* to run

Sure: because, under the hood, AWS actually spins up a VM when required. In practice, it has to be idle for an hour or two before the VM spins down again.

If you have any half-decent amount of traffic to your service, this doesn't really matter. And if you don't - but still want to keep the function warm - then you set up a CloudWatch Events trigger to call your lambda repeatedly, say once every 15 minutes.

Basically, lambda is a load balancer + dynamically-started VMs behind it. It saves you the bother of assembling those pieces yourself, and when your usage is low, it saves you the cost of having one permanently-running VM. It also saves you having to apply OS-level updates by hand.

[K]

Re: Lambda - great on paper

Its just another tool in the box..

Personally I use it for automating thing, such as spinning and shutting down of our test boxes. But at least 1 team at my company has built a fully fledged web-app on it...

[JulieM]

Déjà vu

This is exactly what happened in the Bad Old Days of proprietary Java: Before the Java interpretator itself was Open-Sourced, it was entirely possible to create even Hard Open Source code in an utterly proprietary language; Sun and their licencees could render your project useless if, for example, they withdrew support for a feature or a platform upon which you were depending. We had to drop that obscure feature on 32-bit Linux, for performance reasons. It's still there and blisteringly fast under Solaris on SPARC, though; and well-written Linux apps usually build with minimal changes on Solaris, too .....

Of course the release of OpenJDK under a Hard Open Source licence changed that a little (Sun would rightly never choose a Soft Open Source liacence after the Microsoft débacle); but since the Oracle takeover of Sun, there are just enough subtle and incompatible enhancements in the proprietary Java interpretator to keep a little lock-in going down.

It always struck me as slightly ironic how the Raspberry Pi, considered the proof of the pudding about software being truly Open Source, really depends on one enorrmous binary firmware blob to make it act as a general-purpose computer with everything on top of that firmware self-hosting.

This is simply takkng it to the next level, and it's scary for those who would self-host.

I sometimes wonder if any country that ever tried to legislate explicitly against vendor lock-in, might find themselves on the receiving end of a bit of US-style "regime change" ?

[Anonymous Coward]

"really depends on one enorrmous binary firmware"

Probably you don't know what the firmware in Linux is (and why you don't see it in Windows):

https://wiki.ubuntu.com/Kernel/Firmware

Firmware code may, and often is, not open source at all, it's strictly tied to the hardware, and the hardware manufacturer may not want to give away IP or the like. You'll need open-source CPUs, GPUs, etc...

Like it or not, any OS still needs to run atop some kind of hardware (physical or virtual), and has to program and use it as needed. Having the latest firmware loadable on-request is a plus - even CPUs can load code to fix issues.

[patrickstar]

Re: "really depends on one enorrmous binary firmware"

This - i.e. pluggable firmware for various hardware - is not (only) what he's referring to.

The entire GPU firmware on the RPi is closed source, to the point where you can even buy licenses (!) to enable additional features (like the MPEG2 decoder). The hardware is there, it's just disabled until you convince the firmware that you've paid for using it.

And there's no way around using the GPU and thus running closed-source code, because the GPU is what actually initializes and boots the Pi from the SD card (yes, really, the GPU, look it up!). It basically does the job of what would be BIOS/EFI on a PC. And there's no "libreboot" or whatever equivalent for the Pi.

The Pi is far from an open platform despite schematics and such being available. I get it - this was probably the only reasonable option given the price point - but if you're an open source purist you most definitely shouldn't use the Pi.

I doubt the GPU is happy to give up all its firmware, so it's actually worse than running closed source software in general. Atleast in the software case you have the option of reverse engineering it, without having to bring out a scanning electron microscope and focused ion beam workstation.

[JulieM]

Re: "really depends on one enorrmous binary firmware"

Who is "he" ?

What she means is, you often don't even notice the proprietary layer is even there until it's too ltae. If you ever need to replace that proprietary layer, what are you going to replace it with that's Open?

[patrickstar]

Re: "really depends on one enorrmous binary firmware"

Are you assuming genders just because of the username "JulieM"? What if the person identifies as an attack helicopter, with the preferred pronoun "it"?

Anyways - just wanted to point out that binary blobs to get random HW going isn't what people really are complaining about with the Pi. It's the fact that the entire fundamental firmware / "BIOS" is closed source and locked down. You can even get x86 systems that are far more open than the Pi (see libreboot).

You wouldn't see people bitching (as much) if you just needed some blob to get graphics going for example, and could just avoid it if you don't need that - or even better, get basic unaccelerated graphics without it. But as it is now, if you would somehow manage to remove the closed source stuff the Pi wouldn't just fail to boot, it would never even execute a single instruction.

[Old Coot]

Re: Déjà vu

In Soviet USSA, regime changes you.

[David 132]

Hyperbole for Hypervisors

"one of the worst forms of proprietary lock-in we've ever seen in the history of humanity"

Yeah. Lambda and Serverless is the kind of thing that HITLER would have done.

[Not That Andrew]

Re: Hyperbole for Hypervisors

I wasn't aware the Nazi's invaded Poland to ensure vendor lock in