Table of Contents
Kubernetes clusters simplify the deployment and maintenance of containerized workloads in the cloud. Organizations are finding that Kubernetes blurs the line between development and operations. For instance, engineers that don't have access to traditional servers still find they need cluster permissions to test changes, run their tooling, and debug running workloads.
In this article, you'll look at five reasons why developers and engineers should be able to use Kubernetes clusters. These factors have been chosen because they directly benefit individual developers as well as the overall productivity of their team and organization.
Granting developers access to clusters enhances their effectiveness and creates a more positive work environment, and it starts with empowering engineers to make changes without running through costly exchanges with ops teams. This leads to a better work ethic, happier people, and teams that are fully tooled up to quickly do their best work.
1. Productivity
The number one reason you should give developers cluster privileges is productivity. Operations and security teams will be concerned about developer access, but most requests are made on a good faith basis. Instead of siloing off individual disciplines, it's important to recognize that the best solutions often come from people on other teams.
Engineers that can't interact with a cluster when they need to can be held back and forced to reconsider their approach to a problem. If a longer route needs to be chosen, timelines and costs are impacted accordingly.
Providing developers with the access they need leaves them free to develop optimal solutions without hitting roadblocks along the way. It recognizes the nature of code authorship as permeating through the entire lifecycle instead of being a siloed stage that's kept apart from the infrastructure. This leads to more effective solutions that come at a lower cost.
Increased productivity also impacts individual developers. Engineers will know when they're being held back. Continuing to use tools that are perceived to be inadequate will sow frustration that eventually leads to unhappiness. This ultimately affects the organization's engineer turnover rates.
2. Responsibility
Developers who have access to Kubernetes gain more responsibility and can make holistic improvements to the software, workflow, and deployment infrastructure. Eliminating silos between dev and ops creates a level working environment where developers are trusted to make broad changes that optimize the application.
With this responsibility comes the opportunity to understand how code progresses from development, through staging, and into production. Particularly in larger organizations, a developer's involvement with a change often ends once the code's been reviewed and merged. The "deploy" stage is usually an opaque process that engineers are separated from.
This restrictive model leads to inefficiencies and missed opportunities for improvement. Developers that are responsible for the entire process gain insights into how CI pipelines, staging environments, and production infrastructure function. In turn, these insights can inform code changes that add additional resiliency to the project.
3. Autonomy
Many developers are independent by nature; they have favored tools, working practices, and approaches to problems. Opening up Kubernetes cluster access provides a higher degree of autonomy where engineers are free to try out new solutions without having to go through the platform team. This leads to a greater sense of achievement and satisfaction that helps to retain engineers.
Having control over tooling gives developers more options to build optimal solutions. Infrastructure has a cost, but so does developer time. Creating new cloud resources is usually relatively quick and easy, whereas writing code to fit a specific environment can be time-consuming with dead ends and a suboptimal outcome.
Allowing developers to operate more autonomously lets you select from the broadest range of approaches. The developers' word doesn't need to be final; collaboration with other teams and consequent trade-offs will always be necessary. However, giving developers a chance to solve solutions using their preferred tools can reduce friction and accelerate implementation times.
4. Velocity
Developer velocity is another important metric of success. Engineers operating at a higher velocity will generally be more productive; they may also have extra motivation and be better equipped to handle new tasks, as they're seeing regular progress each day. Velocity is lost when developers encounter challenges due to hidden complexity in the problem they're solving, an ineffective implementation plan, or weaknesses in the tools available to them.
Another critical contributor is a developers' ability to rapidly test and iterate on work-in-progress solutions. Testing often takes much longer than code authorship, so it makes sense to remove as many stumbling points as possible. Among these, discrepancies between test and production environments can be one of the biggest time sinks. Giving developers access to Kubernetes clusters addresses this by providing a deployment environment with much greater parity to production.
Eliminating obstacles lets developers carry more momentum through their process. This makes it quicker and easier to experiment, iterate, and adapt code to its surroundings. Developers will move more quickly and feel more fulfilled in their role when they're not having to work around missing tools or address inconsistencies between environments.
5. Developer Experience (DX)
Kubernetes access completes the developer experience and simplifies everyday tasks. Trying to rigidly allocate tools to Dev, Sec, and Ops teams often creates artificial distinctions between disciplines. In reality, everyone needs holistic interactions with the entire software lifecycle, and developers are no exception.
Granting access provides an enhanced engineering experience where developers can live stream logs, readily debug production environments, and run experiments with confidence that their solutions will be applicable to the final infrastructure. From the perspective of a product manager or team leader, this should be seen as unlocking the full potential of your developers to analyze problems and devise solutions.
An engineer's role shouldn't end when the code is merged. There's no hard boundary between development and operations; developers will need to step in to investigate production issues by reviewing stack traces, collecting environmental information, and running reproduction cases.
Having access to the Kubernetes cluster that's running the app equips engineers to perform these tasks and effectively solve the problem. It's much more efficient than having to ask a platform lead to apply changes, monitor their effects, and assess whether the problem's been resolved. This reduces time to remediation, mitigates the impact to customers, and lowers the associated costs.
Developer Happiness: The Driving Force
Behind all these points lies a simple realization: optimizing for productivity, responsibility, autonomy, velocity, and developer experience results in happier developers who feel valued and empowered. The individual well-being of developers can be obscured and overshadowed by the gritty technical details of an organization's tools and methodologies. It's a vital consideration because happier people are more likely to continue to work effectively and bring new ideas to the table.
Kubernetes can deliver these five key traits of a positive development experience. It streamlines and unifies the entire code delivery process, from initial testing by individual developers right through to production deployment. This holistic view keeps developers involved, simplifies their tasks, and results in increased job satisfaction.
By contrast, developers that can't quickly provision development environments or debug production issues can become frustrated and disillusioned. Having to run every access request by the platform team is inefficient; moreover, it creates a culture of distrust and siloed disciplines.
Conclusion
Kubernetes clusters are often viewed warily; a compromise or misapplied config file has the potential to bring down your infrastructure, so they must be adequately protected from mistakes and bad actors. However, locking out developers can be too restrictive. As you've seen, you could be missing opportunities, wasting time, and frustrating your engineers by refusing to offer cluster access.
Don't underestimate the importance of keeping developers satisfied and motivated. Direct access to production-like dev environments, the prospect of more autonomy, and a workflow that maximizes velocity will promote happiness and make engineers feel valued. It all culminates in a self-sustaining feedback loop where the productivity enhancements unlock more options down the line.
There are other benefits to developer access as well. Developers gravitate towards tools with the ability to reduce friction and streamline workflows. They're also keen to learn and utilize modern technologies that are defining the ecosystem, a characteristic that's certainly true of Kubernetes. Using Kubernetes, and allowing developers to use it, can make an organization more attractive to top engineers and create a better chance of long-term talent retention.
However, opening up access doesn't need to mean everyone becomes an admin. There are strategies that can help you maintain control and prevent mishaps while granting developers the capabilities they need. For instance, you can use a tool like Loft to give developers self-service access to virtual clusters that run atop your existing environment, adding the multi-tenancy support that standard Kubernetes is missing. Another approach might be to provide a locked-down namespace for each developer by using Kubernetes RBAC rules to enforce access control. Whichever route you take, developers will thank you, and you could see lasting benefits to team productivity and agility.
