Is Kubernetes Still Just an Ops Topic?

The idea for the container orchestrator Kubernetes is clearly stemming from infrastructure and operations challenges. How can I provide software at massive scale? How can I make it run in many datacenters around the world? How can I ensure that it is always running? These were the issues that Kubernetes was made to resolve.

Its auto-scaling features allowed the infrastructure managers to build a system that adapts to the computing needs of the software. The standardization of containers and Kubernetes made it possible to create portable systems that could be run in any cloud environment, public and private and in every data center worldwide. Finally, capabilities such as the self-healing nature of Kubernetes together auto-scaling further ensured a very high reliability of the systems.

Since all of these things are operations issues, Kubernetes has been mostly an ops topic in its early days and developers were hardly in touch with it. Nowadays, this is still often the case and the people with a deep Kubernetes expertise usually work as infrastructure engineer, system administrator, DevOps engineer or at least have a similar background. Additionally, many tools in the k8s ecosystem are about managing and maintaining production systems.

So, the question for many developers is if Kubernetes is something they should care about and work with or if it is still “just an ops topic”.

#Should developers care about Kubernetes?

When Kubernetes is introduced in a company with an existing product, applications or at least some parts of them have to be migrated to Kubernetes first. This is often not a task for the “average” developer but something that only a small team is focused on or that even operations engineers are taking care of. At this stage, Kubernetes is still not a developer topic.

However, after the initial migration or if new applications or services are developed, Kubernetes comes into play also for the developers. With Kubernetes being quite mainstream nowadays, many companies are in such a situation now and developers need to be enabled to work with Kubernetes. This is especially true for complex systems such as microservice-based applications that are too large to run on limited local environments or for machine learning and artificial intelligence software that has enormous computing requirements. In these cases, the application will run on Kubernetes in production and thus mandates to also use Kubernetes during development because otherwise the developers are not even able to test it properly.

From a developer’s perspective in an organizational setting, there can be several reasons why they have to or should use Kubernetes:

• The first reason is that there was a decision to use Kubernetes for the whole development team, even if the individual developer would not necessarily need it.
• A second reason is the previously described technical necessity to use it as it would otherwise be impossible or too much effort to get the application to run.
• Another valid reason for a developer to start to work with Kubernetes is that this is the most efficient way of developing a good and stable system. For example, software that was developed with Kubernetes from the beginning does not have to be adapted to run in a production Kubernetes environment anymore, which ensures that there will be less unexpected problems after deployment.
• Finally, the use of Kubernetes can have some desired side-effects on the whole engineering teams. Since the developers are enabled to properly run tests and deploy their developments more independently, there can be more responsibility and “system-thinking” for the whole application instead of a narrow focus on the subparts an individual developer is working on.

Of course, several of these reasons are usually relevant at the same time for a developer to start working with Kubernetes. If one expects the current trends to continue in this area, one can thus conclude:

Kubernetes is not only an ops topic anymore, but more and more developers are caring about it, too.

#How to make Kubernetes an (attractive) dev topic

Some developers might be hesitant when they start to use Kubernetes for the first time. Fortunately, it is now easier to use than ever before. This is due to several reasons:

• Local Kubernetes Clusters: It is now possible to run Kubernetes on local machines with tools such as Kubernetes in Docker (kind), minikube or MicroK8s. This allows developers to run their first experiments completely isolated from others and with low risk and low cost.
• Shared Remote Clusters: For more advanced development and complex applications, developers can use shared Kubernetes clusters in the cloud. Solutions such as loft or DevSpace Cloud make it possible to create namespaces on demand with a single command while these solutions care for the multi-tenancy aspects of the cluster and allow for a centralized management by an ops colleague.
• Standardized Processes with Dev Tools: No matter if local clusters or remote clusters are used, there are tools such as DevSpace, Skaffold and Tilt that help to make the developer’s life with Kubernetes easier. It is possible to standardize and centrally configure all Kubernetes workflows such as updating or deploying an application, so developers can work with Kubernetes without having to drastically change their workflows.
• Large Community: The fact that Kubernetes has emerged as the dominating container orchestrator with a wide-spread adoption has the advantage that also the community is very large. Thanks to this community, there is also a lot of documentation, tutorials and even open source software for many niche requirements, which can help with more complicated issues.

#Conclusion

Kubernetes and its ecosystem have shown an incredible progress recently. It is now a mature and ubiquitous technology whose appeal is going beyond operation tasks. Therefore, developers often cannot and also should not try to get around it but should be open for the innovation it can bring. There certainly are some advantages for their development processes, too.

The goal should therefore rather be to make Kubernetes as easy and seamless to use as possible, so that Kubernetes can soon become what it is supposed to be for developers: A standard commodity in the background that just works and makes its users’ life easier.

In the very recent past, there has been some development with exactly this goal: Open-source tools for the development workflows have emerged (DevSpace, Skaffold, Tilt), some companies are developing internal platform solutions to make Kubernetes easily usable for their specific needs (Spotify and Box talked about their platform at KubeCon North America 2019) and there are general solutions that transform any Kubernetes cluster into a development platform (loft, DevSpace Cloud).

Photo by Christina @ wocintechchat.com on Unsplash