3 ms·

>I've tried that in the past. Even if modules aren't tightly coupled, deployment is, so different teams need to synchronize at deployment time. No they don't.

>I've tried that in the past. Even if modules aren't tightly coupled, deployment is, so different teams need to synchronize at deployment time. No they don't. There's no reason why two different teams can't schedule an upgrade of the same service at different times. The riskiness of this is entirely dependent upon how good your integration test suite is. >if a module update introduces a performance bug, it will affect everything else. The module will still affect everything that is dependent upon it if it is rebuilt as a microservice. You're just moving the performance problem from one place to another. >if you want to update a core lib for component X, it will need to be updated (and tested) for everything else. Ok, so upgrade the library and run the full set of integration tests.

tomchristie 11y ago
> The module will still affect everything that is dependent upon it if it is rebuilt as a microservice. Your services are running on different servers (or containers) to each other, so they're partitioned. If one service has a bug that introduces a catastrophic error that takes all the server resources you'll either: Monolith: Bring down the service completely. Microservices/SOA: Timeouts to part of the system, and partial loss of functionality. (Assuming you've done a decent job of engineering for partial failure)
- ken47 11y ago
  There's absolutely no reason why you can't timeout within your monolith.
  - tomchristie 11y ago
    Indeed. But you can't guard against catastrophic system failures (out of memory, disk, processor time, corruptions) in the way you can with independant services.
- crdoconnor 11y ago
  >Monolith: Bring down the service completely. Unless you've scaled your "monolith" horizontally, in which case it takes out one server. If you've got a decent system, it can self heal from that and ping you via a monitoring system. >Microservices/SOA: Timeouts to part of the system Causing all manner of annoying behavior and difficult to track down bugs like an endlessly loading web page on a completely different system that happens a couple times a week instead of a clear error message. >Assuming you've done a decent job of engineering for partial failure If you assume a fantastic job done when engineering then you can make the worst architectural patterns "work". It doesn't mean that they are good ieda.

tomchristie 11y ago

> The module will still affect everything that is dependent upon it if it is rebuilt as a microservice. Your services are running on different servers (or containers) to each other, so they're partitioned. If one service has a bug that introduces a catastrophic error that takes all the server resources you'll either: Monolith: Bring down the service completely. Microservices/SOA: Timeouts to part of the system, and partial loss of functionality. (Assuming you've done a decent job of engineering for partial failure)

ken47 11y ago
There's absolutely no reason why you can't timeout within your monolith.
- tomchristie 11y ago
  Indeed. But you can't guard against catastrophic system failures (out of memory, disk, processor time, corruptions) in the way you can with independant services.
crdoconnor 11y ago
>Monolith: Bring down the service completely. Unless you've scaled your "monolith" horizontally, in which case it takes out one server. If you've got a decent system, it can self heal from that and ping you via a monitoring system. >Microservices/SOA: Timeouts to part of the system Causing all manner of annoying behavior and difficult to track down bugs like an endlessly loading web page on a completely different system that happens a couple times a week instead of a clear error message. >Assuming you've done a decent job of engineering for partial failure If you assume a fantastic job done when engineering then you can make the worst architectural patterns "work". It doesn't mean that they are good ieda.