2 ms·

You don't have to test unrelated components if you tweak a monolith either. I suspect the feeling that microservices let you deploy faster come from the fact th

You don't have to test unrelated components if you tweak a monolith either. I suspect the feeling that microservices let you deploy faster come from the fact that such designs often conflate other things together, e.g. the CI system runs the entire test suite for everything regardless of what changed (due to transient CI workers losing their caches), there's one branch into which every change gets merged so you can't control when core library changes affect you, etc. But it doesn't have to be setup that way. Ensuring implementation details don't get mixed up is indeed nice in some ways, but cuts both ways: it makes upgrading core libraries harder in case of security issues and such.

throwaway11460 3y ago
You definitely need to. I was bitten by stuff like the compiler/optimizer deciding to do it differently after the unrelated change, resulting in significant performance degradation and whole service outage. There was a bug in our code that just got surfaced, of course - but it was another team's code that I didn't even know about. Debugging and fixing it was a nightmare. That was when I jumped on the SOA train (wasn't called microservices yet). Another time an unrelated change of another team created a security issue because they improperly used a singleton class from our team's code, and our code became vulnerable because of that. That one was caught during security approval, fortunately - we'd be fucked if it went from CI straight to prod, or if they tested only the changed parts. It's not just about CI. It's about integration testing, user acceptance testing, security approval, etc. If your system goes from CI directly to production then yeah, maybe you don't need microservices that much - but there are still benefits.