Unless you’re really really good at FinOps, requests won’t be billed. But if you run Knative in your own cluster, what you’re paying for is the cluster instance.
#Serverless naming camelcase code#
A managed Knative, like Code Engine, has billing, and it’s per request. Well, the first problem is that it’s a bit of a mouthful (BPRRPI, anyone?), and the second problem is that it’s not even accurate. What about ‘cloud funtainer’? You get a Thermos with a picture of a cloud on it.Īnd this is why Knative describes itself as ‘serverless’.Īnother way of describing serverless, which involves less head-warping ‘there are no servers visible to the developer, but there are servers underneath, and actually the developer sees and defines those servers’, is this: “Billing per request rather than per instance”.īut there’s still a problem, even with that name. Apparently ‘funtainer’ is Thermos’s fun-container (as in, actual fun, or as much actual fun as you can have with an insulated drink container). You’ll get a lot of cheerful-looking Thermoses, and nothing about the cloud architectures. Funtainer isn’t ‘a container which is lots of fun’, it’s a mash-up of ‘function’ and ‘container’. At the time, it was OpenWhisk, Spotinst, and OpenFaaS. This was pre-Knative, and waaay before last year’s Amazon Lambda container-support news. One name which got floated for this model was ‘funtainer’. In the stack, but in the model where containers are the units of deployment, the user controls them. In this layer diagram, grey parts of the stack are controlled by the provider, and blue parts are controlled by the developer. Function as a service makes no sense, because it’s not a function. Serverless-but-with-a-server doesn’t roll off the tongue.
Serverless is a ridiculous name for something which has a server, if the user is the one managing the server. That’s a server! And I decide what it looks like and how it runs, so I own it. I’m doing on Code Engine, a managed Knative: For example, I’ve just written this in a Dockerfile for a demo The problem? What do we name our new way of doing things? Every container file explicitly declares and manages a server. Then Knative appeared on the scene, and it could only run containers. Containers were so great for this use case, some FaaS frameworks retrofitted the ability to run code in containers as well as loose functions. Why insist on trying to make functions, when we have containers? They’re light, portable, totally encapsulated, and ubiquitous.
Managing free-standing functions just starts to feel like a lot of work. Most FaaS frameworks have some packaging syntax for expressing dependencies and other metadata, but there’s usually a limit on how big those dependencies can be, and if you want to switch framework, you may need to rewrite all your metadata. If your code has dependencies, that also gets awkward. But to run the function on your machine, you either need to run the whole framework, or you need to roll your own lightweight harness to stand your little functions up and drive them. On the cloud, the user experience is frictionless. They’re always going to be tied to some execution framework, like Amazon Lambda or OpenWhisk. But these free-floating functions aren’t so great for running locally. There’s still a server, of course, but the cloud provider takes care of defining it and provisioning it. For some use cases, running a function is fine. I don’t have evidence, but I assume that everyone just got tired of people piping up with “but actually serverless does have servers, you know” every time anyone said “serverless”.īut there was a problem.
For a while, we stopped calling it ‘serverless’ and started calling it ‘functions as a service’, or FaaS. Let’s talk about the naming challenges around serverless. Some things are easier to mis-name than others. Naming things is hard, and bad names make developers unhappy. There are only two hard things in Computer Science: cache invalidation and naming things.
0 kommentar(er)
