Hacker News Reader

Comment by evankanderson | Hacker News Reader

This is a way to deploy and manage a stateless web application ("function") without needing to get into a bunch of low-level details, and get closer to pay-for-what-you-use.

View on HN

Sorry, I'm still pretty new to Kubernetes. I am exploring using Serverless Framework + AWS Lambda/GCP Functions to build out a full CRUD-like REST API backend. If I used Knative, would I achieve a similar functionality? Would each "function" (i.e. endpoint) be deployed in a separate container? If it's all in one single (autoscaling) container you still don't acheive full pay-for-what-you-use, right?

Each distinct container/app/function scales independently.

Billing models do in fact affect our design discussions and we're still kicking the questions around[0][1].

[0] https://github.com/knative/serving/issues/895

[1] https://github.com/knative/serving/issues/848

Very interesting! thanks!

> get closer to pay-for-what-you-use.

How though, won't you need a Kubernetes cluster running?

The exact economics depend on where the billing boundary falls. For on-prem the economics will probably follow one of central IT budget, showback or chargeback and I expect the case for hugging the curve as tightly as possible is weaker.

For cloud providers the boundary is likely to become execution-seconds. As Kubernetes worker nodes become abstracted away this will be the remaining way to track utilisation.

On the small scale, no, it's not pay-for-what-you-use. Imagine though you're an enterprise, running a large K8S cluster with lots of workloads inside. By using Knative and scale-to-zero, now you can pack more lightweight workloads into the same cluster resources, because the pods scale down when they're not actively being used. It gives you (as the cluster operator in your company) the ability to run your cluster the same way serverless works in the cloud.

Reply on news.ycombinator.com