Use your favorite IDE, debugger, or other Kubernetes tools

Use your favorite IDE, debugger, or other tools that run locally with Kubernetes

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.

Telepresence + Your Local Tools for Kubernetes

Telepresence, focuses on improving the developer workflow for single Kubernetes developers. With Telepresence, developers can develop as if their laptop is running remotely in their Kubernetes cluster. This way they can keep their existing local development, build and debugging workflows. They're then free to use the local tools (debuggers, IDEs, etc.) that maximize their productivity.

This demo shows a Java microservice running in Kubernetes. Thanks to the power of Telepresence, the developer uses VSCode to make changes to the service they've intercepted to their own laptop. They can see the changes immediately!

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 on Twitter.

Learn More

• Check out Telepresence
• Learn more about fast, efficient development of Kubernetes microservices ​