3 ms·

Agreed, but I'll go a step further and say microservices are really valuable when you have products that are powered through a reasonable DevOps and CI/CD suppo

by adra 4y ago

Agreed, but I'll go a step further and say microservices are really valuable when you have products that are powered through a reasonable DevOps and CI/CD support within and organization. If you're a company that only releases quarterly, a monolith probably makes sense. If you're a company releasing changes daily / hourly, monoliths make progressively less sense and become progressively harder to work with. When we release software (a lot) our downtime SLO is generally zero minutes. If you're a well out together outfit with strict discipline, this can be achieved with microservices. Inversely, monoliths almost never have to deal with multiple components at different release levels, so they don't do a particularly good job to support it, which is why you often see hours long upgrade windows for monoliths. Shut everything down, deploy updates, start everything back up and hope the house is still working plus the changes.

codethief 4y ago
> If you're a company releasing changes daily / hourly, monoliths make progressively less sense and become progressively harder to work with. Counter argument: Your overall CI/CD infrastructure landscape will be much simpler and muss less error-prone. As will be your release and test pipelines. For instance, if you have a few dozen microservices, each being released every other hour, how do you run E2E tests (across all services) before you release anything? Let's say you take your microservice A in version v1.2.3 (soon to be released) and test it against microservice B's current prod version v2.0.1. Meanwhile, team B is also working on releasing the new version v2.1.0 of microservice B and testing it against A's current prod version v1.2.2. Both test runs work fine. But no one ever bothered to test A v1.2.3 and B v2.1.0 against each other…
- upbeat_general 4y ago
  Another issue is backwards compatibility. With microservices, you have to keep your old endpoints open until everyone has migrated, and make sure the new endpoint is always available when upgrading. Much simpler to verify with tests with a monolith.

by adra 4y ago

codethief 4y ago

> If you're a company releasing changes daily / hourly, monoliths make progressively less sense and become progressively harder to work with. Counter argument: Your overall CI/CD infrastructure landscape will be much simpler and muss less error-prone. As will be your release and test pipelines. For instance, if you have a few dozen microservices, each being released every other hour, how do you run E2E tests (across all services) before you release anything? Let's say you take your microservice A in version v1.2.3 (soon to be released) and test it against microservice B's current prod version v2.0.1. Meanwhile, team B is also working on releasing the new version v2.1.0 of microservice B and testing it against A's current prod version v1.2.2. Both test runs work fine. But no one ever bothered to test A v1.2.3 and B v2.1.0 against each other…

upbeat_general 4y ago
Another issue is backwards compatibility. With microservices, you have to keep your old endpoints open until everyone has migrated, and make sure the new endpoint is always available when upgrading. Much simpler to verify with tests with a monolith.