logo

In this blog post i will tell you the story of developers everyday problems when working with microservices and how a tool can save you a lot of time.

How do you set up a development environment for microservices and Kubernetes ? While tools and infrastructure for building traditional web applications has been optimized over time, the same cannot be said for microservices.

In particular, setting up this development environment can be more complex than a traditional web application.

Your service likely relies on resources like a database or others microservices that either you or your coworkers maintain. For example, your service might rely on an authentication service. These external dependencies add complexity to creating such development environment. So How do you run your service so you can code and test it when your service depends on other resources or services?

Let’s setup an environment :

setup

Option 1 : All system locally

Using tools like minikube or Docker Compose to spin up services locally. For resources like databases you can use Docker images.

  • Pros:
    • fast and all is local development
  • Cons:
    • You need to spin up the whole system locally, which will become difficult once you have a large enough number of services and resources.

Option 2 : Copy of the production system

You run a testing environment cluster in the cloud. It might not have as much configurations as the production system, since load will be much lower, but it is quite close. Your code also runs in this cluster.

  • Pros:
    • Very similar to production
  • Cons:
    • Development is slower since you need to push code to cloud after every change in order to try it.
    • Using tools like debuggers is difficult since the code runs remotely.
    • Pay for additional cloud resources and spinning up new clusters.

Option 3 : Port forwarding

You already have all services and database running on the kubernetes cluster. You can just connect to the remote services using port forwarding provided by kubernetes.

  • Pros:
    • Fast, local development
    • Simple local setup
  • Cons:
    • Configuring a proxy or VPN that works with your cluster can be complex.
    • Reconfigure your application to use localhost instead of kubernetes service name.
    • Easy to forget or misconfigure your application and port forwardings.

Then you find Telepresence :

Telepresence, in conjunction with a containerized development environment, gives the developer a fast development workflow in developing a multi-container application on Kubernetes. Telepresence lets you run your application locally, while proxying it to your remote Kubernetes cluster.

This lets developer working with microservice to develop fast local application event if they depend in remote services . Make change , save and immediately see change in your service. Use any local tool to test or debug even in your IDE.

So to simplify, your local development will be a part of your remote kubernetes cluster.

Installtion :

It is very easy , you can find details here. I am using ubuntu :

Trying Telepresence :

Telepresence proxies traffic from your local machine to remote kubernetes cluster. You can access kubernetes services directly your laptop behaves like a part of the cluster. Let’s try it out:

start

As you can see i call my remote service from my laptop like it is a part of the cluster dns.

Debugging local application :

One of the most used use cases is debugging your application running in remote kubernetes cluster.

For this example i have this small architecture in my GKE cluster to show how debugging is working :

arch

Telepresence can fake the remote deployment with it’s own , making all services on kubernetes talk to your local process when this target service is called from others services: telepresence --swap-deployment --expose 8080 server

swap

It will scale the original “server” (which represent micro 2 in my architecture) deployment to 0 replicas and create new replicas with the same labels, so the service will forward the traffic to your local running application.

I will call my microservice 1 (client) who will call microservice 2 (server) to show you the debugging in my IDE :

call

intellij

There are also other tutorials in Telepresence documentation how to debug java application or how to use Telepresence with IntelliJ.

Summary :

Telepresence can proxy traffic from your machine to your remote Kubernetes cluster and vice-versa. It’s a great tool which can speed up developing and debugging microservices running on remote Kubernetes cluster. It allows us to run applications locally as if they are a part of the cluster. Moreover, there is no need to use external tools like docker-compose and of course you don’t need to buy a new laptop! 😄

This blog it’s not a complete telepresence tutorial. It has an excellent documentation with many tutorials and use cases, it’s worth to read it and play a bit with it. I’m sure you’ll love it.