Smarter Local Development of Kubernetes Microservices with Telepresence

A microservice architecture lets you structure an application as a collection of small, loosely coupled services.

Their size and independance enable development teams to produce code that is focused on doing one job, and do it right.

That makes designing, improving and maintaining software more predictable, as the company scales its infrastructure and its human resources.

Microservices done right give you extra modularity and better control on your execution as a team, as a company.

Microservices… Macroproblems?

An architecture that separates concerns across multiple services makes validating a change exponentially more difficult.

Either they imply replicating the architecture on the developer’s machine, or they require you to build and deploy each and every change in your Continous Integration pipeline.

Neither seem like entirely viable options.

Should I install Kubernetes locally then?

We’d venture to say that it’s a pretty common onboarding step for newscomers in nowadays software development teams.

Depending on your organization maturity, especially regarding documenting practices like employee onboarding, this installation process could somehow feel like chaining git clone commands of small monolithic projects.

Obviously, while developing, you’d have to constantly ensure that repositories are in the right state (branching), that services are able to properly communicate with each other (resolution) and that you have relevant data to play with (fixtures).

In such case, it would probably make sense to leverage the capabilities of Kubernetes in terms of services orchestration and resolution.

Minikube is a tool that makes it easy to run Kubernetes locally.

Supercharge your local development lifecycle with Telepresence

Telepresence enables you to transparently access other microservices in an OpenShift and Kubernetes cluster (including a Minikube one).

By effortlessly proxying network connections across your microservice architecture, it empowers your local workspace with all the benefits that a normal Kubernetes microservices pod would have access to.

No need to run an entire architecture anymore

Here, we are using our own Stacktical staging Kubernetes cluster for demonstration purposes.

First, let’s install Telepresence

brew cask install osxfuse
brew install datawire/blackbird/telepresence

We’re installing Telepresence on Mac OS Sierra.

You can find instructions for your own operating system at

Then let’s list Kubernetes services

kubectl get service frontend backend db

Pay attention to port information.

Our objective is to be able to communicate to backend on the 8888 port from our local frontend.

We don’t want to install or manage our API locally, and we want to use our existing staging Stacktical project data without relying on fixtures.

Telepresence will help us with just that.

Swapping the remote frontend service with our local one

telepresence --swap-deployment frontend --expose 8080:80 --run-shell

Note how we reuse the port information from earlier.

Whenever we call the remote backend service, it’ll answer back to our local frontend application.

This two-way proxying system is at the foundation of the very ability of Telepresence to letting you replace any microservice in your architecture with its local counterpart.

Now let’s actually try talking with backend from localhost

The remote Swagger definition appears.

I can now magically display the remote backend Swagger definition from my local machine.

This could be a useful way to access an always up to date API documentation of your project, as a frontend developer.

Getting fancy with realtime integration of dependencies

But you’re part of a team: your code still needs to be merged and interact with the code of your peers at some point.

So we’ve been wondering: What happens if two developers use Telepresence at the same time, on the same Kubernetes cluster?

Let’s verify just that with a simple Request versus Response scenario.


Developer A

As expected, Telepresence proxies the signup request to Kubernetes. The email address already exists in the staging database and Developer A is alerted accordingly.


The signup response sent to Developer A has actually been provided by the backend of Developer B !

Developer B

Developer A and B can communicate across Kubernetes using Telepresence.

One can probably imagine how handling dependencies between frontend and backend development like that could increase the team’s overall velocity for the ongoing sprint.


But tools like Telepresence makes it easy to contribute to existing, Kubernetes-powered projects and re-imagine how we collaborate around shipping code faster than ever before.

It’s not just a matter of shipping scalable services. It’s a matter of improving the scalability of your team as well.

For more information about Telepresence, go to

This article was originally posted on But will it scale? the official blog of Stacktical, the Scalability Testing Automation Platform powered by Predictive Technologies.

Hi, we're the team behind Stacktical and the DSLA downtime compensation token.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store