5 ms·

My company is in the process of building out an integration test suite for our microservices platform. A few pain points: 1. The tests themselves are housed in

My company is in the process of building out an integration test suite for our microservices platform. A few pain points: 1. The tests themselves are housed in a separate repository, so you can't update the tests alongside your service. This means every change to a service has to be backwards compatible. Hello, multi-step rollouts. 2. Our environments must be highly configurable, so that every permutation of versioned services can be integration-tested. This is forcing us to adopt an unnecessarily complex container orchestrator. 3. Service owners are not excited about setting up and contributing to yet another project. We end up with a lot of out-of-date integration tests. Lots of noise, if you ask me. I think a combination of contract testing (e.g. using Swagger, Pact) with monitoring, canary deployments, and automatic rollbacks would be easier to maintain and just as effective at catching bugs.

bpicolo 9y ago
Once you dive into SoA, you see how much sense single-source-repository starts to make. Developing features between <n> different repositories is tedious, and the single-repo gives ample benefits. Having easy-to-work with interface layers like protobuf in a shared repo makes tons of sense, for example. It's interesting to see how things like Golang may well have evolved out of this problem. Calculating a golang app's dependencies is as trivial as a grep or two, so it's easy to know what tests to run when libraries change.
- shcallaway 9y ago
  At the very least, this experience has made me question the conventional wisdom that microservices = good and monolith = bad.
  - cle 9y ago
    That's conventional wisdom? Outside of loud naive bloggers preaching that microservices solve the world's problems, most engineers I've chatted to IRL have been pretty skeptical of the overall utility of microservice architectures because of the high complexity they add.
  - pbreit 9y ago
    Conventional wisdom has always been and remains the opposite.
msangi 9y ago
Wouldn't you need backwards compatibility anyway to avoid the need of upgrading all the services at the same time?
- cpitman 9y ago
  I usually advocate for storing (and therefore versioning) tests with the code under test, but this one complaint may have changed my mind. Backwards compatibility is incredibly important for microservice architectures. The more tests are black box, the more this would work.

bpicolo 9y ago

Once you dive into SoA, you see how much sense single-source-repository starts to make. Developing features between <n> different repositories is tedious, and the single-repo gives ample benefits. Having easy-to-work with interface layers like protobuf in a shared repo makes tons of sense, for example. It's interesting to see how things like Golang may well have evolved out of this problem. Calculating a golang app's dependencies is as trivial as a grep or two, so it's easy to know what tests to run when libraries change.

shcallaway 9y ago
At the very least, this experience has made me question the conventional wisdom that microservices = good and monolith = bad.
- cle 9y ago
  That's conventional wisdom? Outside of loud naive bloggers preaching that microservices solve the world's problems, most engineers I've chatted to IRL have been pretty skeptical of the overall utility of microservice architectures because of the high complexity they add.
- pbreit 9y ago
  Conventional wisdom has always been and remains the opposite.

msangi 9y ago

Wouldn't you need backwards compatibility anyway to avoid the need of upgrading all the services at the same time?

cpitman 9y ago
I usually advocate for storing (and therefore versioning) tests with the code under test, but this one complaint may have changed my mind. Backwards compatibility is incredibly important for microservice architectures. The more tests are black box, the more this would work.