[tlonny]

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...

[kkapelon]

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]

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]

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)

[foobarian]

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]

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]

Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.