3

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?

Improve this question
8
  • 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, 2018 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, 2018 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, 2018 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, 2018 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, 2018 at 21:39

2 Answers 2

Reset to default
2

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.

Improve this answer
2
  • 1
    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, 2018 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, 2018 at 20:17
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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