Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Building and Testing Kubernetes Applications Locally Using Telepresence

Building and Testing Kubernetes Applications Locally Using Telepresence

Leia em Português

This item in japanese

Developing software applications or microservices that will ultimately be deployed on a container scheduling platform presents new challenges for engineers, particularly in regards to building and testing services locally that require several dependencies. Kubernetes 1.3 included the release of minikube, a VM-powered single node cluster that could be run locally, and although this approach is very useful, it can consume large amounts of local resources. An alternative approach is presented by the open source Telepresence tool, in which developers work on their service locally but transparently integrate (via a bidirectional proxy) with other dependent services running in a remote cluster.

InfoQ recently sat down with Abhay Saxena from Datawire, creators of the open source Telepresence tool, and discussed how the software development lifecycle has changed when deploying applications into container orchestration platforms like Kubernetes, why Kubernetes has become so popular, and the role of the CNCF within the cloud native tooling space.

InfoQ: Hi Abhay, thanks for joining InfoQ today. Could you briefly introduce yourself and the Telepresence Kubernetes development tool?

Abhay Saxena: I'm Abhay Saxena, a software engineer at Datawire. I maintain the open source Telepresence project. We were building a cloud application on Kubernetes using a microservices architecture, and found the develop/debug cycle on Kubernetes to be slow. Every time we made a code change, we had to go through a container build / deploy process, and this added latency just slowed things down.

So we asked ourselves whether we could eliminate that process completely for development, and came up with Telepresence. With Telepresence, we write and run a service locally, while running everything else in a remote Kubernetes cluster. Telepresence creates a bidirectional proxy between the local service and remote Kubernetes cluster, so your local service has full access to the remote cluster, and vice versa.

The net effect is that I can now make a two line code change, and test it instantly.

InfoQ: What are the typical use cases for Telepresence? Are you seeing any usage that you didn't expect?

Saxena: The most common use case is rapid development. A continuous integration/continuous deployment pipeline is an important tool, but horrible for actual development. No developer wants to have to wait on CI for every change. The second scenario which was a bit surprising at first is running a debugger. We have users who want to use a debugger on their microservice, and with Telepresence, it is as simple as running your debugger on your code.

InfoQ: How does a tool like Telepresence fit into the overall software development lifecycle using Kubernetes?

Saxena: If you think of the basic Kubernetes SDLC as "code, (canary) deploy, monitor", Telepresence is intended purely for the "code" phase. In the code phase, you have to write and test your service, and Telepresence makes you more productive during that phase. As soon as you deploy into production, you'll want to use a CI/CD pipeline. That said, we are working on some things that allow Telepresence to work on some production-related scenarios. Stay tuned!

InfoQ: Why do you think Kubernetes has become so popular, and what do you think the future of Kubernetes holds?

Saxena: I think they started with a solid technology and design, and from there they've done a better job than anyone else in all aspects of a community, from evangelizing to end users to having a good process for getting additional contributions.

In the long-term, I can see how Kubernetes becomes something like a cloud version of POSIX -- a standard for how cloud infrastructure can interoperate. The recent announcement of Kubernetes on DC/OS is an example of what I mean. In the nearer term, the work on declarative application management is something we're keeping a close eye on, as application development is one of the immature parts of the Kubernetes ecosystem (and the area that Datawire is working hard on!).

InfoQ: What are your thoughts on the Cloud Native Computing Foundation (CNCF), and would you ever consider donating a tool like Telepresence to them?

Saxena: We're big fans of the CNCF. They've done a great job of incubating cloud-native technologies. We actually use a number of CNCF technologies in our day-to-day: Kubernetes, of course, but also Envoy, Prometheus, and Docker. Donating Telepresence to the CNCF is something we'd love to do as the project grows. We're seeing firsthand the support that the CNCF is providing to Envoy, and would love for their support for Telepresence.

InfoQ: Is there anything else you would like to share with the InfoQ readers? What is the best way to get involved with the Telepresence project?

Saxena: Telepresence works with both Kubernetes and OpenShift. We're always looking for more feedback and suggestions, so if you think Telepresence might be useful, visit and give it a try!

Other container scheduling platforms offer similar tooling to assist with local development, including Docker for Mac / Windows, Red Hat OpenShift minishift, and Apache Mesos minimesos.

Rate this Article