Kubernetes is great. With Kubernetes, the imperative notion of installing software becomes a thing of the past, while the declarative notion of describing how software is to be installed becomes the way it is done. A declarative definition allows us, developers, to specify just how we want our software installed, and to have it under source control, so that we can install it once and again, exactly the same way.

To allow us to do so, Kubernetes defines a declarative language -- a language of API Objects. Today, these API objects are either written by hands, typically in YAML format, or rendered using Go templates that come as part of a Helm chart.

While the language provided by Kubernetes exposes its entire API, providing developers access to all its wealth, this language does not provide one important thing -- abstraction.

In programming languages, abstraction mechanisms allow developers define new concepts, and then use them (and reuse them) in different contexts. Functions, for example, provide a powerful abstraction mechanism in which some computation is given a name, allowing it to be reused in different contexts, with different parameters.

Kubernetes allows us to define objects such as Pods, Deployments and ConfigMaps. These are the building blocks provided by Kubernetes. But it doesn't give you a mechanism to create your own blocks. This is Lambda-Kube comes into the picture.

Lambda-Kube is a Clojure library. It contains functions, most of which are purely-functional (have no side-effects). These functions allow developers to build objects in the Kubernetes object language. These objects can then be handed to Kubernetes, to turn them into a running system.

Clojure is very good in making functions, and especially pure functions, compose. Unlike the Kubernetes object language, in which object definitions are often big, allowing many options, Lambda-Kube functions are designed to be simple, but are designed to compose well, following the Unix Philosophy.

Lambda-Kube provides a collection of functions that represent the major Kubernetes objects and some patterns regarding them, but users are encouraged to extend this library with their own functions, adding functionality Lambda-Kube does not address.

No, because Helm is considered a "package manager for Kubernetes", while Lambda-Kube is a library for building Kubernetes objects. However, by generating Kubernetes objects, Lambda-Kube provides an alternative to Helm's use of Go templates. Here is why we believe this alternative is better.

Additionally, it allows users to write reusable Clojure libraries that describe the deployment of services. As such, they can play the role charts play in Helm. Clojure already has a few good package managers (e.g., Leiningen and Boot), which can install such libraries on demand. This makes them (and not Lambda-Kube itself), Helm-replacements.

Be Comprehensive. If you find functionality that is missing, feel free to write it yourself. If you feel it can be useful to others, please open a PR.

Validate it Outputs. Kubernetes will always be better than anyone in validating its input. We do not attempt to replicate its logic. Lambda-Kube will allow you to build invalid objects, and it's up to you to make sure you get it right. Fortunately, it does make it easy to test things as you write them, by using lein auto run.