Let's assume without proof that Glibc developers are good. Similarly, kernel.org developers are good as are the gcc.gnu.org people.
Should glibc, gcc and the kernel be in a monorepo?
(Cue laugh track ...)
Monorepo is great if you're really good
51–60 of 159 posts
Re: Monorepo is great if you're really good
#52Linus Torvalds said something about this, in relation to microkernels. But the gist is in how interactions between many pieces makes the whole thing complex. Here's the quote from his book "Just for Fun". "The theory behind the microkernel is that operating systems are complicated. So you try to get some of the complexity out by modularizing it a lot. The tenet of the microkernel approach is that the kernel, which is…
> "...The simplicity you try to reach is a false simplicity." Also applies to some microservice architectures I've seen. People completely disregard the complexity (and overhead!) of the interactions between microservices.
Does anyone here do Microservices well? And keep them in a monorepo?
Re: Monorepo is great if you're really good
#53Earlier quoted context omitted.
> "...The simplicity you try to reach is a false simplicity." Also applies to some microservice architectures I've seen. People completely disregard the complexity (and overhead!) of the interactions between microservices.
Does anyone here do Microservices well? And keep them in a monorepo?
We (~150 eng) build microservices in a polyglot environment (mostly Python, JS, and Go), all in a monorepo! We also build + deploy in containers with Jenkins, etc.
The structure looks something like this:
|-- third_party (third party libs)
`-- python
|-- libs (internally-written, common dependencies)
`-- application_name
|-- client (react app, connects to flask)
|-- server (flask app, connects to services)
`-- services (microservices)
Let me know if you have any questions, I'm happy to answer them! I'm super happy about our setup and eager to share it :)
Re: Monorepo is great if you're really good
#54You're just pushing your trouble into a shadow layer that's hidden. You still have just as much complexity. It's just not encoded.
If branch A on repo X will only work with branch B on repo Y, you're holding that relationship in an uncoded way. It's true and unrepresented, and you never want that.
Re: Monorepo is great if you're really good
#55Linus Torvalds said something about this, in relation to microkernels. But the gist is in how interactions between many pieces makes the whole thing complex. Here's the quote from his book "Just for Fun". "The theory behind the microkernel is that operating systems are complicated. So you try to get some of the complexity out by modularizing it a lot. The tenet of the microkernel approach is that the kernel, which is…
> The theory behind the microkernel is that operating systems are complicated. Seems like a blatant straw man to me.
The advantage of microkernels is that they can be extended with “untrusted” code like hardware drivers or file systems. This runs in user space and thus any bugs in such code will not crash the kernel process.
So I agree with you that Linus is presenting a straw man and your comment shouldn’t have been downvoted.
Re: Monorepo is great if you're really good
#56I think the whole idea of simplicity vs complexity, and the linked article "Worse is Better" is fundamentally ill-conceived. Simple vs. Complex is contextually relative. Literally every observer is subject to their own opinion of a design. Success in the wild = success. I think success in the wild, especially in our age of information overload, depends on being "convenient to understand and operate".
A 'simple' solution may not be easy to grok. Few people think at the level of axioms.
A survivable solution must be passed along to many people across generations.
For some, monorepos are simple because that is what they know, for others multirepos are the norm. The survival of the firms that adopt these strategies will somewhat dictate what repo strategy propagates in the world, not the best design.
Re: Monorepo is great if you're really good
#57Let's assume without proof that Glibc developers are good. Similarly, kernel.org developers are good as are the gcc.gnu.org people. Should glibc, gcc and the kernel be in a monorepo? (Cue laugh track ...)
Did you just invent the unikernel?
Re: Monorepo is great if you're really good
#58Always makes me think of a philips radio my Dad told me about called the "Mono Knob". It had a complex design that allowed control via just one knob. He said they were always in the shop for repair when he worked as a teenager in a radio store.
Re: Monorepo is great if you're really good
#59Ugh I don't like his use of the word dumbass. Coding is hard, it's easy to break things. We've developed lots of tools of strategies so we don't have to rely on people getting it right every time. Branching: getting forked by your worst programmer This example seems contrived I've never worked anywhere where having a fork that works for some scenarios and not others is tolerated for long. This would be given the high…
> In most cases I'd trade a little bit of modularity for increased domain logic consistency
In my experience that is not the entire trade-off. At scale, you also get circular dependencies between modules, which makes refactoring, migrations, deprecations, and other improvements incrementally impossible. Sometimes this can happen unintentionally through including a "upcall" to a module that is actually the best tool for the local job at hand.
In the case of several repos, you will notice the extra work needed to pull in the extra project. In the case of a monorepo... it might look like any benign change.
Re: Monorepo is great if you're really good
#60> the entire code base got forked, and the entire org is now held hostage by the dumbass. > Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies. Really, the one consistent thing is that if you have a good team, you'll make it work no matter what tech or decisions you make (assuming you're also good enough to know when…
> repo A branch B can only be built with repo C branch F, but all the other repos should be master This alone is pretty much what makes me prefer monorepos. If you don't have a stable interface for all of your in-house dependencies (and nobody does early on in a project), you're doomed to spend a ton of time matching branches like this. Not to mention, a naive build process of "grab the latest everything and build it…
All modern dependency management tools solve this problem by allowing dependencies to be specified as URI's.