3 ms·

I don't think that's true, careful engineers like microservices/SOA because deploying a small fix doesn't necessitate testing and deploying everything else too,

I don't think that's true, careful engineers like microservices/SOA because deploying a small fix doesn't necessitate testing and deploying everything else too, service outage is limited, and rollbacks easier. Careful engineers always test everything they are going to deploy - and I don't mean just running the unit test suite. Careful engineers also appreciate when internal implementation details aren't exposed to the rest of the system, interactions are monitored and audited, interfaces are strictly defined and enforced, and services are not bound to run on a single machine - security boundaries and contexts, reduction of attack surface. I also don't think he's arguing for carefulness at all - he's saying that if it wasn't for the free money, engineers would be forced to move faster and break more things to make quick cash. Understandable from business investor perspective, but has nothing to do with careful engineering. He's basically saying "you're so careful I am not making my money, fuck all that and deliver already".

mike_hearn 2y ago
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 2y 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.

mike_hearn 2y ago

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 2y 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.