4 ms·

If the capital needs returns, how come they don't need to keep it KISS? Seems like they wouldn't only if it helped them get the returns.

apantel 2y ago
I think it’s more that because there was so much capital looking for an outlet, anyone could suggest any big large thing and the money would be made available. Vs tight times where every expenditure is scrutinized.
mike_hearn 2y ago
If the world is given no choice but to give you money, you're not going to be careful with that money. DHH argues that careful engineers would use microservices a lot less.
- throwaway11460 2y ago
  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.

apantel 2y ago

I think it’s more that because there was so much capital looking for an outlet, anyone could suggest any big large thing and the money would be made available. Vs tight times where every expenditure is scrutinized.

mike_hearn 2y ago

If the world is given no choice but to give you money, you're not going to be careful with that money. DHH argues that careful engineers would use microservices a lot less.

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