Deploying Apps With KEDA-HTTP

When you search for "what is Kubernetes?", content abounds with technical details of the system. There's less about what Kubernetes is at a high level. Here's my attempt at that in two sentences:

Kubernetes is an operating system for your cluster of computers. Like any OS, you get a syscall API for CPU, memory, networking, storage and more, and build abstractions from there.

If you're new to Kubernetes, let those two sentences sink in before you move on. And if you're an app developer trying to deploy to Kubernetes, remember the things you're not implementing: an HTTP server/router, a database driver, a JSON parser, and so on. You're using abstractions. Kubernetes should be no different.

App Developers on the Web

I'm using the term "app developer" in a very imprecise way; that's on purpose. I'm not out to define what this group developers does or is, I'm out to assert the tasks they shouldn't have to do while building their app. Developers should not have to understand details of virtual machines, the Kubelet, Pods/Deployments/Services/etc..., or kubectl [0]. They also shouldn't need to deal with Helm charts or watch Kubernetes dashboards after a deploy [1].

In other words, they shouldn't have to know a distributed syscall API to accomplish everyday deployment and management tasks. Kubernetes is a robust platform on which to run web applications, not an adequate experience for web developers to deploy them.

A Better Experience

In 2015, Rob Pike gave a talk at dotGo entitled "Simplicity is Complicated". Referring to the Go language, he explained that while Go is simple for developers, the code that provides that simplicity is very complex. Indeed, the Go standard library provides a very simple and flexible API to access underlying system resources.

Kubernetes is the underlying system. The task we have now is (a) defining what a simple and flexible interface needs to look like, and (b) implementing it.

Many cloud providers have relevant products we can draw inspiration from [2]. While these platforms are diverse, most or all of them share roughly the following features.

• You focus on running your code, not underlying resources like VMs, containers, VNets and so forth
• Your app can automatically scale up and down based on demand
• A CLI is available to deploy your code to production with a command
• Your app can built in the cloud, instead of your computer
• It's easy to connect your code to other databases and other cloud services
• You can opt in to advanced features like gradual rollouts and more

Kubernetes has the foundational technologies to build these features and more. Our challenge is to choose the right ones, manage the complexity, and expose a simple and flexible abstraction purpose-built for Kubernetes.

KEDA-HTTP

That brings us to KEDA-HTTP, a new project I'm starting. I'm building KEDA-HTTP to bring Kubernetes closer to app developers plain and simple. Knowing approximately what a good platform looks like, the technical details matter.

Under the Hood

This project primarily assembles existing building blocks to build the right developer experience [3]:

• Standard Kubernetes Deployments, Services and Ingresses and Ingress Controllers for running pods ("compute") and routing HTTP traffic to them
• KEDA for scaling Deployments up and down
• The operator pattern and Custom Resource Definitions (CRDs) for defining a comprehensive abstraction and API over KEDA and the standard Kubernetes resources

The Future

Kubernetes has democratized distributed systems. Any developer can access lots of distributed primitives over a standard API, but doing so requires understanding large concepts and keeping lots of context in one's head. That requirement alone is a barrier to entry for a lot of people. Further, a large subset of applications don't need some of these primitives [4].

I believe that we know what a simple and flexible interface needs to look like. As I see this system evolve, I'm optimistic that this next level of abstraction will greatly increase the number of developers who can use the technology. Work is ongoing at github.com/osscda/kedahttp and there is a proposal open for adding this technology to the KEDA project.

A small team of my Cloud Advocate peers at Microsoft, the great people in the KEDA project and me are working on this project. We're not quite ready for help, but watch the proposal issue for progress. We'll be slowly modularizing the codebase and contributing functionality piece by piece into KEDA.

[0] As is the case with every abstraction, developers should somewhat understand inner workings.

[1] In many cases, developers also function in SRE or DevOps roles as well. In those situations, they almost certainly would need to use these dashboards to assess the health of their code in production. There is a clear separation of roles or "personas" implied here - the developer writes application code and deploys it to production, while the SRE/DevOps engineer operates it in production.

[2] In no order, with no preference and non-exhaustively, these include App Platform, App Engine, Elastic Beanstalk, Heroku and App Service

[3] Personally, I'm excited about the fact that the project is partially being implemented in Rust. While the language has a reputation for being hard to learn, I believe that the language provides several features that make it well suited for writing Kubernetes components

[4] Such as leader election and distributed leases