We who work in Cloud Native organisations have largely solved the problem of the increased complexity in setting up a Kubernetes platform. But there’s something we have not solved: how to make Kubernetes simple for developers to use.
Don’t get me wrong, I am an active supporter of Kubernetes, and I will never get tired of preaching that Kubernetes is a Greek word that everyone pronounces incorrectly. (I am Greek myself, so I am required to bring this up.)
Yes, Kubernetes solves several problems in handling application workloads and yes, it provides higher levels of automation, which make day-two operations less scary. However, the continuously increasing variety of tools and services available, in combination with the required knowledge of the different Kubernetes concepts and objects makes the adoption of Kubernetes quite a challenging task.
Like Joe Beda, principal engineer at VMware and founder of Heptio, once said, ‘I think that, as engineers, we tend to discount the complexity we build ourselves versus complexity we need to learn’.
So the question is, how do you start?
Let’s say, for example, that you are a developer and you want to deploy your application to Kubernetes. Where do you begin? Which Kubernetes objects should you use? Where do you build your container image? How do you maintain it? How do you deploy your containerised application in a Kubernetes cluster efficiently and securely? How can you create a Continuous Integration/Continuous Delivery pipeline in an external tool that is in harmony with your cluster? How do you configure yourself all those according to best practices?
All the above questions prompted me and a colleague from Container Solutions, Aleksandr Guljajev, to explore ways to make the developer’s experience smoother. We stumbled upon Knative and its build capability as a first experiment. During that process, we discovered that there was an ongoing proposal to deprecate the Knative Build capability with Tekton CD. So, we decided to try both! Eventually we created a demo which we also presented during our monthly Software Circus meetup last August.
Knative, which had its first birthday last July, is a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere. Until recently, it consisted of three components, Build, Serving, and Eventing.
The Build component is about how the application code can be built natively on a Kubernetes cluster via the use of standard templates. It helps package software in a container without having to worry about external dependencies. The Serving component is the one responsible for deploying the container application on the same cluster. And finally, the Eventing component is really focussed on event-driven applications.
Our idea was to explore the Knative Build capabilities, as it promised native image builds in Kubernetes, standard templates, and easy deployments in the cluster. Although the Knative spectrum also includes the other two components, we decided to focus only on the Build component for this experiment.
To test our assumption, we created a demo by leveraging the Google Kubernetes Engine service from Google Cloud, where we installed Knative and Istio. Then, we chose a simple microservice application and evaluated how easy is to execute a build and deploy the application in Knative.
I will not bore you with code snippets; you can find them here, and I do recommend using them to try out the demo yourself. But the main message I would like to pass on is that Knative Build did fulfill its initial promise, which was to provide a native environment to build container images.
However, as far as how functional or modular it can be, several questions remain. Knative Build basically allows you to define a build template and create an instance of it. And basically this is it. There is no granularity or ability to define more steps (for example: unit tests, sanity checks, etc). All in all, it felt that something is missing, although Knative Build does lead you in the right direction.
After exploring Knative Build, it was more clear to us why the proposal to deprecate it in favor of TektonCD existed. TektonCD provides an additional layer of abstraction by introducing the pipeline mentality in Kubernetes. It is an open-source, standalone project that does not require Knative or anything else, except a Kubernetes cluster.
We conducted the same experiment, this time with TektonCD as the main build tool. We were able to create a modular pipeline, which was defined in clear YAML steps with well-defined inputs and outputs.
All in all, TektonCD indeed seemed like a proper way forward to simplify the developer workflow when working with Kubernetes, while also providing a familiar conceptual level by using objects like pipeline and tasks. In this way, developers can create composable pipelines that can use natively built container images while eliminating the need for third-party build services.
On a final note, for this experiment, we still leveraged Knative, but this time only to serve the application in the cluster.
Our experiments were a very interesting and insightful process that led us to believe that Knative and TektonCD can help developers with the adoption of Kubernetes. Knative Build paved the way and TektonCD seems like the ‘new kid on the block’’.
Since this past September, the proposal to deprecate Knative Build was passed and the component is already archived in the official Github Knative repository as well as referenced as deprecated in the official Knative documentation. This development paves the way for TektonCD to be considered as the primary Kubernetes native build tool and, at the same time, allows Knative to focus on the other two components (Serving and Eventing), which differentiate Knative from similar tools.
While the main message of the post is to share lessons learned while working with Knative and TektonCD, I also want to highlight how we treat innovation here at Container Solutions. It is a simple process that involves having an idea, finding people that want to contribute, creating an experiment, and then sharing the results with everyone.
At the end of the day, it is all about culture and how you create a safe environment for your employees. If you want to learn more about what it’s like to work at Container Solutions make sure to check out this blog post from a colleague who joined us recently.
We have our first-ever book coming: "Cloud Native Transformation - Practical Patterns for Innovation". Click below to read now!