5 ms·

According to the former CTO of GitHub, the need for an org to use monorepo vs microservices is dependent on the scaling size: https://news.ycombinator.com/item?

According to the former CTO of GitHub, the need for an org to use monorepo vs microservices is dependent on the scaling size: https://news.ycombinator.com/item?id=33601658 https://news.ycombinator.com/item?id=33601658 According to him, startups work better in monorepos. Microservices work better for medium to large size organizations. Monorepos again for Google size mega orgs. In the end, its a dumb debate. Because it’s a tooling problem, not a code organization problem. It doesn’t matter which you pick, your success or failure in the organization pattern is entirely dependent on how much you invest in tooling and whether that is microservices tooling or monorepo tooling matters not. Anytime you see someone complaining about one or the other and you ask them why, the answer always can be resolved with better tooling.

jiggawatts 2y ago
The dependency on scaling size is precisely my point. There's fuzzy boundaries where one or another approach starts making sense. If you don't know where those boundaries are, if you don't know what business requirements are going into these decisions, then keep things as simple as possible until you do. In other words, don't try to build an airport before you've understood what an aeroplane even is! Quite recently I saw a completed(!) web application project split up into microservices because the enterprise architect insisted that this was the only acceptable approach, and a monolith was "wrong" somehow. A staggering amount of time, money, and effort was expended to basically make a functioning application worse in every possible way. Nobody could understand it, and the EA couldn't explain other than just waving his hands about and making vague, unspecific noises.
- SOLAR_FIELDS 2y ago
  My point here is that ultimately it doesn’t really matter. You can make either work at scale (Spotify for microservices, Google for monorepo). So don’t even bother thinking about it too much, just make a decision and start investing in tooling. Which I think is your same statement here. Ultimately I’m going to ask whoever proposed micro services vs monorepo is: how are you going to qualify shared changes? How are you going to publish artifacts? How are you going to document things and make them reusable? There are ways to do so in both approaches. If someone isn’t answering those questions and weighing them against the effort required to implement only the tooling changes without the application code changes, they’re missing the point and are at risk of just wasting everyone’s time remaking the same mistakes that their predecessors made (not investing in tooling) that prompted the discussion about moving from one to the other in the first place.

jiggawatts 2y ago

The dependency on scaling size is precisely my point. There's fuzzy boundaries where one or another approach starts making sense. If you don't know where those boundaries are, if you don't know what business requirements are going into these decisions, then keep things as simple as possible until you do. In other words, don't try to build an airport before you've understood what an aeroplane even is! Quite recently I saw a completed(!) web application project split up into microservices because the enterprise architect insisted that this was the only acceptable approach, and a monolith was "wrong" somehow. A staggering amount of time, money, and effort was expended to basically make a functioning application worse in every possible way. Nobody could understand it, and the EA couldn't explain other than just waving his hands about and making vague, unspecific noises.

SOLAR_FIELDS 2y ago
My point here is that ultimately it doesn’t really matter. You can make either work at scale (Spotify for microservices, Google for monorepo). So don’t even bother thinking about it too much, just make a decision and start investing in tooling. Which I think is your same statement here. Ultimately I’m going to ask whoever proposed micro services vs monorepo is: how are you going to qualify shared changes? How are you going to publish artifacts? How are you going to document things and make them reusable? There are ways to do so in both approaches. If someone isn’t answering those questions and weighing them against the effort required to implement only the tooling changes without the application code changes, they’re missing the point and are at risk of just wasting everyone’s time remaking the same mistakes that their predecessors made (not investing in tooling) that prompted the discussion about moving from one to the other in the first place.