Serverless: slower and more expensive

The “feature” behind Lambdas aren’t the way they work; it’s the way they force you to work, exposing an ABI that forces “Lambda-compatible code” into a shape where it isn’t attempting to call into OS features of the local machine for things like state storage or IPC, but rather making calls to network-visible service endpoints to accomplish those tasks.

In other words, the Lambda environment, as a development target, is the exact opposite point on the spectrum from an OS like Mosix: rather than trying to make a big cluster of specialized compute resources appear as a standardized local POSIX environment, Lambda instead does away with the POSIX environment entirely and forces your code to interface with the big cluster of specialized compute resource “where it lives.” You can’t just write to disk, because there is no disk. You can’t just talk to other processes on the same machine, because there is no (multiprocessing) machine. In fact, you can’t even cache state in process memory indefinitely, because your process isn’t indefinite like it is in POSIX. Etc.

This is a big benefit for ops folks, insofar as code that’s written as “Lambda code” (but generically, using libraries like Fog) can be easily run in many more modern infrastructure environments (including on-prem ones!) than regular code can, “at scale”, without modification to the code itself. As well, these restrictions (like the one on not caching state in memory) force devs to confront what turn out to be the realities of fault-tolerance, which means far less of an ops headache later on, trying to baby along workloads that rely on never dying.

I would describe Lambda as doing a very similar thing for the server, as what Google’s Native Client (PPAPI) attempted to do for the browser: to create a new, strict ABI for developers to target, that forces code written against that ABI to build its features differently (i.e. more portably, more securely, etc.)

Or, philosophically, “serverless” is just a further extension of Heroku’s “twelve-factor”: it’s an approach that hobbles developers’ available toolkit, for the sake of making the workloads they produce better-behaved and more predictable at runtime.

> > > my dependencies might be different

> > No, the lockfile does that.

> your lockfile doesn't care about build steps

Then you're not talking about dependency versioning are you? you're talking about install order. In practice it hasn't been an issue, I should find out how deterministic install order is but I'd only be doing this to win a silly argument rather than anything that has come up in nearly a decade of making serverless apps.

> For example filesystem change events are known to have filesystem and OS dependent behaviours

> When a Node module runs a shell command, it's possible that you have a BSD vs a GNU flavour of a tool

Are you generally proposing it would be common to use an entirely different OS? Or a non-boring extX filesystem?

All your issues seem to come from edge cases. Like if you decide to run FreeB or ReiserFS locally and run a sandbox it it, fine, but know that's going to differ from a Linux / systemd / GNU / extX environment.

> > VMs, docker and having to care about and manage isolation platforms is the reason people started using serverless.

> Maybe, but serverless doesn't answer those questions at all.

Serverless exists precisely to answer the question. I can throw all my MicroVMs in the ocean with no knowledge of dockerfiles, no VM snapshots, no knowledge of cloudinit, no environment knowledge other than 'node 10 on Linux' and get my entire environment back immediately.

Serverless makes a lot of sense if you are paying the system administrator. Most of the cost for running servers I've seen is the support of those servers. Whether it's paying DevOps or a SysAdmin team. However I found it was much too slow to meet SLAs. It takes time to provision lambdas on demand. Then again we did our POC back when Lambda first came online. I think now you can pre-provision tasks which makes things a lot faster.

Lambda meets the requirement of being very low maintenance, reactive, and scalable. I'm not surprised they are charging a premium for it. You don't have to pay multiple $100k sys-admins to keep it running.

> And so for data processing/streaming/batch [...] serverless actually does work out pretty well.

This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the query side unless your queries are trivial enough to be piped straight through to the underlying store. And if your workload is trivial, you should just use clickhouse or straight up postgres because it vastly outperforms serverless stacks in cost and performance[1]

For non-trivial pipelines, tools like spark and dask dominate. And it just so happens that both have plugins to provision their own resources through kubernetes instead of messing around with serverless/paas noise.

And PasS products, well.

https://weekly-geekly.github.io/articles/433346/index.html

>One table instead of 90

>Service requests are executed in milliseconds

>The cost has decreased by half

>Easy removal of duplicate events

Please explain.

[1] https://blog.cloudflare.com/http-analytics-for-6m-requests-p...

IaaS is the peak value proposition of cloud vendors. Serverless/PaaS are grossly overpriced products aimed at non-technical audiences and are mostly snake oil. Change my mind.

The most interesting thing about serverless for me isn't 'web scale' its 'scale to zero'. My apps tend to be bursty, with trickles of data in between. I mostly concerned in reducing their 'idle' costs, so not having to manage the OS, security etc is a massive cost saving for us.