4 ms·

Over the past 10 years dev tools (eg. git, IDEs, laptops) have also become more performant by some small constant factor, 2-3x, which isn't massive in compariso

Over the past 10 years dev tools (eg. git, IDEs, laptops) have also become more performant by some small constant factor, 2-3x, which isn't massive in comparison to Moore's law stuff, but means that a larger fraction of new software projects can start monolithic and stay monolithic for longer. Unless you're handling millions of lines of code and 1000s of developers, you won't need to abandon a monorepo or commit to expensive custom dev-platform investments.

bob1029 5y ago
> Unless you're handling millions of lines of code When including our vendor's WSDL generated reference sources, we are well in excess of 1mm lines of code. I think even omitting that we are very close. I cannot imagine us ever getting too big in those terms. Our full checkout is ~400 megs right now. If some day github says we are too big and need to break shit up, Ill move us to perforce or something even more ridiculous. Our main product does a full re-build in ~45 seconds on a powerful developer machine. Incrementals for more likely work areas are closer to 8 seconds. Full monorepo checkbuild takes about 5 minutes. For reference, we do use .NET so JIT is an ally here.
- sk5t 5y ago
  > full re-build in ~45 seconds That's cute. How about the test suites?
  - deleted 5y ago
    [deleted]
  - Too 5y ago
    Likely faster, less flaky, less complicated setup and higher coverage than the integration test suite of a set of microservices.
  - hactually 5y ago
    Using Go stack here. Can confirm it can be done. We're at 8s to build and another 15s to run full test suite.
Tabular-Iceberg 5y ago
If a repo needs to be broken up for performance or organisational reasons, is there really a reason to prefer to integrate the parts as microservices rather than as libraries?
- CuriouslyC 5y ago
  The main benefit of microservices there is that they can be independently deployed. If you have libs into a monolith you have to redeploy the entire thing, which may involve coordination. I still mostly prefer the libs + monolith approach though.
KptMarchewa 5y ago
10 years ago SSDs weren't common, and they are 10x performance improvement alone.

bob1029 5y ago

> Unless you're handling millions of lines of code When including our vendor's WSDL generated reference sources, we are well in excess of 1mm lines of code. I think even omitting that we are very close. I cannot imagine us ever getting too big in those terms. Our full checkout is ~400 megs right now. If some day github says we are too big and need to break shit up, Ill move us to perforce or something even more ridiculous. Our main product does a full re-build in ~45 seconds on a powerful developer machine. Incrementals for more likely work areas are closer to 8 seconds. Full monorepo checkbuild takes about 5 minutes. For reference, we do use .NET so JIT is an ally here.

sk5t 5y ago
> full re-build in ~45 seconds That's cute. How about the test suites?
- deleted 5y ago
  [deleted]
- Too 5y ago
  Likely faster, less flaky, less complicated setup and higher coverage than the integration test suite of a set of microservices.
- hactually 5y ago
  Using Go stack here. Can confirm it can be done. We're at 8s to build and another 15s to run full test suite.

Tabular-Iceberg 5y ago

If a repo needs to be broken up for performance or organisational reasons, is there really a reason to prefer to integrate the parts as microservices rather than as libraries?

CuriouslyC 5y ago
The main benefit of microservices there is that they can be independently deployed. If you have libs into a monolith you have to redeploy the entire thing, which may involve coordination. I still mostly prefer the libs + monolith approach though.

KptMarchewa 5y ago

10 years ago SSDs weren't common, and they are 10x performance improvement alone.