4 ms·

I do worry the pendulum will swing too far the other way. Having a separate Lambda function for every web request "because microservices" sucks, but having a si

by mjr00 3y ago

I do worry the pendulum will swing too far the other way. Having a separate Lambda function for every web request "because microservices" sucks, but having a single codebase worked on by 200+ engineers also comes with a lot of problems.

dopidopHN 3y ago
Exactly, I do appreciate micro services but not for the technical aspect. They shine in large cove base where at least a handful of teams are responsible for some services and not other. So you don’t have to get in there backlog too much.
winrid 3y ago
Have a folder/subproject per team?
- mjr00 3y ago
  This helps, but doesn't fully solve the problem. You still end up using the same runtime so it's not like the teams are fully independent. Classic problem is you have a /Team1 and /Team2 folder (or library that gets imported, doesn't matter). Team1 needs to upgrade to pandas 2. They try, but wait, Team2's code depends on Tensorflow which depends on pandas 1.x. You are now in dependency hell[0] and need to do something unpleasant, whether that's forcibly updating everything in that pandas/TF/etc dependency chain, which can be a long and painful project in large codebases, if it gets done at all. Or doing JAR shading or fork-and-rename to be able to support both pandas==1.x and pandas=2 in the same runtime, which may not even work in pandas' case. Or the most common thing, which is just give up and stick with comically outdated libraries and runtimes for way too long. Hello, Java 6/7. [0] https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell
  - winrid 3y ago
    No suggestion will fully solve all the problems. Are you looking for silver bullets in HN comments? :) I would rather deal with folder per team in same repo than services spread across multiple repos that still depend on common libraries/utilities/databases, which has happened at most jobs I've had, and it's a mess.
aledalgrande 3y ago
lol I work on a single codebase with 2000+ engineers

by mjr00 3y ago

dopidopHN 3y ago

Exactly, I do appreciate micro services but not for the technical aspect. They shine in large cove base where at least a handful of teams are responsible for some services and not other. So you don’t have to get in there backlog too much.

winrid 3y ago

Have a folder/subproject per team?

mjr00 3y ago
This helps, but doesn't fully solve the problem. You still end up using the same runtime so it's not like the teams are fully independent. Classic problem is you have a /Team1 and /Team2 folder (or library that gets imported, doesn't matter). Team1 needs to upgrade to pandas 2. They try, but wait, Team2's code depends on Tensorflow which depends on pandas 1.x. You are now in dependency hell[0] and need to do something unpleasant, whether that's forcibly updating everything in that pandas/TF/etc dependency chain, which can be a long and painful project in large codebases, if it gets done at all. Or doing JAR shading or fork-and-rename to be able to support both pandas==1.x and pandas=2 in the same runtime, which may not even work in pandas' case. Or the most common thing, which is just give up and stick with comically outdated libraries and runtimes for way too long. Hello, Java 6/7. [0] https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell
- winrid 3y ago
  No suggestion will fully solve all the problems. Are you looking for silver bullets in HN comments? :) I would rather deal with folder per team in same repo than services spread across multiple repos that still depend on common libraries/utilities/databases, which has happened at most jobs I've had, and it's a mess.

aledalgrande 3y ago

lol I work on a single codebase with 2000+ engineers