|
|
|
|
|
by jririi82zxn
2468 days ago
|
|
Wow everyone all excited about hosted FreeBSD jails Some of us had deploy pipelines into “containers” working like a Lambda in 2003. Nothing in software is all that novel these days, IMO. All these features that have been there for a decade plus are just wrapped in a corporate brand now. Progress. |
|
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.