3 ms·

And then team 1 needs to upgrade pandas to 2.0, but team 2 is still on pandas 1, so when the main app pulls them in nothing works, so you need to start a cross-

by mjr00 3y ago

And then team 1 needs to upgrade pandas to 2.0, but team 2 is still on pandas 1, so when the main app pulls them in nothing works, so you need to start a cross-team committee to schedule the work to upgrade a single library... Separate services aren't a silver bullet, but as an fyi to the younger software developers, we tried "just have all teams work on the same code base and deployable artifact" for a long while and it didn't work very well either.

charcircuit 3y ago
All the teams will need to migrate sooner or later so figuring out all of the potential problems in migrating and having everyone do it an once is more efficient than each team needing to figure it out separately.
- mjr00 3y ago
  That's not how it plays out in reality. usually nothing gets done because "upgrade this package" is never on anyone's priority list. Or teams end up doing shit like JAR shading or forking and renaming a package with some _v2 or whatever suffix to be able to support both the old and new version simultaneously in the main code base. And then of course nobody ever updates the runtime (hello, enterprise monoliths still running on Java 6/7!) It ends up being a complete mess.
  - NBJack 3y ago
    I'm just grateful a language like Java has any sort of namespace solution to dependency nightmares. I have lost track of how many times I did a git pull on a Python based solution only to find I broke all the things when I tried to upgrade one package.
NBJack 3y ago
That's easy: we'll make the ultimate build system! It will scale, and maintain packages, and compile all the things transitively. Just give me $xx million dollars and a few years, and I'll give you the perfect solution. Just press this button to start the upgrade build and....boom! 10,000 services and their dependencies being built on a ton of hardware; we can practically gurantee your change in dependency will be checked... Whoops, turns out your one dependency change cascaded into about 1.5% breakage....no, I don't know who owns those packsges; why do you ask? That's not my job! /s
wg0 3y ago
Imagine a solo developer, writing an app that is composed of packages/libraries/crates from the get go. Now in one place such an engineer uses pandas 2 in other place pandas 1 but it is just one single app. What does it say about the quality of engineering and mental focus of such a solo developer that cannot accomplish same thing with the same API - OR cannot refactor the already written code for Pandas 1 to Pandas2. Sounds to me like more of an engineering discipline and engineering mindfulness problem. Fix is simple with a simple rule - everyone has to use the latest major version, always. Micro services do not make any sort of people's communication go away, they move it to different boundaries. From dependencies to the business layer/interfaces which is lot harder to navigate and negotiate. Imagine needing a field in your downstream service. They refuse because they don't see it their domain and you cram it on your side and what not. Ask anyone working in micro services environment and they'll tell you it is a recurring issue every quarter if not more.

by mjr00 3y ago

charcircuit 3y ago

All the teams will need to migrate sooner or later so figuring out all of the potential problems in migrating and having everyone do it an once is more efficient than each team needing to figure it out separately.

mjr00 3y ago
That's not how it plays out in reality. usually nothing gets done because "upgrade this package" is never on anyone's priority list. Or teams end up doing shit like JAR shading or forking and renaming a package with some _v2 or whatever suffix to be able to support both the old and new version simultaneously in the main code base. And then of course nobody ever updates the runtime (hello, enterprise monoliths still running on Java 6/7!) It ends up being a complete mess.
- NBJack 3y ago
  I'm just grateful a language like Java has any sort of namespace solution to dependency nightmares. I have lost track of how many times I did a git pull on a Python based solution only to find I broke all the things when I tried to upgrade one package.

NBJack 3y ago

That's easy: we'll make the ultimate build system! It will scale, and maintain packages, and compile all the things transitively. Just give me $xx million dollars and a few years, and I'll give you the perfect solution. Just press this button to start the upgrade build and....boom! 10,000 services and their dependencies being built on a ton of hardware; we can practically gurantee your change in dependency will be checked... Whoops, turns out your one dependency change cascaded into about 1.5% breakage....no, I don't know who owns those packsges; why do you ask? That's not my job! /s

wg0 3y ago

Imagine a solo developer, writing an app that is composed of packages/libraries/crates from the get go. Now in one place such an engineer uses pandas 2 in other place pandas 1 but it is just one single app. What does it say about the quality of engineering and mental focus of such a solo developer that cannot accomplish same thing with the same API - OR cannot refactor the already written code for Pandas 1 to Pandas2. Sounds to me like more of an engineering discipline and engineering mindfulness problem. Fix is simple with a simple rule - everyone has to use the latest major version, always. Micro services do not make any sort of people's communication go away, they move it to different boundaries. From dependencies to the business layer/interfaces which is lot harder to navigate and negotiate. Imagine needing a field in your downstream service. They refuse because they don't see it their domain and you cram it on your side and what not. Ask anyone working in micro services environment and they'll tell you it is a recurring issue every quarter if not more.