Table of Contents
For developers to be efficient, they need a strong setup, good habits, and tools they know and love to use. With all these ingredients, they’ll feel good about their workflow and focus more intensely on the products they’re building, which will help them more swiftly achieve their goals.
This is why if you want your team or company to work at its best level, you need to optimize developer experience (DX). Building a better digital work space will help teams to be happier and more productive. For a manager, this means cost savings for the business and better employee retention.
Kubernetes has been hugely beneficial for companies looking to manage and deliver microservices more efficiently. Since the container orchestration tool is central to many companies’ architecture, this article will explain five critical elements of creating a strong DX with Kubernetes.
Use Tools for Local Development
The developer work space is the main area where the developer interacts with the product by coding new features, troubleshooting, and fixing bugs. If no specific tools are set in place for their local environment, the developer will ignore Kubernetes, thinking of it only as the end of the line for their application. Then when a problem occurs in another environment, the developer will say, “It works on my machine.”
To reconcile devs with Kubernetes, you need to bring Kubernetes to their development work space. Having a local Kubernetes cluster such as minikube is not enough to create fantastic DX. You need to simplify the operation of their local cluster by automatically building and shipping their application to Kubernetes.
There are multiple tools available for this, many of which have been created in the past two to three years. Here are three promising options:
Enable Self-Service for Everything
Kubernetes is a platform designed to manage a large workload. Its scheduler will try to use the available resources. On top of that, you can add the Cluster Autoscaler, which will adjust the number of nodes based on your resource consumption. This optimizes compute costs based on the number of applications you are running and their consumption of resources. Ideally, you want a single cluster shared across many teams and applications.
The trap would be if you had a single team managing your one Kubernetes cluster, making Kubernetes a faraway platform for the dev teams organized by the ops teams. This would create two silos, ops and dev, with opposite goals: the dev team wants to quickly ship a brand-new feature to production and the ops team wants to keep their colossal cluster under control (in other words, change is their enemy).
The solution to this problem is to enable self-service for your Kubernetes cluster. In this paradigm, the teams operating the cluster are in charge of making sure that each development team is deploying in an isolated namespace. The operating team configures the proper access and makes sure that a development team can only interact with their resources.
Having self-service Kubernetes will reduce the friction of getting an application into Kubernetes since engineers can do it themselves in a controlled and secure environment.
Self-service in Kubernetes doesn’t stop with namespacing; you can enable self-service in Kubernetes using plug-ins. For instance, you could permit engineers to configure DNS by simply annotating Kubernetes resources using ExternalDNS. You also could make remote management a self-service with External Secrets Operator.
Curating Kubernetes plug-ins will also empower development teams because they will have more control over their environment and keep all their configuration as code using a Kubernetes manifest.
Set Soft Limits and Hard Limits
When working with a multitenant cluster, you have to set boundaries to own many of the resources available to your team. Imposing resource quotas on a per-team basis will help you keep your budget on track and contain buggy applications that might otherwise impact the rest of the cluster.
Along with that, you should consider implementing alerts that trigger when a team has consumed 60 percent of its allocated resources. This ensures that the team never reaches any hard limit, and it won’t block engineers from working when the first alert comes in time for them
to reassess the value of the limit or troubleshoot some greedy applications.
Maintain a Product Mindset
You should use a platform-as-a-product strategy with Kubernetes. Through Kubernetes, you are trying to deliver value to your developers by focusing their efforts on microservice development to make them happier and more productive.
How do you achieve this product mindset? The same way you do for application development:
Account for Different Experience Levels
Finally, remember that Kubernetes is a complex system and that not all your team members will have the same level of experience. Don’t automatically expect your developer to be a Kubernetes expert. Instead, establish a cross-team baseline: what is everyone expected to know about Kubernetes? You could create a shortlist of elements like pods, ReplicaSets, deployments, ConfigMaps, and secrets. Then offer training and prepare documentation to make sure everyone is comfortable with this baseline.
All team members should be able to achieve a good DX from the cross-team baseline and shouldn’t need to know additional concepts in order to do their job. More advanced configurations should be delegated to a Kubernetes expert. If you properly manage your self-service in Kubernetes, advanced configurations can be abstracted by a plug-in (external secrets for manager credentials) or by templating (Helm chart). Developers will have only a small configuration to provide, such as defining variables or adding an annotation to a resource, and the magic will happen behind the curtain.
That being said, too much abstraction can also be harmful because novices may not leave their comfort zone. To manage different levels of experience, schedule time to experiment with Kubernetes and offer regular presentations on the platform so that less-experienced team members can catch up.
Conclusion
Kubernetes offers an incredible opportunity for companies to manage large workloads in the cloud. To seize this opportunity and allow developers to work with Kubernetes for extended periods, you need to make sure they’re achieving a good DX.
In order to do this, make sure you’re using the right tools, empowering your teams, eliminating obstacles, maintaining a product mindset, and accounting for different levels of expertise. If you keep these elements in mind, your teams will be happier, more productive, and more efficient when using Kubernetes.
Photo by Jason Goodman on Unsplash
