4 ms·

Google says zero interest rate policy. No idea how is it related to software architecture though. Maybe it's one of those people who think that software engine

Google says zero interest rate policy. No idea how is it related to software architecture though. Maybe it's one of those people who think that software engineers like to give themselves more work and headache just because, and can't imagine there's something other than his own experience? But whenever I participated in this decision, it was under heavy scrutiny by multiple layers of tech and corporate leadership, and done only because it was the best way to solve our problems.

apantel 2y ago
Zero interest rates -> huge surplus of capital looking for return -> investments in VC and tech -> explosion in tech projects without having to Keep It Simple Stupid -> explosion in complexity (i.e. micro services) and hiring.
- throwaway11460 2y ago
  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.
- rvz 2y ago
  Exactly. Zero interest rate policy where companies believed that there was no need to make money but to only burn it on VC money with complex systems all day long. Look at the amount of complexity that micro-services has gotten banks like Monzo into; over 2,000+ and they are happy with it. [0] An example of bad practices in software engineering which is just only for engineers to persuade their managers around increasing complexity for a increase in salary. [0] https://monzo.com/blog/2022/05/26/humans-who-can-rpc-securing-staff-access-to-microservices https://monzo.com/blog/2022/05/26/humans-who-can-rpc-securin...
financltravsty 2y ago
ZIRP -> free money detached from practical feedback loops -> bad decisions
- syndicatedjelly 2y ago
  each of those things are tenuously related at best
  - financltravsty 2y ago
    Congratulations, this is where a pattern matching system with years of experience having to deal with this industry steps in. Make the intuitive jumps yourself.
    - throwaway11460 2y ago
      From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. Not saying it's always the best approach - as I mentioned, where I worked it was always under heavy scrutiny and chosen only if it was the best approach, which wasn't always.
      - financltravsty 2y ago
        Yes, but it is now impossible to separate them from the hype (same as functional programming languages, cloud providers, etc.). They will continue to be used, but their proliferation into contexts where they are not the best tool (MongoDB as a shining example) was very much a part of the ZIRP environment (the underlying reasons are numerous).
      - rvz 2y ago
        > From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. It is one of the many ways for a VC funded company to quickly run out of money. Given that companies such as Uber and Monzo proudly report that they have thousands upon thousands of micro-services with other startups copying that due to the micro-services hype, I can only see that as a way to introduce more problems such as more operational costs and significant complexity to engineers. Microservices was indeed a ZIRP idea taken to the extreme in many startups believing they could scale like Google, except that they could not afford to and most of them either bankrupted themselves or are still losing hundreds of thousands a month on this idea and are cutting down on the micro-services fad to save money.
waldrews 2y ago
I think he's referring to a 'zero interest rate phenomenon,' a shorthand for an excess that happens when capital is cheap and complexity is rewarded and too easily funded. Supposedly, this leads engineers to choose overly complex solutions, hoping to be rewarded by getting large teams to manage, and gaining experience for their resume. This is in contrast to the scrappy, pragmatic, YAGNI architectural choices DHH regularly advocates. My own view is more pessimistic, that complex architectural choices are made even when the companies involved can't afford them.

apantel 2y ago

Zero interest rates -> huge surplus of capital looking for return -> investments in VC and tech -> explosion in tech projects without having to Keep It Simple Stupid -> explosion in complexity (i.e. micro services) and hiring.

throwaway11460 2y ago
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.
rvz 2y ago
Exactly. Zero interest rate policy where companies believed that there was no need to make money but to only burn it on VC money with complex systems all day long. Look at the amount of complexity that micro-services has gotten banks like Monzo into; over 2,000+ and they are happy with it. [0] An example of bad practices in software engineering which is just only for engineers to persuade their managers around increasing complexity for a increase in salary. [0] https://monzo.com/blog/2022/05/26/humans-who-can-rpc-securing-staff-access-to-microservices https://monzo.com/blog/2022/05/26/humans-who-can-rpc-securin...

financltravsty 2y ago

ZIRP -> free money detached from practical feedback loops -> bad decisions

syndicatedjelly 2y ago
each of those things are tenuously related at best
- financltravsty 2y ago
  Congratulations, this is where a pattern matching system with years of experience having to deal with this industry steps in. Make the intuitive jumps yourself.
  - throwaway11460 2y ago
    From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. Not saying it's always the best approach - as I mentioned, where I worked it was always under heavy scrutiny and chosen only if it was the best approach, which wasn't always.
    - financltravsty 2y ago
      Yes, but it is now impossible to separate them from the hype (same as functional programming languages, cloud providers, etc.). They will continue to be used, but their proliferation into contexts where they are not the best tool (MongoDB as a shining example) was very much a part of the ZIRP environment (the underlying reasons are numerous).
    - rvz 2y ago
      > From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. It is one of the many ways for a VC funded company to quickly run out of money. Given that companies such as Uber and Monzo proudly report that they have thousands upon thousands of micro-services with other startups copying that due to the micro-services hype, I can only see that as a way to introduce more problems such as more operational costs and significant complexity to engineers. Microservices was indeed a ZIRP idea taken to the extreme in many startups believing they could scale like Google, except that they could not afford to and most of them either bankrupted themselves or are still losing hundreds of thousands a month on this idea and are cutting down on the micro-services fad to save money.

waldrews 2y ago

I think he's referring to a 'zero interest rate phenomenon,' a shorthand for an excess that happens when capital is cheap and complexity is rewarded and too easily funded. Supposedly, this leads engineers to choose overly complex solutions, hoping to be rewarded by getting large teams to manage, and gaining experience for their resume. This is in contrast to the scrappy, pragmatic, YAGNI architectural choices DHH regularly advocates. My own view is more pessimistic, that complex architectural choices are made even when the companies involved can't afford them.