> deploying code without visibility of the underlying server it runs on Well I take issue with this, I think Kubeless and Riff are definitely serverless, even

> deploying code without visibility of the underlying server it runs on Well I take issue with this, I think Kubeless and Riff are definitely serverless, even though I need a Kubernetes cluster provisioned (and it obviously has servers in it). I can get visibility into those servers, or I can run them in a managed way where there will be no visibility. Both ways are serverless, I think this because they are FaaS solutions and because of the way the runtime environment is dynamically provisioned. I don't have to know or care what server it's on. I'm not sure that's what makes it "serverless" but there is definitely room for questions between "serverless" and "Serverless" with a capital S. And in at least one of those (Riff) it's actually cold/pods all go offline at rest, so not warm processes running on any server until it is called (scale to zero.) You just have an API gateway that is always online, and it starts the workers in response to events. It's hopefully lightweight compared to your app / suite of microservices / the kubeless version of what I'm describing, where each function has a memory footprint that doesn't evaporate when it's not in use. Regardless of whether you're using FaaS or not, the pricing model for servers as scale grows seems to be quite favorable compared to same size "all-lambda" solutions, and based on the feedback in this thread and prior ones, I think there's a compelling benefit to price predictability if you take the time to estimate how big your computers need to be and, say, order enough reserved instances to cover something like the capacity you will need for the year. You can always scale past that to grow when needed, but reserved instances are cheaper than ordinary instances, and ordinary instances are cheaper than an equivalent amount of CPU time on Lambda. I get how this kind of negates the benefits, but not really. It depends entirely on the pricing model and how much you use. If you can fit in the free tier, it's much less compelling. But you can start with a really small cluster if you can scale your worker deployments' pods all the way to zero without causing a downtime event. (But if you're now groaning because I've got you managing a cluster of nodes again, then your priorities might be different than mine too...)