4 ms·

This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into mic

by tlonny 4y ago

This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into microservices is total overkill in this instance...

foobarian 4y ago
When do the deploys happen? Will they take longer because of the larger size? How do the IDEs work, do they need to load and index everything?
- XorNot 4y ago
  In an age of 64gb developer PCs, we can handle all but the absolute largest codebases on any random MacBook pretty much. You're not Google, you don't have this problem.
  - foobarian 4y ago
    Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
kkapelon 4y ago
This doesn't cover independent deployments. Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.
- tlonny 4y ago
  I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app. One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices. Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...
  - kkapelon 4y ago
    Simple example. You have an app and just 3 microservices web + recommendation engine + payment gatway This means that the team that handles recommendation engine can deploy as fast as they want while the payment gateway (which is brittle and mission critical) stays put. If you have just a monolith then everytime the recommendation engine is tuned, the payment gateway code is also redeployed with possible downtime (contrived example but just to give you the idea)

4 ms·

This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into mic

by tlonny 4y ago

foobarian 4y ago
When do the deploys happen? Will they take longer because of the larger size? How do the IDEs work, do they need to load and index everything?
- XorNot 4y ago
  In an age of 64gb developer PCs, we can handle all but the absolute largest codebases on any random MacBook pretty much. You're not Google, you don't have this problem.
  - foobarian 4y ago
    Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
kkapelon 4y ago
This doesn't cover independent deployments. Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.
- tlonny 4y ago
  I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app. One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices. Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...
  - kkapelon 4y ago
    Simple example. You have an app and just 3 microservices web + recommendation engine + payment gatway This means that the team that handles recommendation engine can deploy as fast as they want while the payment gateway (which is brittle and mission critical) stays put. If you have just a monolith then everytime the recommendation engine is tuned, the payment gateway code is also redeployed with possible downtime (contrived example but just to give you the idea)