I think FaaSes have value, but I am still on the fence about their changing "everything".
To start with ...
> When it comes to services such as AWS Lambda, when you expose an endpoint, you don’t necessarily have to worry about massive surges in traffic.
You sorta still do. The latency of a cold start is still higher than a warmed-up chunk of code. Can Node start, interpret code, perform logic and respond in less than 100ms? It certainly can.
Meanwhile, a warmed up JVM can perform the same logic in nanoseconds.
Lambda and most other designs I've seen retain warm copies. Either loaded in advance (I saw an AWS slide deck saying that a large part of their secret sauce is load prediction) or kept around once it has launched.
But you will always have a bimodal distribution, probably quite wide, because FaaSes typically scale down to zero.
Hugging the curve is never free. Either you accept idle capacity (enough to cover a start of a surge while you bring additional capacity online) or you accept lumpy latency.
I suspect FaaSes will shine in situations which are sensitive to billing cost but not latency. Where latency is non-negotiable, you will either see folks sticking to services or some mix of services that are augmented by functions built from the same codebase.
> These Serverless cloud providers constantly monitor and manage the underlying fleet of servers running your code.
PaaSes do this too. It's one of the main selling points.
> Thankfully, every endpoint you set up can use a different language runtime.
This isn't really true. FaaSes currently provide a closed list of supported languages. Implementations vary, even within a single platform.
What's missing here is an open extension point. I have internally argued, and I will be continuing to argue, that we already have one: buildpacks. The concept is well-understood, the tooling and testing is well in hand and we have a great deal of expertise in this area.
In particular, it means we don't need to reinvent a wheel. Identifying that code is meant to be mounted in a FaaSes is no different in kind from detecting that it is intended to be run as a Rails app or a vanilla Rack app.
What's missing from the discussion is what is missing from FaaSes: tools for composing larger systems. Most efforts (eg. IBM's composer[1] tool or Lambda's step functions) look at creating state machines wrapped around functions. I think this is the wrong approach. Composition should be declarative, mediated through state, with no logic outside of the functions. My model here is how Concourse defines tasks. I've been making this argument too and I hope we'll bring to FaaS users the kind of lego-brick composability that Concourse users enjoy.
[0] https://pivotal.io/platform/pivotal-function-service, based on https://projectriff.io/