Ambassador Logo

Kubernetes Doesn’t Have to Mean Throwing Away Your Local Dev Toolkit

Adopting Kubernetes may come with tradeoffs, but using your favorite local tools doesn’t have to be sacrificed.

Moving to Kubernetes can mean a lot of changes and challenges for development teams, but it shouldn’t mean your developers can’t use their favorite tools. Changing tools can make it harder for developers to be productive. Challenges they would be able to solve easily with the tools they were comfortable with for their monolith may not be accessible in a Kubernetes environment. This means it can take longer to solve problems or they may not be able to solve them at all.

If organizations adopt Kubernetes to move faster, how can they cope with these changes that slow their individual developers down?

Debugging Kubernetes Services

There are an abundance of tools that have been created for debugging traditional web applications. These tools make it easier for developers to identify bugs and test solutions in an environment that looks similar to the production environment.

Since configuring local development environments is more challenging when using Kubernetes, using local tools is also less straightforward. Consider the following:

  • A backend developer identifies a problem/issue/bug with one of their services, but they can't recreate it outside of the target environment (production, QA etc) and they need to use IDE-based debugging tools to diagnose and fix the issue
  • A backend developer wants to install a local debugging/diagnosis tool within their Kubernetes cluster, but the ops/platform/SRE/InfoSec team won't let them due to potential security risks
  • A backend developer wants to SSH/kubectl exec/port-forward from their local machine to a remote cluster in order to debug an issue using a locally installed tool, but the ops team have disabled this option to remotely connect with the cluster

For a monolithic application, developers at most organizations would know what steps to take to address these challenges because the tooling has been created and optimized for those environments. With Kubernetes however, the processes are not well-defined and developers tend to waste more time searching for solutions. This, of course, means less time shipping new features.

Solutions to Enable Use of Your Local Tools with Kubernetes

Enable Developers to Add their Development Machine as a Full Node into the Remote Kubernetes Cluster

A potentially simple solution for developers looking to integrate local and remote resources is to add their development machine as a node in the cluster. Depending on the underlying networking configuration, this can be a quick way to easily develop a service locally with access to remote cluster dependencies.

The simplicity of this solution is greatly dependent on the remote cluster configuration. Many cloud vendors or mature on-premise infrastructure operators will view the ability to extend a cluster to a local machine as increasing the threat model inappropriately.

Adopt New Technologies

Improving developer experience has been an often-discussed topic in the cloud native space. There are several popular tools that have gained traction for reducing friction in a developer’s code, test, deploy loop:

  • Skaffold is a workflow tool that helps developers automatically build, push, and deploy their application to a Kubernetes environment.
  • Telepresence is an OSS tool that enables developers to “intercept” their cloud service and run it locally on their laptop to code in a more traditional local development environment.
  • Tilt gives you smart rebuilds, continuous feedback, live updates, snapshots, and more for local development in Kubernetes.
  • Garden is an automation platform for cloud native applications that enables developers to use the same workflows and production-like Kubernetes environments at every step of the process.

If this is a problem you’ve faced while adopting cloud native technologies, we’d love to hear about your story and how you’ve addressed it. Please drop us a line at @ambassadorlabs on Twitter or join our Slack channel to share your story.