8

When performance testing in the microservices world (talking mainly load testing), what is your approach regarding external dependencies (APIs) your application relies on, but not owned/controlled by your team. In my case the external dependencies are owned by teams within the same company.So would you point to the corresponding "real" integration non-prod endpoints OR you would create stubs and mimic their response times in order to match production as much as possible?

  • First approach example: A back-end api owned by your team and calling an external api to verify a customer. Your team doesn't have control over the customer api, but you still point to their integration testing endpoint when running the load test.
  • Second approach example: A back-end api owned by your team calls a stub that sends a static response and mimics the response time of the external customer api.

I realise there are pros and cons of the two approaches, and one would favour over the other depending on the goals of the testing. But what is your preferred one? Shouldn't be necessarily a choice between the two mentioned above. Can be a completely different one.

martbon
  • 81
  • 3
  • 2
    I'd be terrified to use stubs in this case. Mainly because that is how a billion-dollar computer manufacturer with millions of orders per day worked 18 months with over 100 developers on converting their structure to Microservices, to find out that when they went to production, nothing happened. In their development environments, they stubbed every external call and by doing so they never realized that 150ms response time on 200 microservices meant 0.00% availability. Moral of [the story](https://www.youtube.com/watch?v=gfh-VCTwMw8) - don't stub because you can. Stub because you must. – Dennis VW Dec 15 '19 at 06:29
  • 2
    Thanks! Good point regarding the confidence in your tests and the information they provide. In my situation, the system with its dependencies is already established with its known weaknesses. But still, there is always some waiting to be found... – martbon Dec 16 '19 at 21:11

1 Answers1

7

It is important to identify the system (or application) under test. If you are measuring the performance of only your own microservice, then you can consider stubbing as an option.

However, performance test is typically done to assess the performance of the system as a whole. The intent is usually to emulate the latency in actual usage. The only way to model this somewhat accurately is to not stub and use the "real" integration end points. This approach has additional advantages as it can help you to identify potential system performance bottlenecks such as chained synchronous calls between your microservices (Service A calls B and B calls C and C calls D and etc). The tests can also be reused for Load testing.

In short, you would need to do both to ensure:

  1. A microservice is performing within the SLA
  2. The various microservices are performing within the SLA as a whole.
Seth
  • 431
  • 1
  • 5
  • 9
  • 3
    Thanks for you input Seth, my reputation is still not enough to publicly upvote your comment, but it should be recorded. Quite like the idea of enabling coverage on both sides. The only problem for me in my case is that the integration endpoints owned by external teams are sometimes not even close to the production ones. So the information they give you might be misleading. – martbon Dec 16 '19 at 21:20