Published on: Jan 02, 2023

Telepresence Microservices Debugging  

The microservices architecture is confirmed by one or more systems which is a distributed system. A business use case or business flow is built using a collection of microservices; one of the difficulties with this design is debugging one or more of these subsystems. 

In a conventional single-deployment design, the developer’s local computer may be configured with all of the required monolithic system components, allowing for code debugging. However, setting up a number of these systems for debugging on a local desktop is not cost-effective in a vast microservices landscape since they need a lot of memory and processing capacity, which is sometimes unavailable to developers. 

There is a fix for this issue when using Kubernetes. It is suggested by Telepresence and entails utilizing a proxy setup to reroute traffic from a group of microservices from the development environment to the local workstation. The proxy is set up as a sidecar and acts as a mediator. Thus, the execution takes place on the server, but a few components are active locally, and traffic is diverted as necessary. 

Ambassador, a network traffic controller for Kubernetes, offers a solid networking basis upon which telepresence has been developed.  Development teams now have a different option for setting up local desktops and development environments to debug massive dispersed microservices networks. 

The fact that the Telepresence free license version only permits one single developer per proxy at a time was a hurdle for our team when we tested this. Upgrading to the licensed version would be necessary if many developers needed to work on the same microservice simultaneously. Adding a distinct id for each concurrent developer to the traffic header and allocating the bandwidth appropriately allows many concurrent developers from a single Telepresence proxy setup. 

Otherwise, a solution that involves setting up one Telepresence proxy per namespace may also make this feasible. However, a unique microservices instance with its own namespace must be given to each developer.