Hacker News new | ask | show | jobs
by BurningFrog 2206 days ago
Microservice testing come with version combination hell.

If you have 10 microservices, each of which can be on one of two versions, that's 1024 combinations. How do you test that?

2 comments

Sounds like the services shouldn't be split up into 10 if there's that much dependency going on.

Like, services are an abstraction. If one service has to call all other 9 services, and the same occurs for the other 9 services -- then that's a monolith acting over the network.

Im yet to see a system that consists of other versions of code than ”new” and “current”. You test against changes only, what you described is some mess in deployed versions / versions management.
How is this different from what I'm describing?

"New" and "current" are two different versions.

In that you always test against only the versions you have deployed + new version of single service.

Which downplays your exaggerated 1024 cases to 1.

OK, but then you have a very controlled way of deploying each service.

Each team can't just deploy a new version of their microservice when it makes sense to them.

So your collection of microservices becomes a bit of a distributed monolith, losing some of the classic microservice advantages.

Or so it seems to me. I just read about this stuff, have never used it. Happy to be educated.

Its losing „some” adventages of startup grade microservices and gain maintainability adventages of „netflix/facebook” level grid... Depends whats your scale. Shipping shit fast is often not the best solution at that scale, doing it right is. And I have already explained to someone else in this thread why that approach is important.