Challenges Debugging Microservices
Debugging microservices can be challenging. I am in the process of moving DeployHub Pro to microservices for our SaaS offering and I ran into an interesting dilemma. Microservices are great for having small contained pieces of functionality for scalability and reuse. However, the problem is in having an easy-to-use debug environment in Eclipse.
The Reverse Proxy Problem
Running microservices locally on my single machine requires that each one runs in its own Tomcat instance. And, each Tomcat instance can’t run on the same port so you have a unique port per microservice. Problem solved? Not exactly. My UI needs to access the RESTFul APIs on a single Server Name/Port combo (well-known name). Every microservice is on a separate port so reverse proxy is needed like NGINX or HAProxy. Reverse Proxy solves the mapping problem of the well-known name but the debugging is still tricky. 20 microservices = 20 tomcat instances running inside of Eclipse. Possible but not optimal. Bring Docker containers into the picture and even more complicated, ie. remote debugging needed.
The solution is to keep all of the microservices as one big application like we use to. The main difference from a Tomcat perspective is the web.xml. I am just going to have my one big web.xml that is used with one instance of Tomcat. Back to the good old days of running and debugging. That problem is solved.
Running Microservices Outside of Eclipse
As part of my build process, I split out the microservices into smaller web.xml files and split out associated source code at that point. We use our build product OpenMake Meister to do the split which involves defining XML files (Target Definition Files) that define the relationship between source, the split out web.xml, and the target microservice war file. Running the build gives me all of microservices broken out for their Tomcat deploys and I still have my big single war for a standalone install. Best of both worlds.
DeployHub Key Features