The Firecracker virtual machine monitor

Posted Jan 4, 2019 14:25 UTC (Fri) by niner (subscriber, #26151)
In reply to: The Firecracker virtual machine monitor by Cyberax
Parent article: The Firecracker virtual machine monitor

When I read "serverless" I think "peer to peer" or "decentralized".

After reading the article and the comments it seems like "serverless" is meant as "ephemeral". My picture is still very hazy though.

The Firecracker virtual machine monitor

Posted Jan 5, 2019 19:03 UTC (Sat) by k8to (guest, #15413) [Link] (1 responses)

Serverless is a sales pitch. Amazon and others tell you that you won't have to think about servers (or vms) anymore. People like this sales pitch.

The interface offered is that you define some hosted functions that interact with each other and the cloud vendor's system services the execute "somewhere" when they get messages /traffic /invoked. How they actually currently run its packaged as a container/vm that gets started when in use and paused or offlined when not. That's not a hard guarantee. Someone could design a multitenanted serverless platform, but typically getting lightweight benefits from that means designing for a particular language runtime, and that hasn't been popular historically.

In reality you trade off problem sets in such a world. You reduce your initial ops costs and gain some need to finesse the vendor platform to avoid stalls. You lose the need to carefully avoid adding unwanted state, but you also lose access to your familiar debugging tools.

The Firecracker virtual machine monitor

Posted Jan 5, 2019 20:45 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> You lose the need to carefully avoid adding unwanted state, but you also lose access to your familiar debugging tools.
You can run AWS Lambdas locally for debugging. Remote debugging is indeed more complicated, you can't just SSH into the server and see what's going on there. But on the other hand, you need much less of it - as there's much less infrastructure that you manage.

The Firecracker virtual machine monitor

Posted Jan 14, 2019 17:30 UTC (Mon) by dariomolinari (guest, #109072) [Link] (1 responses)

Totally concur: until my laptop/phone/TV doesn't dedicate a portion of its CPU/RAM/Storage to Cloud services I will not accept the term "serverless" as more than a marketing gimmick! ;-)

The Firecracker virtual machine monitor

Posted Jan 14, 2019 19:56 UTC (Mon) by excors (subscriber, #95769) [Link]

There's already stuff like AWS Snowball Edge, which (as far as I can tell) lets you run some AWS cloud services (S3, EC2, Lambda (the 'serverless' thing)) in an actual physical box that Amazon will ship to you, and works even without internet access. I guess you'd count that box as a server (though is it still the cloud?). But presumably there's little technical reason why Amazon's software would have to run on that box, it should equally be able to run in VMs on your laptop and TV and internet-connected toaster oven (assuming they have enough RAM), and then maybe you could really call it serverless, though I still don't know if it would be the cloud or not.

I think the fundamental problem is that the technology is advancing faster than our ability to come up with good terminology for it.

The Firecracker virtual machine monitor

Posted Feb 5, 2019 6:42 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]

Yeah, it's a terrible name "serverless" should mean there is no server, but there very much is. You need to know the capabilities of the environment you're running in, at the very least - Google's implementation: functions, is pretty transparent about the fact that you're just getting an ephemeral VM, with a very basic runtime. Which can be great!

In the end, though, the name is a distraction from the real problems:

1) there's no good way of organizing all your various functions/lambdas. It's too granular. If you poke, around, you'll see people writing about all the wacky ad-hoc conventions they invent to keep a bunch of javascript files with one function each somehow sanely organized & maintainable. It should be a solvable problem, but it's certainly not solved, yet.

2) the environments still haven't found the right balance: this is evidenced by Google's Functions: you have the "super limited" version. The "do whatever you want version". And not much in-between.

3) Re-initializing your whole environment everytime doesn't just kill perf via a slow VM. There's things like caching, that are pretty useful in any prod, latency-sensitive service. Again, look at Google Functions - in some of the examples, by Google, there's a whole lot of ugly code (half, in some cases), that's a bunch of global variables, etc, that are there because you generally *could get lucky, and get the same VM, and those variables will be cached.

However, when you're working with small, event-driven stuff they can be quite nice.

In short, it's an interesting space to watch, with some promise, some neat tech (see this article!), and some solvable problems, waiting to be solved..