Comment by shcallaway | Hacker News Reader

Comment by shcallaway | Hacker News Reader

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.

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.

At the very least, this experience has made me question the conventional wisdom that microservices = good and monolith = bad.

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.

Conventional wisdom has always been and remains the opposite.

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

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.

Reply on news.ycombinator.com