Table of Contents
Kubernetes is everywhere. You can easily get this feeling if you hear about one of its many impressive adoption figures. Does that mean that Kubernetes has reached its “final stage” and already brings all its benefits to the companies using it?
Kubernetes adoption is only the first step
To answer this question, it makes sense to take a closer look at what adoption actually means. The term “Kubernetes adoption” is pretty vague and can have a wide range of meanings ranging from embracing Kubernetes in the whole organization running all workloads on it to just having one engineer playing around with it in a test environment.
If you take a closer look at adoption statistics, you will find out that adoption is often still very limited. Gartner, for example, found out that less than 30% of companies are using containerized applications in production and less than 5% of enterprise applications run in a container environment. Further proof that Kubernetes usage is still at an early stage can be found in VMWare’s “The State of Kubernetes 2020” survey which states that 57% of companies are operating fewer than 10 Kubernetes clusters.
While these numbers are expected to grow tremendously in the next years, this also means that today, companies that have already “adopted” Kubernetes cannot lean back and enjoy its full benefits yet. Just ticking the next box of fancy technologies by running little, unimportant experiments with Kubernetes does not bring any benefits aside from looking like a modern tech company at first glance.
However, people will quickly see that such a Kubernetes adoption is quite useless if it ends here and developers may even be disappointed. This is especially true as many developers actually like Kubernetes and want to learn more about it, as the latest Stack Overflow survey discovered.
For this, adopting Kubernetes is only the first step towards a meaningful use of Kubernetes.
You need actual Kubernetes diffusion
What you actually need to get the full benefits of Kubernetes and make your developers happy working with it, is true Kubernetes diffusion, which means an organizational-wide roll-out and access to Kubernetes.
Although Kubernetes is still a rather new technology, there is little doubt that it is mature enough for this and the initial adoption step can be seen as evaluation period to answer the question IF to use Kubernetes at all. Given its widespread endorsement by major players and cloud providers, Kubernetes has become a dominant technology and you can be fairly sure that it is a future-proof solution.
So now, as a next step, you can focus on Kubernetes diffusion, which comes with some new requirements and challenges. Particularly, there are two central questions that need to be answered for a widespread Kubernetes use within an organization and to bring your Kubernetes adoption to the next level:
1. How to make Kubernetes available for everyone
The first fundamental question is how to give everyone access to Kubernetes. Solving this question is central because without a Kubernetes access, it is not possible to work with it. That is why this question should be addressed first and with a high priority if you plan a further Kubernetes roll-out for your company.
Solution for first adoption:
If you are in the early adoption and experimentation phase, answering this question is relatively simple. You can either just pay the fees for a managed Kubernetes service in a public cloud, which may be a few hundred dollar per month for the cluster management fee and the computing resources, or you let the engineers set their Kubernetes clusters up themselves. The setup can be done in a public cloud, a private cloud, or even on the local computers of the engineers. Since these adopters are Kubernetes experts (or are supposed to become experts) and often also have admin access to the cloud environment, all of this is not a big challenge during the early adoption stage.
Challenge for diffusion:
It becomes much more complex during the diffusion stage. Now, not only a few Kubernetes experts with admin rights to a cloud environment need Kubernetes, but every engineer in your organization. To make this efficiently possible, you need an automized way of providing Kubernetes even to non-experts, which rules out local Kubernetes solutions (no automatization, individual setup) and also simple managed Kubernetes offerings (average engineers should not have admin access).
Solution for diffusion:
This means that you need to provide an easy to use internal Kubernetes platform to your engineers that allows them to create a work environment on-demand. At the same time, this self-service platform needs to enforce usage limits to prevent excessive cloud computing cost.
That such an internal platform is the way to go can be seen in the fact that some industry leaders and innovative companies, such as Spotify and Datadog (page 25) have already built them for their engineering teams.
However, developing such a platform from scratch can be quite costly and is not so easy, so it may make sense to build upon existing solutions. kiosk, for example, was exactly made for such a use case and can be used as an underlying multi-tenancy extension for an internal Kubernetes platform.
If this is still too much effort, you can also use an out-of-the-box solution that includes all the self-service, user isolation, and user management features. loft is such a solution that turns any regular Kubernetes cluster into a self-service internal Kubernetes platform for your team. All you have to do in this case is install loft into your Kubernetes cluster that is supposed to serve as internal platform. To try it out, you can follow the loft quickstart.
2. How to make Kubernetes useable for everyone
After you have figured out how to give everyone Kubernetes access, you need to enable engineers to efficiently work with it. The solution to this is essential as Kubernetes can be quite complex and not every engineer is (or should become) a Kubernetes expert, but you still want to ensure that you improve development productivity by introducing Kubernetes.
Solution for first adoption:
Again, this challenge is not really a problem for the initial adoption period, when just a few engineers use and explore Kubernetes. They usually either are Kubernetes experts or can become experts by working with it. Learning and trying out things in Kubernetes is actually part of their job and in the exploration phase, time and efficiency are not so critical.
Challenge for diffusion:
The situation for wider adoption, i.e. the diffusion phase, is much different. Here, “average” engineers are supposed to work with Kubernetes. However, their job is not to learn and master Kubernetes perfectly, but to get their regular tasks done as efficiently as possible. The use of Kubernetes should thus be as easy, efficient, and as fast as possible, so it does support and does not interfere with their actual work.
Solution for diffusion:
You need to provide solutions to your engineers that cover their whole workflow. This starts with getting a Kubernetes access in a simple way (see Question 1). Then, the engineers need to be able to develop with Kubernetes. For this, there are already some popular open-source tools that facilitate and standardize development workflows, such as DevSpace (which also has an optional loft integration, so creating a Kubernetes work environment and subsequent development can be done with the same tool), Skaffold, or Tilt.
And finally, the engineers need to be able to easily deploy to Kubernetes, which can either be done with the same tools or with specialized CI/CD tools, such as Jenkins, Circle CI, or Travis CI.
Throughout the whole engineering process, it is important that every step is well documented and that the tools are pre-configured and set up as much as possible, so that the engineers can simply follow standardized guidelines and become productive very fast.
Since it is inevitable that problems occur (some of them are actually desirable because so bugs can be discovered before they enter the production system), it is also important that a constant learning of how to work with these tools and Kubernetes is encouraged and facilitated. (Still, normal engineers should not become k8s experts but should rather know how to handle “standard issues” and understand basic Kubernetes concepts.)
What should you do after you adopted Kubernetes
To sum up, let’s assume you have successfully adopted Kubernetes at small scale and now want to boost diffusion in your organization. Your next steps should be:
Make Kubernetes easily available in a streamlined process via an internal Kubernetes platform. Either build it yourself from scratch like Spotify, build upon existing solutions such as kiosk or directly start with an off-the-shelf solution like loft.
Prepare the rollout in your organization. Choose tools for development and deployment workflows, write internal documentation, and set up/pre-configure the tools as much as possible.
Roll out Kubernetes in your organization step-by-step. Maybe kick it off with a training and onboarding session. It’s best to start with just a few engineers or one team and see how the shift to Kubernetes works for them, so you can improve it for the next one.
- Continuously improve your system, your workflows, and your communication. Listen to feedback from the engineers and keep educating and helping with problems. You should also monitor the diffusion progress and keep an eye on cloud computing cost.
Conclusion
Kubernetes has now reached the masses of companies but not of people. While initial adoption in form of experimentation is a good first step, it cannot be the final destination to get the real benefits of Kubernetes. The adoption rather needs to continue, so Kubernetes also reaches the majority of engineers. To get to this step without losing productivity, you need to make Kubernetes readily available and easily useable to the engineers by providing them an internal, self-service Kubernetes platform and a variety of tools for their workflows.
Photo by Lindsay Henwood on Unsplash
