Developing with Telepresence

The Problem: Local vs. Cluster

Developing microservices in 2021 usually means you are running a single service locally while the other 20 dependencies are sitting in a remote Kubernetes dev-cluster.

The struggle is real: How do you make your local process “feel” like it’s inside the cluster? You could use kubectl port-forward for every single dependency, but that’s a nightmare to maintain. You could use mocks, but then you aren’t testing the real integration.

Enter Telepresence

I’ve been looking into Telepresence 2 (now part of the Ambassador Labs family). Unlike the older version, it’s rewritten in Go and feels much more stable for daily use.

What it essentially does is create a two-way proxy between your local machine and the cluster.

Why Outbound Traffic Matters

The most common use case for me right now is Outbound Traffic. I want my local Go or Java process to be able to resolve service-b.default.svc.cluster.local as if it were running in a pod.

With Telepresence, you can “connect” your laptop to the cluster:

telepresence connect

Once connected, your local DNS is hijacked (in a good way). You can use curl or your IDE’s debugger to call cluster services directly. This is a game changer for inner-loop development. You don’t have to wait for a CI/CD pipeline just to see if your service can talk to the database or a legacy API.

Takeaway

If you are fighting with environment variables and local hosts files just to get your services to talk to each other, give this a try. It’s about making the cluster transparent.

I’ve been following their documentation closely, especially the parts about routing:

Telepresence: How-to Outbound Traffic

It’s still early days for the v2 rewrite, but the developer experience is already significantly better than the old “swap-deployment” approach.