Deploying Apps With KEDA-HTTP
Tags: kubernetes, webdev, cloud, cloudnative
Published: 2020-11-24 01:22:57

When you search for ["what is Kubernetes?"](https://duckduckgo.com/?q=what+is+kubernetes&t=brave&ia=web), 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, `Pod`s/`Deployment`s/`Service`s/etc..., or `kubectl` _[0]_. They also shouldn't need to deal with [Helm](https://helm.sh) 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"](https://www.youtube.com/watch?v=rFejpH_tAHM). 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](https://github.com/osscda/kedahttp), 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 `Deployment`s, `Service`s and `Ingress`es and Ingress Controllers for running pods ("compute") and routing HTTP traffic to them
- [KEDA](https://keda.sh) for scaling `Deployment`s up and down
- The [operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) and [Custom Resource Definitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 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](https://github.com/osscda/kedahttp) and there is a [proposal](https://github.com/kedacore/keda/issues/538) 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](https://github.com/kedacore/keda/issues/538) 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](https://www.digitalocean.com/products/app-platform/), [App Engine](https://cloud.google.com/appengine/), [Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/), [Heroku](https://heroku.com) and [App Service](https://azure.microsoft.com/en-us/services/app-service/)

[3] Personally, I'm excited about the fact that the project is partially being implemented in [Rust](https://rust-lang.org). 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