The Missing Kubernetes Platform for Developers
A Kubernetes platform made for developers is the essential next step for k8s adoption.
Kubernetes is the target environment for more and more software during production, so it will automatically become a topic for developers, too. However, Kubernetes is made for operations and is still challenging to use for people without special knowledge about it. Since developers should rather focus on developing new software instead of learning Kubernetes, a special Kubernetes platform for developers is needed. This platform should enable developers to access Kubernetes whenever they need to and let them seamlessly work with it, so everybody in a dev team can easily work with k8s without learning its details. Exemplarily, this can be achieved by combining loft and DevSpace. Together, both tools allow developers to finally work on what they like to do, developing great new software.
The adoption of the container orchestration technology Kubernetes is continuously growing in enterprises. However, while this transition is often desired from a management perspective, it can be a huge challenge for development teams. In this post, I will explain what kind of Kubernetes development platform is needed and currently often missing to make the move to Kubernetes easier for developers.
Kubernetes is often inevitable
With its increasing popularity, using Kubernetes is on the way to become the new standard for many complex software applications. No matter if it is a managerial decision or technical necessity to use Kubernetes, developers cannot simply neglect container technologies but need to interact with them when these technologies are used to run production workloads. There are two main reasons for this:
1. Developers are responsible for the application.
In a DevOps world, there is no strict distinction between software development and operations. For this, developers cannot just lean back and blame operations if there are problems with an application in production. They rather also have a responsibility for the software along its whole lifecycle. This means that they also need to consider the production environment in their development decisions and if the production environment is Kubernetes, they thus have to interact with Kubernetes for development, too.
2. Some applications cannot be developed without Kubernetes.
Especially with microservices, developers often work on a particular service that is part of a larger set of interacting services. Due to this interdependency, efficient software development is only possible with all services running. However, with larger applications, it is often impossible to run them on local computers anymore as they require a lot of computing resources or other specific configurations. In these situations, cloud development, i.e. developing software directly in a cloud environment, is the only feasible option. (For more information about cloud development, read my article about this topic.)
Result: Developers need access to Kubernetes.
I wrote a separate post about possible ways to give developers access to Kubernetes. You can find it here.
Not every developer should become a Kubernetes expert
Just giving every developer access to Kubernetes, however, does not solve the problem. They also need to be able to actively work with it. Still, not every developer should and often does not want to become a Kubernetes expert. This is for several reasons:
1. Kubernetes is very complex.
Since Kubernetes is designed to be very powerful and at the same time a flexible technology to run production workloads at scale, it is also a very complex technology, which makes it hard to learn. Additionally, it is more an operation technology and thus requires a different skill set than the everyday tasks of a developer. For this, it usually takes a very long time for an average developer to master Kubernetes.
2. Developers have other things to do.
Development capacity is a scarce resource at almost any company. Developing new features, fixing bugs and refactoring software are tasks that usually have a higher priority than learning Kubernetes. Therefore, you usually want development teams to focus on their actual work of creating additional value, especially because learning k8s would take a considerable amount of time.
3. Developers face the same challenges working with k8s.
Since many challenges are the same for every developer when switching to Kubernetes-based development, it would be very inefficient if every developer tries to solve the same problem. Looking at the example of a microservice application, every developer would face the same challenge of getting the necessary services to run at the beginning. It would thus be sufficient if every problem is just solved once and the solutions are then shared in the whole team. For this, it is unnecessary that every developer is a Kubernetes expert.
Result: Developers need to be enabled to work with Kubernetes without becoming experts themselves.
What a Kubernetes platform for developers should achieve
One approach of providing developers with an easy-to-use k8s platform is to abstract away some of Kubernetes’ general complexity. However, there is a general conflict between usability and flexibility. By abstracting away some of its functionality, Kubernetes would also lose some of its power and might not be usable in any scenario. For this, a Kubernetes abstraction for developers might be a good solution for some situations but it would be unable to reach universal applicability. Since there are so many different applications that can run on Kubernetes, this approach is hardly feasible.
What you actually want a Kubernetes dev platform to achieve is to enable developers to directly interact with Kubernetes while they do not necessarily have to configure anything. This can be done by providing smart defaults that can be fully customized and adapted. Optimally, developers can then work with Kubernetes without ever having to configure anything but knowing they could if they needed to. In concrete terms, a k8s platform for developers needs to achieve the following goals:
- Developers can directly access k8s without contacting operations/cluster managers
- Developers can get started fast and do not have to adapt their workflows
- Developers can easily deploy to Kubernetes
How to get such a Kubernetes dev platform
I believe it is possible to already get such an efficient k8s development platform. Since I am a co-founder of DevSpace, a company that provides the components for such a platform, I will explain how we recommend setting it up. What you essentially need are three things: A Kubernetes cluster for your developers, loft and the open-source CLI tool DevSpace.
Goal 1: Developers can directly access k8s without contacting operations/cluster managers
At first, you need to set up a Kubernetes cluster. The easiest way to do this is to use a public cloud provider that offers managed Kubernetes. All major cloud providers, such as Google Cloud, Amazon Web Services, Microsoft Azure or Alibaba Cloud, and an increasing number of small providers offer such a service. Alternatively, you can set up a Kubernetes cluster in a private cloud, which requires a bit more effort but should not be a big challenge if you already have another cluster running for your production system.
After you have a cluster, you need to give your developers access to it. ( Refer to my other post for different methods to give developers access to Kubernetes.) To create a real internal Kubernetes platform for your developers, you need to connect it to loft. This can be simply done installing loft and running the command loft start. Loft then transforms your cluster into a developer platform and thus solves the issue of giving your developers access to k8s because you now can invite users to your cluster via the loft UI and set limits for the individual users, e.g. regarding the allowed computing power. As long as the users stay within these limits, they can create isolated Kubernetes namespaces on demand without having to interact with the cluster manager.
Goal 2: Developers can get started easily and do not have to adapt their workflows
To make the development workflow with Kubernetes seamless, we recommend installing DevSpace, an open-source CLI tool that works independently of loft. Then, you need to define the necessary configurations in the devspace.yaml. This configuration file will be automatically created once you run the command devspace init and gives you a good starting point. However, you usually will have to make some adaptions to fully reflect your desired workflow. Optimally, someone in your team who has some Kubernetes expertise is responsible for this task. In the devspace.yaml, you can determine many different settings, e.g. how the application should be deployed for development, staging, and production, which dependencies exist and which ports should be used.
After this initial setup, the configuration file can be shared with the rest of the team using normal git versioning. For the average developer, it is then possible to just use the optimized configuration file and work as normally not caring about Kubernetes. While the developed software is executed in the Kubernetes cluster, developers can continue to use their local IDEs and debuggers. (For more information about this form of cloud development and why it could be the future, read my other article here.) Developers simply need to run devspace dev which starts the application in Kubernetes and makes it accessible on localhost via port forwarding. DevSpace then automatically syncs the locally written code into the containers and even allows developers to execute commands directly in the containers. All of this ensures that the development in Kubernetes is as similar to local development as possible.
We recently added a local UI for DevSpace to further improve the developer experience and to make it easier to understand what is happening in Kubernetes during development.
Goal 3: Developers can easily deploy to Kubernetes
The command devspace deploy is specifically made to deploy an application to a Kubernetes namespace. Similar to devspace dev, what is happening during devspace deploy can be defined in the devspace.yaml configuration. With this, every developer is able to deploy to Kubernetes with ease. Alternatively, it is also possible to integrate DevSpace in a CI pipeline or to use other tools for deployment. Since the application has been developed in Kubernetes from the start, you reduce the number of new issues during deployment to a minimum.
Conclusion
At KubeCon + CloudNativeCon North America 2018, Janet Kuo, a software engineer at Google, already declared that Kubernetes “is now very, very boring”. What she meant is that Kubernetes just works and is not a major concern for the increasing number of companies running production loads on it. Now, Kubernetes needs to become “boring” for developers, too. That means it should just work and run in the background supporting actual software development. A great developer platform for Kubernetes is the next necessary step in this direction.
Photo by Maximilian Weisbecker on Unsplash
Originally published at https://devspace.cloud.
