The use case:

I am working on a microservice based architecture and I am wondering how I am supposed to debug a microservice (with my IDE attached to it) on my local machine where I develop it.

The problem:

Until today I just had a few microservices (~4-7) for a whole web platform and in order to debug a single platform I would just start all my non dockerized microservices and set breakpoints in the to be debugged microservice.

However my platform became more complex. Now I have dockerized all my microservices, I have centralized logging with an ELK stack which gets logs via Filebeat (a tool written by Elastic, which basically transports the Docker output to Logstash), Prometheus + Grafana, zipkin (performance monitoring), transport via RabbitMQ etc. As you can see I have to run quite a couple docker containers to debug my whole platform.

My question:

How do you handle the development of new microservices which you would like to debug with an attached IDE when they are dependent on other services?

  • What precisely is the problem? Debugging a program that is running within a container? Or setting up all the required containers locally? – amon Jul 14 '18 at 12:45
  • The problem is that a new microservice is dependent on other containers (for example because they queue messages in a queue which are the input for the new service). – kentor Jul 14 '18 at 12:53
  • 2
    As the platform grows there may be tens of microservices and maybe 5 further containers for infrastructure stuff like Grafana, Prometheus, Elasticsearch, Logstash, Zipkin, Filebeat and so on. I expected some better approach than starting 30 containers or so to debug a single application? – kentor Jul 14 '18 at 13:02
  • 3
    A microservice is developed and released independently of other microservices. Integration testing between the microservice under development and any microservices that it depends upon should be done in a QA environment, which can exist on your local machine or separate servers. You may run the microservice in development from your IDE. Just configure the instance to work with the QA environment instances. – Joshua Jones Jul 14 '18 at 17:07
  • 1
    Also, if each one is that tightly coupled with every other one you’re probably missing the point of a MSA. – Paul Jul 14 '18 at 21:39

This is what I do for complex setups like you describe.

Whenever you write a micro-service, write a Client for that micro-service to the same interface. Integration Test the client against the service and record the traffic.

Now write a mocked Client, which instead of calling the service to get the response, loads files filled with the traffic you previously recorded.

Now your next micro-service with a dependency on the first, can use the mocked client instead of the real dependency in its tests.

The use of the recorded data allows you to quickly generate new responses from the real service to fit your test case. Or even to use logged responses where you have identified a bug in production.

You can now write new tests cases and debug your service in the IDE without having to setup all the dependent services.

  • But how do you know you’re mocking out the right responses from the micro service ? What if it changes its responses but you forget you used it in this service ? Your mocked version will still work but in reality it won’t work anymore. – Steve Chamaillard Sep 2 '18 at 19:27
  • because its part of the dependency project, so it will be updated with it and because you can quickly update it to match the real service output as required – Ewan Sep 2 '18 at 20:17

If your microservices are designed properly, each service fulfills a business capability, which is described by a collection of user stories and acceptance criteria. These user stories and acceptance criteria will have to be tested at service level. Therefore, create tests that cover all services stories and mock the rest. This should be enough to develop and debug a single service.

If you think this approach is not valid, maybe because every service needs many other services to do meaningful things, then you should consider if your services are too small or split incorrectly. You might have to apply this approach but instead of running a single service, run 2 or 3, but never the whole system or many services. That would most likely mean a bad design in my opinion.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.