Naive Workflow vs. Unikube Workflow

Local Kubernetes Development with Unikube

Do you want to know how the development process with Unikube consolidates all necessary tools for an easy local development of Kubernetes (K8s) applications? Read on!

Flow_Water_1200x500px.jpg

In previous blog posts, we looked at the migration process and the development process in a Cloud Native environment. We have seen that a developer needs to have a basic understanding of a number of different tools such as Helm, kubectl and Telepresence for a local development workflow. Now we want to take a quick look at the development process with Unikube, which aims to consolidate all necessary tools for convenient and seamless local development of Kubernetes (K8s) applications.

Naive workflow

A previous blog post took a deep dive into how local Kubernetes development can be achieved. In this section, we just want to take a quick look at the various steps and tools. To be able to develop an application for Kubernetes, a developer faces at least three of the following challenges, if not more:

  • Source code with Dockerfile for Docker image
  • Helm charts or Kubernetes manifest files, e. g. provided by a Kubernetes specialist
  • Local Kubernetes cluster, e. g. k3d/k3s local development setup
  • Knowledge and skills of the whole technology stack, as well as different tools to maintain a local cluster
  • A tool such as Telepresence for hot code reloading without re-deploying
  • A tool for debugging, such as the Python- or Java debugger

The illustration below shows a complete naive workflow of the development process. We can see that there are quite some steps to get the local Kubernetes development cluster up and running before the developer can begin with the actual source code development. Additionally and depending on the application, there is a varying degree of direct collaboration and documentation between the software developer and the Kubernetes specialist. During and after the development, there is the need for special tooling to bring the source code into the local cluster.

Image: Naive Workflow - Infographic

Image 1: Example of a naive workflow

Unikube workflow

Now we want to take a look at the local development workflow when using Unikube. Of course, a developer is also faced with certain requirements, namely:

  • Source code with Dockerfile for Docker image
  • Helm charts or Kubernetes manifest files, e. g. provided by a Kubernetes specialist
  • Unikube platform and CLI
  • A tool for debugging, such as the Python- or Java debugger

We can see that half of the points of the naive workflow are consolidated into the Unikube platform and CLI. With Unikube, a developer only needs to have knowledge and skills about one single platform/tool and that is Unikube. The need for direct cluster creation, configuration and interaction with different tools is gone!

Again we want to take a look at an illustration of the Unikube workflow. Compared with the naive workflow we can see that the software developer can skip some steps and begin writing code more easily, as the Kubernetes specialist has created a project and settings in the Unikube platform. Collaboration and documentation between the software developer and the Kubernetes specialist all take place via the Unikube platform as well.

Now the software developer can create a local Kubernetes cluster and select the project to work on with the Unikube CLI. No further special tooling is needed during or after the development and no direct interaction with the K8s cluster is necessary when using the Unikube CLI.

The only reservation is a tool for debugging, such as the Python- or Java debugger. Since the debugging tool is very specialized and dependent on the chosen programming language and interpreter, Unikube currently doesn’t support remote debugging. You can check out the roadmap for Unikube and of course, you can always get in touch to propose new features, for example via GitHub.


Image: Unikube Workflow

Image 2: The Unikube workflow

Direct comparison: Naive workflow & Unikube workflow

While this blog post doesn’t aim to give a deep dive into Unikube and all the commands of the CLI, we want to make a direct comparison of the various steps during the development of the naive workflow and the Unikube workflow.

Image: Workflow Comparison

Conclusion

Although the table only lists the Unikube CLI commands and doesn’t go into any details, we can clearly see that besides a remote debugger all necessary steps are directly supported by Unikube. This is an enormous advantage for the software developer, as only one tool - Unikube - has to be learned.