4 ms·

Wouldn't they similarly need comparable amount of time to update all 14 microservices? IMHO unless you have a strong engineering culture, having the same depen

Wouldn't they similarly need comparable amount of time to update all 14 microservices? IMHO unless you have a strong engineering culture, having the same dependencies is the only way to ensure they are all properly updated (regarding security updates, and replacing deprecated dependencies/versions.)

mjr00 3y ago
> Wouldn't they similarly need comparable amount of time to update all 14 microservices? In my experience doing this at AWS and elsewhere, no, the services case is much easier. Even just the ability to do releases in chunks 1/14 of the size is a huge advantage. On top of that, your services are going to have smaller dependency chains, and transitive dependencies are truly where dependency hell[0] comes into play. It boils down to complexity being multiplicative rather than additive. Depending on the size of everything, each service is probably more like 1/50th the amount of work rather than 1/14th. > IMHO unless you have a strong engineering culture, having the same dependencies is the only way to ensure they are all properly updated (regarding security updates, and replacing deprecated dependencies/versions.) This is working under the assumption that all your code and services should always be updated to the latest, which isn't necessarily true. I still have smaller, infrequently updated services running and happily chugging away that run on Python 3.5. Other codebases have been upgraded to Python 3.10, sure, but what's the harm in letting this one run on an end-of-life Python, especially given that it's a backend service, with no public access, that only communicates via RPCs? A vulnerability might be found in Python 3.5 that necessitates an upgrade, but it's not like moving to the latest version of everything prevents that -- i.e. "Heartbreak"[1] only affected OpenSSL 3, not people still using OpenSSL 1.1! [0] https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell [1] https://arstechnica.com/information-technology/2022/11/openssl-3-patch-once-critical-but-now-just-high-fixes-buffer-overflow/ https://arstechnica.com/information-technology/2022/11/opens...
theshrike79 3y ago
There are always those specific cases you need to do when upgrading major versions. The chance of a percentage of 14 microservices just plain not using that feature is bigger than the chance of that monolith not using it. A completely contrived and fake example: The language you're using has a complete refactor of its math library, everything must be rewritten in a new style that's incompatible with the old style. In a microservice world there's a good chance that very few of those actually need the high-powered math library. But your monolith has a few sections that use it so the whole shebang is delayed until that bit is rewritten to the new API.

mjr00 3y ago

> Wouldn't they similarly need comparable amount of time to update all 14 microservices? In my experience doing this at AWS and elsewhere, no, the services case is much easier. Even just the ability to do releases in chunks 1/14 of the size is a huge advantage. On top of that, your services are going to have smaller dependency chains, and transitive dependencies are truly where dependency hell[0] comes into play. It boils down to complexity being multiplicative rather than additive. Depending on the size of everything, each service is probably more like 1/50th the amount of work rather than 1/14th. > IMHO unless you have a strong engineering culture, having the same dependencies is the only way to ensure they are all properly updated (regarding security updates, and replacing deprecated dependencies/versions.) This is working under the assumption that all your code and services should always be updated to the latest, which isn't necessarily true. I still have smaller, infrequently updated services running and happily chugging away that run on Python 3.5. Other codebases have been upgraded to Python 3.10, sure, but what's the harm in letting this one run on an end-of-life Python, especially given that it's a backend service, with no public access, that only communicates via RPCs? A vulnerability might be found in Python 3.5 that necessitates an upgrade, but it's not like moving to the latest version of everything prevents that -- i.e. "Heartbreak"[1] only affected OpenSSL 3, not people still using OpenSSL 1.1! [0] https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell [1] https://arstechnica.com/information-technology/2022/11/openssl-3-patch-once-critical-but-now-just-high-fixes-buffer-overflow/ https://arstechnica.com/information-technology/2022/11/opens...

theshrike79 3y ago

There are always those specific cases you need to do when upgrading major versions. The chance of a percentage of 14 microservices just plain not using that feature is bigger than the chance of that monolith not using it. A completely contrived and fake example: The language you're using has a complete refactor of its math library, everything must be rewritten in a new style that's incompatible with the old style. In a microservice world there's a good chance that very few of those actually need the high-powered math library. But your monolith has a few sections that use it so the whole shebang is delayed until that bit is rewritten to the new API.