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..