Kubernetes Native Application Development Made Simple

What is an application, after all?

application (noun): a program or piece of software designed to fulfil a particular purpose. [citation]

Traditional, legacy applications have been built in a very coupled manner, such that everything is dependent and tied to everything else, and there was very little, to no separation of concerns. Debugging was hard, pulling the hand would make the feet go up. It would not scale. Such applications are generally referred to as “monoliths”, and we want to move away from them in our Cloud Native world. But this is the age of Cloud Native Everything, isn’t it? This begs the question …

What is an application in this new age, the age of Cloud Native Computing? We hear the term microservices or microservices architecture a lot in this world. To quote Martin Fowler here:

“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

In the CNC world, one generally writes self-contained services. Each of these services does one thing (solves a business problem) and does it well. Sounds familiar? Indeed, this is an old Unix philosophy and design principle. These services can be independently deployed, scaled or torn down. They come together to form a modern day application.

You might be building a simple voting application that has a front end. The front end makes calls to an API service that fetches data from a Postgres DB. Or maybe you are building the next Uber or Flickr which has many different applications each comprising of multiple microservices. And it is definitely possible that many applications are using the same services independent of each other. For example, a location service, an authorization/login service, a rating service.

The above example is probably too simplistic but it conveys the message, “an application in the CNC world is what you want your application to be”. You stitch together services to build your application, and in all likelihood you containerize each service and run them. This is the new normal.

Speaking of normal, Kubernetes is the gold standard to run your containerized applications. It is designed to scale, be fault tolerant and it’s one of the most actively developed projects in this space.

Deploying microservices on Kubernetes requires a developer to write Kubernetes manifests. Manifests are a way to declaratively define your microservice. Kubernetes tooling takes care of the rest.

Here’s an example of a manifest that can deploy NGINX on Kubernetes:

The example above is a Kubernetes Deployment manifest which has a Pod defined with one container running an NGINX server exposing port 80.

And this is a Kubernetes Service manifest exposing the Deployment to port 80 as type NodePort, which means that this will expose our NGINX server on port 80 on all the worker nodes in the Kubernetes cluster.

This isn’t very complicated but it requires the developer to learn Kubernetes concepts and then fight with multiple YAML files. And this is a very simple example. Take the case of an Uber-like example. You would definitely require a lot many manifests and much more complicated than the NGINX example above. Writing and maintaining thousands of YAML is a painful task. This has got many in the Kubernetes community thinking and there have been many attempts to solve this problem each with their unique positives and negatives.

A Solution

Kedge is a proposed solution to this problem. Kedge provides a simple, concise and declarative way to define your services that can be stitched together to build your application on Kubernetes. In short, Kedge lets you define, build and deploy your application the way you want.

Kedge is made for Kubernetes and it builds on top of the Pod concept, the fundamental unit of Kubernetes. Here’s the Kedge equivalent of the above NGINX deployment manifest:

See how concise it is. And all you have to do kedge create -f nginx-kedge.yaml and NGINX will be deployed on a Kubernetes cluster.

How does it work? Kedge takes this snippet, converts it to relevant Kubernetes manifests and deploys them to the running Kubernetes cluster. Of course, this is a very simple example but this is just scratching the surface of what Kedge can do now and we have just got started.

We identified certain patterns that a lot of users would use in their Kubernetes artifacts and added shortcuts for the same to make the end user experience better, like in the following snippets -

Just by specifying the endpoint field along with a ServicePort definition, Kedge will generate an Ingress resource.

By specifying the health field once, both livenessProbe and readinessProbe get generated.

The same Kedge file can be easily extended using includeResources field, using which you can specify the path to a Kubernetes resource definition (e.g. CronJob, CRDs) file and Kedge will deploy that to your cluster.

We already have tested it with some services and here are some full blown examples that you can review and play with.

You can define your microservices in the simple and concise Kedge format, and let the Kedge CLI tool take over from there. It is very simple to learn and use. Read more about it here.

Developer experience is one of the most important tenets of Kedge. We are building Kedge so that it becomes simple for both developers and operators to write, deploy and maintain their services and applications simply and easily. We envision to make sure Kedge can be integrated with CI/CD pipelines, work across multiple environments, be compatible across a set of old and new versions of Kubernetes.

We are just getting started with Kedge. We will regularly demo our progress in various community forums. Here is recording of one of our recent demos at Kubernetes sig-apps:

Here is another Kedge demo by my teammate Suraj Deshmukh:

Have a look at our issues and milestones to understand where Kedge is going and feel free to open issues. And you can find us here.