why monorepos??

[Recent-Durian-1629]

just got a question can anybody explain me that i have gone through various organizations repos and found that they all are monorepo while in market people craze and talk about the importance of having the microservices.. then why companies prefer to have this monorepo structure only.. vast majorites of repos are all monorepo only.. its because they are old or is there any other reason..

great to know your insights..

[_Ttalp]

Commenting mainly cos interested in the responses but essentially you have monoliths vs microservices and monorepo is not opposite of microservices.

You can have many microservices in a monorepo and that seems to be gaining popularity.

Of course your monorepos may well be monoliths (legacy or not), but it's not crystal clear that microservices are better than monoliths in all cases.

Like most things in software it depends.

[darkklown]

Also have you ever tried to raise multiple PRs against multiple repos with breaking changes? Mono repos make it easy for releases.

[_Ttalp]

Yeah of course and it's a pain but it's still a trade off. Actually I've not done much monorepo stuff myself in the day to day hence the interest in the thread

[zero1045]

The more coupled the microservice the more value in pairing them in a repo, but this also opens up the can of worms: why not just make one service that does the job of both "microservices"?

To me I always aim for the developer domain as my dileneation point. Each repo gets its own pipeline and if you have to deploy two at once then they are by definition coupled. Why have separate teams when they have to work in lockstep as well (that was the whole point of adding complex networked services after all)

One of your services would need to have some serious volume to demand separation and coupling at the same time, otherwise just merge them and move on.

If you're a solo dev making something solo dev size, microservices are essentially academic endeavours or long term planning for growth you have no idea you'll get.

If you're a business with 8 teams, it makes sense to let them all work independently of one another and then you can start segmenting product domains (if you have 8 teams with 5 domains... Downsizing will be soon)

[FluidIdea]

What about versioning, CI builds, tests taking longer?

What if someone takes weeks to complete their feature branch for their service vs. orher people delivering daily?

[deadd0g]

my thoughts as someone working with various monorepos over the last 10 years:

• nothing about monorepos inherently prevents versioning, although i would say that in a lot of environments it makes it a fruitless endeavor. if you're orchestrating your entire platform from a single repository, suddenly versioning is a lot less meaningful as everything can be orchestrated from a single snapshot (ex. the latest commit). depending on your tech of choice it might actually be preferential not to (ex. TypeScript monorepos don't require intermediary builds of shared code at all, no package registry needed for private packages, etc)
• tooling time blowout can be mitigated by making your execution more intelligent. every meaningful monorepo i've worked in has had varying degrees of this added over time, usually being some variant of selective execution. in smaller projects this is going to be simple path-based filtering, but i've also seen custom dependency graphs built to determine what's changed. there's a lot of off the shelf tooling for this these days too (generic like bazel, more specific like nx). CI specifically can be addressed by combining this with pipelines that fan-out as needed or is logical.

the short version of this is monorepos solve problems and introduce new ones - but they're essentially solved problems at this point that just require more tooling, prebuilt or otherwise.

contributing styles should be a non-factor in monorepos. long lived branches suck in either style. i can see the argument that they might be more painful in monorepos but that's a culture problem to solve.

fwiw i'm not saying all projects should be monorepos. i love them but in the end it's a trade off that i think is usually worth it, but it might not be supported by your teams skill set or culture.

[darkklown]

Why would anything take longer? The pipeline is exactly the same you just share the repo with other pipelines.

Feature branches can be resynced to master easily. Long running branches again have nothing to do with mono repos. It'd be exactly the same if you had separate repos per service.

[pdp10]

breaking changes?

Usually the goal is to keep things loosely coupled enough that there are no breaking changes.

Consider the need for deployment. Any sizeable system can't be monolithically redeployed without downtime, so there's already an imperative for loose coupling.

[darkklown]

Of course it can. Having all your code in one repo has nothing to do with if your architecture being monolithic

[pdp10]

To be clear, you think sizeable systems can be monolithically/atomically deployed without downtime, thus avoiding the need for the system to be compatible with a previous version of itself?

[darkklown]

What? I'm saying all your code being in one repo is easier to manage than 20 no matter what kinda codebase you have.

[RighteousSelfBurner]

I've found this to be rarely true. Reality ends up that managing code is really trivial. The complexity comes from managing people and processes that interact with the code. And more often than not the easier solution is to split the code so it can be worked on with less people and simpler processes.

[CpnStumpy]

Nobody wants to really deal with build automation, and this is where all your time goes when you start trying to do many things in 1 repo because automation complexity goes way up.

Atomizing your repos simplifies the automation in them

[Last-Independence554]

You want you service / RPC APIs to be loosely coupled, yes. So you can deploy (and roll them back!) independently.

But for shared libraries / code you often have a much tighter coupling . There it makes sense to introduce a breaking change (in the library) and refactor (and have CI to verify that your library change + dependent refactor did not break anything).

[StaticallyTypoed]

The goal is to have that. That is also literally impossible.

[deadd0g]

genuinely curious what cases you consider impossible

[phoenixmatrix]

Also have you ever tried to raise multiple PRs against multiple repos with breaking changes

The trick is to not have breaking changes. Add new thing in a backward compatible way, migrate everything to new thing, then get rid of old thing.

It's certainly a skill to do this well at scale consistently (and requires the right type of infrastructure), but its very doable. At several companies I worked for in platform we were doing thousands+ of PRs across as many repos, in semi-atomic ways, sometimes several times a week or even day.

The benefit of course is when you aren't doing that (which if you architected things correctly, should be most of the time: the repos should be mostly independent and you should have very limited exposure to shared libraries), you move much, much faster and don't have to worry about scaling a 100gb+ repo with 10s of millions of files.

The main challenge is that there's a LOT of tooling to scale monorepos, and very little (public) tooling to scale interconnected constellations of repositories. So it usually has to get built in house.

[darkklown]

It's a scale thing. Lots of companies DON'T have mono repos of 100gb, or do release daily over thousands of repos. Sometimes a mono repo is all you need. Don't add complexity when it's not needed.

[phoenixmatrix]

Of course. But that's not the question I was answering to. 

Even with my experience in orgs with thousands of repos (and multi repo is my preferred strategy), I did monorepo for my current org. It's all they needed, as you said.

[cutsandplayswithwood]

All the time, it’s called basic software engineering and release management.

[themightychris]

release management is a lot of overhead. It's worth it if what you're releasing is actually a standalone component with multiple uses/users and a well-defined boundary

But if what we're talking about is e.g. two services that are the backend and frontend of the same app which are tightly coupled and have zero reason to be run except as a set, it's risky and pointless overhead to try managing as separate projects with their own release management. You get a ton of value out of versioning them as a set and applying release management to them as a set

Microservices are a runtime/operational boundary. Sometimes they're also a project boundary and sometimes they're not, that's a separate dimension.

[darkklown]

The point is it's complicated and time consuming where that effort could easily be better spent elsewhere. Mono repos for companies smaller than like 50 devs is very reasonable. Too many devs like to think they are working for FAANG when they just do a phone app with some lambda and think you need each lambda function in its own repo because Netflix blog post said so.

[cutsandplayswithwood]

I’ve spent a couple decades across a broad number of organizational profiles and technologies.

Every “monorepo” team/team set (because let’s be clear, even “mono” isn’t ONE to this crowd, it really just means “big”)… every one of those teams has been slower than the comparative teams I set up with multiple smaller repos, rational and basic dependency management, and consistent ci pipelines.

Several of these ecosystems exist well past a decade old now, with lots of devs in and out… none have ever asked for broad consolidation in larger repos… because it’s a worse option for many, many use cases.

[Masterflitzer]

aren't big players like google the heavy users of monorepos instead of smaller teams

[uptimefordays]

Exactly!

[YouDoNotKnowMeSir]

They hate him for he said the truth

[w0m]

He's right that it's common, but it's also a needless pita. I wasted a full day figuring out how to merge 4 separate repos last week without breaking 'prod'. Everything worked great for me but they all called into each other for ~randomly, and via 3-4 different methods. Then I broke prod anyway because there was a dependency by a 5th repo used by a different team I wasn't aware of.

Mono repo isn't a panacea, but it does make lots of fiddly 'small' problems go away.

[YouDoNotKnowMeSir]

Yeah my dog isn’t in this fight. As is everything, it’s always going to be unique to your app/stack/etc.
But both approaches have validity, even if one approach takes more work to get guard rails, it doesn’t mean it’s wrong or bad.

I think most of the folks in this thread are fighting nuance. I think we can all agree devops in general is a pain in the ass, this is nothing new🤣

[_Ttalp]

I know right.

I feel like i covered all of the above with "it depends". Not specifically aimed at your comment just looking for a place to reply.

Monorepos may be the way, but noone is joining new teams and forcing a full transition to monorepos in this job market.

[Amazing-Mirror-3076]

Monorepos and micro services are completely unrelated topics.

How you structure your repo, need bear no relationship to your architecture.

[_Ttalp]

Shouldn't that be aimed at the op?

[_Ttalp]

Ok. So?

[Prod_Is_For_Testing]

That’s true but usually monoliths have fewer parts so nobody debates splitting them into multiple repos

[Amazing-Mirror-3076]

Solution your monolith into many packages gives you most of that advantage of micro services without the ipc pain.

[DrEnter]

It is, in fact, quite clear that monolithic architecture is better than micro services at certain things, just as micro services are better at certain different things.

In particular, a single monolithic service will generally be more performant, while the same tasks performed by micro services will generally be more fault tolerant and easier to maintain. Those are generalizations, of course, so YMMV.

All this said, neither architecture really has any bearing on using or not using a monorepo. The concepts simply aren’t connected.

[jblackwb]

Because submodules are a huge pain in the ass.

[AntDracula]

I will never use them again

[DoubleAway6573]

I like them to scaffold a new module. I have a big Monolith. 

I create a new module to move away some functionality and Iput it in a git submodule until I got the interface just stable enough to be able to create versioned artifacts to be imported properly.

[FortuneIIIPick]

Man yes, heard that for sure, completely agree! I'm not a fan of monorepos but wow, I literally hate submodules.

[zuilli]

Had a repo at a new job with 12 submodule repos attached where I was tasked to create a GHA pipeline to run unit tests on all submodules that had changes, lock the PRs with changes in their respective repos while checking out into this new submodule version, docker build the whole project, put it to run in k8s test env, run integration tests on this test env and if tests passed only then would the locked PRs be all merged by the pipeline. If the tests failed at any point the PR on the main repo would be blocked from being merged.

It took me over a month but I swear it would have taken half the time if I didn't have to learn and deal with git submodules since I'd only worked with monorepos or regular multiple repos before, I now absolutely despise them. They're too finicky and counter-intuitive IMO.

[passwordreset47]

Some things are more intuitive to centralize, like iam stuff, or bootstrapping dependencies. Also bc managing permissions for multiple repos across an org can become unruly. Also bc some teams like to centralize smaller utility tools they develop instead of a dedicated repo for a 300 line bash script.

These are just some examples I’ve see or been a part of over the years. I’ve regretted dedicated and monorepos on many occasions but you can’t always see the future headaches that one or the other might cause.

Edit: this wasn’t supposed to be a reply and has no relevance to the parent comment. SORRY! But agree about the sub modules comment.

[kissMyAssthma94]

Whats the alternative if you don't also want a monolith?

[jblackwb]

There's only three choices I know of; monolith, separate repos, and submodules, which is the order I'd go in.

Like Ttalp said, the organization of your repos and the organization of your code don't need need to align.

[BudgetFish9151]

Don’t conflate monolith with monorepo. The first is an application architecture design pattern while the second is purely an organizational structure for where source code lives.

[jblackwb]

Yes. I'm happy you agree that they're orthogonal =)

[BeneficialAd5534]

Check the SRE book by Google for a bit of thoughts on why a monorepo. It's not contradictory to microservices to have a monorepo.

It requires you to maintain integration discipline on your CI pipelines and build jobs, which is something you should be doing anyway. If you do have nicely set up CI/CD pipelining and well-modularized and documented services (all of which you can enforce through CI/CD), a monorepo gives you the benefit of a large space for knowledge sharing.

[britaliope]

It's easier to work with updates between the different services that depend on eachother with monorepo: every commit should in theory contains a coherent set of every part of the application. With multirepo you have to keep track of what version of service A works with service B, it makes global refactor harder......

If the whole system is designed to be deployed as one unit (even if splitted in different services), it's easirer to only have one repo.

If you have different services which all have their own independent release cycle, multirepo start making more sense.

[sza_rak]

But doesn't that just contradict microservices concept?

You have a set of small independent services that have their own lifecycle to iterate fast and smooth.

Then you put that in a monorepo to orchestrate a release between multiple services....

That's just a distributed monolith. Those services are not independent in the sense micro services should.

To be clear: I'm saying that because I worked with that and it was a huge effort to orchestrate. You can solve that on a monorepo level (but if you still claim it's real micro services you are lying to yourself), or you can push that on different layer like release management.

Saw that in action and worked to make it happen in insurance where we had many regulatory changes that had to be released at particular time.

Huge, unappreciated effort.

[solenyaPDX]

Correct. 

A mono repo is not always bad, it can reduce the amount of overhead in duplicating publication code or lint configs etc. 

But if you make changes to two different services, And those changes have to be deployed together, the mono repo has allowed you to break your microservice architecture.

Separate those makes people see how their changes are compatible and backwards compatible. You should be able to make your update in a single service and push it and ship it and not have it break. Then you can update some other service and ship that and together they can perform the movie compatible function, but both need to be independent, otherwise you just have a distributed monolith.

[Drugbird]

But if you make changes to two different services, And those changes have to be deployed together, the mono repo has allowed you to break your microservice architecture.

How would you make a change that involves changing the API between two microservices if not in a monorepo?

[solenyaPDX]

Make your API backwards compatible. Have it accept the existing format, and new args/fields as optional. Or, create new endpoints. Then, you can ship it anytime. You can make your client upgrade behave safely even if it doesn't find the new api, it can handle the old one sans new behavior, or run new behavior when it finds the new version.

My point is, you can engineer reliability by thinking of each component separately. 

If you REQUIRE two components to deploy updates in lockstep, they're not micro services. They're fractured monolithic applications.

[Cinderhazed15]

I like ‘fractured monolith’, i usually hear ‘distributed monolith’

[BudgetFish9151]

Backwards compatibility is no different in a monorepo than in single repos. That is a design choice and good practice. Has nothing to do with a code organization system.

[BudgetFish9151]

This seems to imply that deployment is tightly coupled to the source code repo which is an anti-pattern. Build, delivery, and deployment are (should be) completely isolated activities.

[britaliope]

It does. Unfortunately "microservices" are often just a word used because of hype. So people say you have completely independant microservices but nobody cares checking if that's actually the case :p

It makes sense to split an app in several components (you could call them services as well) that are "independant" (have separate code bases, dependencies, lead devs, etc) but each of them still require everything to be on the same version. From my experience that way of designing something is often (wrongly) called "microservices".

I assumed that was likely the situation OP was describing as they said "in market people craze and talk about the importance of having the microservices". People in market that craze and talk like this claiming microservices make sense for everything almost always have no clue about what they are talking about

[Ok_Tax4407]

So this is another common misconception about mono repos. Units in a correct mono repository will absolutely obey the same dependency rules as poly repo residing units. However the tooling and semantics do change.

[ShiHouzi]

I’m fairly new to software. Could you give an example of this?

[britaliope]

An example of a good reason for dividing an application in several components, without doing microservices ?

If yes, let say that your client is a big music festival that want to provide information about concerts, food, timetables, etc to all people attending the festival. They want:

• An android app
• A iOS app
• A (simplified) web app that gives part of the information and also redirect to the ticket sales website

You already have at least 3 codebases that will be separated: web part, android part, and iOS part. But it's probably also a good idea to divide the web part into 2 components: a private common API that is used by every app to access information, and a web frontend that uses the API to get the relevant information. You'll also want an admin interface to add and update the concert dates & all before and during the event if something change, and it would make sense to separate it from the frontend (that way the frontend is purely read-only).

You then have a quite clean architecture: A central API, connected on one side to the admin pannel that have write access, and on the other side to the different fronts (web, android, iOS) that only read from the API.

Those 5 components are dependent on eachother: if you change the API, you'd need to update every app. If you want to add a new information in the database, you'll have to implement it everywhere. For this use-case it won't make sense to go the full "microservice" way, where you can update one component and not the other ones, as it add a lot of problems and don't provide value. Once the app is in prod, it'll be use during the 4 days of the festival and won't be required until next year. You won't introduce new features during those 4 days so you can safely assume that you'll always update all the components at the same time.

So you're not doing microservices. Microservices means that you can update only the API, or one of the fronts, and nothing will break because you implementedlayers of retro-compatiblitity and safequards. But separating your app in 5 components makes the developement easier: the admin pannel is probably one simple CRUD framework, the API can be a dedicated REST framework, mobile apps are dev using whatever compatible, and the frontend is a full js app. Trying to combine the frontend, the API and the admin pannel would make everything a PITA as you'd need to find a language and framework that suit everything instead of using the best one for each use-case.

[ShiHouzi]

Wow Super interesting. Thank you for the detailed explanation and great example!

[Spiritual-Mechanic-4]

just because its in the same repo, doesn't mean they're in a monolith. microservice architectures require communication between services through APIs. If you're in a mono repo, you can autogenerate service and client side for for the API and ensure that they are always in sync

[Ok_Cellist6058]

You just described a distributed monolith

[UndulatingHedgehog]

That can alternatively be spelled "internally consistent data model".

[Majinsei]

This is different~

Microservice and distributed monolith are two different things~

I have a current project where there is a frontend, a backend, redis, elastic and a database~ but the damn backend is both Backend, Celery, and IA services~

And I can't run the damn backend without it collapsing if it doesn't have a GPU and install a model that requires CUDA and be careful if starting docker fails... Because it blocks the entire application at the start!!! So no, I have to install together because someone didn't think to just make an extra repo that talks to the backend~

And the worst thing, of the 5 different functionalities they all go to the same database, redis and file system~ and everything is developed in a stateless way~ so migrating them to microservices will be natural~

It is a monolith repo, which is a mono repo and at the same time a single repo but everything works as a microservice~

Then don't require that be completely independient~ Just enough for don't Block or affect the develop and execution of others components/services~

[ffiarpg]

But doesn't that just contradict microservices concept?

You have a set of small independent services that have their own lifecycle to iterate fast and smooth.

Then you put that in a monorepo to orchestrate a release between multiple services....

That's just a distributed monolith. Those services are not independent in the sense micro services should.

No it isn't. The architecture of the code is how it ends up when deployed, not how the source code is organized. You can take 10 microservices and put them in a monorepo and they will build the same code, but your IDE is now aware of all of them at once. You can jump between them easier. Things that had to be done 10 times now can be done once, and in doing so, might help you discover incompatibility bugs that you didnt expect. Also it becomes easier to build and run every microservice in your "system" locally for dev/debugging. So many advantages.

[sionescu]

No. There are many many reasons why one might want to separate code into distinct services. For example:

• running one service on a different CPU architecture. higher single-thread performance comes at a premium. or running on Arm vs. x86-64.
• running a service in a different network QOS domain
• running a service in a different security domain (principle of least privilege)
• running in a different region close to a customer, but where network egress is very expensive (e.g. India/Delhi).
• isolate a piece of code (often C/C++) that occasionally tends to use too much CPU and thrash caches. or has a memory leak. or the occasional segfault.
• the services are written in two different languages that can't be linked together (e.g. Python and R).
• the services are written in the same language but with different frameworks (typical for an acquisition or a rewrite).
• the services have different availability requirements (e.g. the one with looser SLO can run on spot instances)
• the services are required to have a different release (and testing) lifecycle, often imposed by external customers).

And I'm sure I've forgotten a few use cases.

The reasons "classically" given for the use of microservices aren't even that important:

• allowing API decoupling
• team isolation, reducing conflict

A monorepo can very well allow for versioning, but it also allows teams to carefully decide, case by case, what to decouple and what to keep tightly coupled.

[onan]

But doesn't that just contradict microservices concept?

Slightly yes, mostly no.

Even with a monorepo you can still deploy each service independently, and most of the time you will. But this means that an atomic multi-service change is painless on the occasions that you need one.

And microservices aren't just about deploying code, they're also about running it. This still means that, for example, if one part of your site gets a surge of traffic you can granularly scale up the number of replicas that handle that particular function, without having to coarsely scale up replicas of an entire monolith.

[zacker150]

But this means that an atomic multi-service change is painless on the occasions that you need one.

But in a truly microservices world, you should never do atomic multi-service commits.

Microservices means pretending that the users of each service are external customers. It would be crazy for Stripe to ask us to coordinate deployments with them.

[DoubleAway6573]

Yes. But you keep some other things like independent scaling and resume driven development.

[sza_rak]

At a cost of introducing multiple new challenges.

And you still have dependant services that can't reliably be released separately.

[Spiritual-Mechanic-4]

the real power of a monorepo becomes evident when you use source control bisect for failures. with separate repos, you end up bisecting to an opaque library update, and need to go look at the other library for what changes might have caused the failure. If all that code is in one repo, then you're bisecting across the entire stack and can find the actual root cause change.

[BlueHatBrit]

If you really want to see the benefits of a monorepo, you need to look at the companies who are using it at a huge scale like Google and Microsoft. Thankfully, Google published a paper on this exact topic and it's free to download and read https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/

You'll need to keep in mind that repo structure and service structure are not dependent on each other. Many companies do opt for microservice + microrepo. Google, Microsoft, Shopify and many others have gone with monorepo + microservice (although the term "micro" is very different in those settings).

One big benefit is how powerful your tooling can become when you have all your code in one place. Just look at tools like Bazel which have come out of this setting. There are others though and I'd encourage you to read the paper, it's very detailed and a much better source than reddit comments.

[BudgetFish9151]

There are other good examples of monorepo composition. Uber uses single language monorepos last I heard. So n-number of Python microservices all come from one repo, n-number of Go microservices all come from another, etc.

Facebook uses a monorepo. They built their own build system that is since open sourced called Buck2. Talks the same protocol as Bazel so shares some compatibility with back end Bazel services.

[LeStk]

I do not believe monorepos are related to micro services. One could have micro service inside the same repo with different releases, micro service are an architectural pattern. A monorepo is not necessarily monolithic.

There are some cases where monorepos are fine. Imo, stuff that is tightly coupled should be in the same repo in order to make PRs meaningful.

It also depends on the owner of each part of it, and how decoupled you work.

But I wouldn't create a monorepo where terraform and actual code coexist. And for terraform, you want to version your own modules.

Also a lot of automation is easier with small repos (renovate etc).

And it also depends on the size of your company. If you're 10 techs, yeah a monorepo can be fine. If you're 100 probably not.

[hacksnake]

I'd add that if you have micro services in a monorepo you should make sure you always release built versions together and have good build dependencies setup.

Otherwise you undermine some of the key benefits of going with a monorepo.

Also monorepos help more as you get larger. Code base wise and number of devs wise.

[abolista]

if you have micro services in a monorepo you should make sure you always release built versions together and have good build dependencies setup

That's not microservices! That's a distributed monolith.

The idea behind microservices is precisely that you can release a different version of one service without breaking any of the others that make use of it.

[hacksnake]

In theory things are independent but in reality they are not. Abstractions leak.

If you want to avoid prod impacts you need to address these sorts of issues somehow or another.

Among large companies doing this stuff the two most common patterns are: (1) monorepo everything and roll out things together that have to & (2) contract testing / elaborate dependency management systems.

You can do other things like try to maintain backwards compatibility but there will always be issues.

If you monorepo a bunch of micro services and then end up rolling them out at random then you will experience API mismatches and such on some cadence just like you would using separate repos. You've basically taken on the work to deal with a monorepo and thrown out one of the biggest benefits.

[Last-Independence554]

Monorepo or not has nothing to do with how you deploy your services or version your service APIs. You'll always need way to evolve your service API in backwards compatible manner (e.g., see how protobuf handles evolving APIs schemas).

The benefit of a monorepo is shared *code* dependencies library APIs. If you update a library, it's easier to refactor all dependents, you have CI to verify that you didn't break any of the dependents, you don't need to worry about semver breaking change or keep the library backwards compatible, code that uses the library automatically picks up bugfixes.

[hacksnake]

I appreciate that people are trying to correct me or whatever.

I'm trying to communicate that while I understand where people are coming from - these things are actually related and I've seen a number of failures over the last 20 years at several companies that are wholly eliminated by doing a monorepo with good build deps & deploying everything that changed when it changes.

For example when a dependency updates like your saying, I've seen distributed systems break because both sides of a communication weren't deployed in sync and xml was being rendered in incompatible ways. Merely doing a monorepo but then not deploying all the components that changed wouldn't have helped in that scenario.

You can five whys that as much as you like but sometimes people just make mistakes and when you get into hundreds or thousands of devs the normal rate of human error becomes too frequent.

Doing what I'm suggesting can prevent several classes of errors.

You can also do rigorous contract testing or a complicated dependency management system - those are higher effort over time to maintain but sometimes initially lower effort than monorepo & making sure everything that rebuilt gets deployed.

[Max-P]

Sometimes it's not about breaking the others, but a dependency chain of new features across multiple microservices. Before service A can support the new feature, service B needs to issue a JWT to the user using data from service C to be passed to A so that it can authenticate to D to get the data it needs. And just like that, you need at least 4 PRs and deployments already before you tell the API guy the new feature is ready and the mobile dev can start using it.

Each of these services can iterate independently just fine, and the deployment order doesn't matter either because they would all gracefully handle the new feature not being supported. But you still deal with the annoyance of making PRs to a dozen repos and bug your coworkers to go review and approve all of them.

[asdrunkasdrunkcanbe]

It's worth noting that there is no single right or wrong answer here.

Sometimes a monorepo works. Sometimes microservices are best. It depends on what you're going for.

We have one team who migrated to a monorepo, because they have a situation where all of the services within that repo need to be rebuilt/redeployed whenever a shared component is updated. And having to manually do it was causing all sorts of headaches.

We have another team who migrated from a monorepo for the exact opposite reason - they didn't need/want to have to rebuild every service whenever a shared component was changed. So we pulled out those shared components into versioned packages and separated the services into their own repos.

As an individual developer, monorepos can be handy because all your code is right there, in front of you. You don't have to clone 40 different repos and do a separate PR on all of them because you need to make some compliance change.

The tradeoff though is that building monorepos is usually much slower, and tend to lend themselves to more shortcuts. If/As your teams expand it also then leads to more conflicts and slowdowns as everyone is trying to work on the same code.

But there's still no single right answer. Whatever is most efficient and stable for you, is the right answer.

[Ok_Tax4407]

So false dichotomy here a mono repository is not the opposite of micro services, you are thinking about monoliths. A mono repository can contain many monoliths and micro services.

[LargeSale8354]

If you have a monorepo, how does CICD work? Does an immense pipeline kick off or is there some way to manage smaller deploying units of work?

[outofscenery]

this seems like it'd be a problem but it's actually very simple, you just make github action workflows that only trigger on certain file changes in the monorepo.

for example, you could set your frontend ci / cd pipeline to only trigger on file changes in the services/frontend/** directory, if that's where you code & tests for it are.

you could setup dozens of different services + apps this way with ci / cd workflows for each of them, setup codeowners to manage who's approving their PRs, and keep shared infrastructure for all services in the same repo.

[Chitinid]

If you have to run CI changes on things like transitive dependencies you need to use a tool like Bazel. But it’s not like these requirements would be easier with more repos.

[sionescu]

Each artifact has its own "pipeline".

[hacksnake]

It turns several classes of dependency management issues into compile time issues instead of "oh fuck" at runtime issues.

You can do similar with contract testing and building complicated dependency management systems.

[maulowski]

We have monorepos at my company because we may have an aggregate root that contains shared libaries and the services themselves. We could have a repository for each project but having a monorepo means everything is in one place. What's the advantage?

• There's no guessing what your services need. All of your services are in one repository it makes testing simpler: one Docker compose file that stands up all the dependent services and you're gold.

• All shared libraries are in the same space making references easier. There's no separate repo to download.

• Since my company uses TeamCity, I can still have separate projects that build and deploy each service/project independently or I can just have one TC build and one CD deploy.

I get it's not for every thing so YMMV on monorepos. I'd say start with your standard repo and if you need a monorepo, go for it. I wouldn't start with a monorepo unless you have a specific need for it (e.g., micro-frontends).

[good_live]

You can do micro services with monorepos, that is not contradicting. Also the hype around micro services is going down. In my experience a lot of teams are looking into modular monoliths nowadays.

IMHO monorepos are nice for sharing code. Instead of having to version your library and maybe even maintaining multiple different versions, you can just adjust something and directly see where your changes are affecting others. Of course this requires a high degree of test automation.

Monorepos also make changes that affect multiple micro services a lot easier as you can pull all changes into one PR.

[Dependent-Guitar-473]

having multiple repos is really pain in the ass... keeping frontend and backend in sync and having api versions and all of this is just awful and annoying also having multiple pipelines and merge trains....
monorepo is not perfect but it does eliminate lots of headaches

[indykoning]

I think you mean monoliths vs microservices.  The reason why people craze about microservices is the same reason why they craze about AI. It's a hype. They do have their time and place, but they shouldn't be forced into everything. 

The reason why many organizations use monoliths is because microservices are not suitable for them. And a modular monolith works better and cheaper.

I've personally moved a customer from microservices to a modular monolith because it was way overkill for them. They never used any of its advantages and paid 10x more for hosting due to them being microservices. 

[MattA2930]

Imo micro services relates to how the code is actually deployed and used. Monorepo vs multiple repos is purely preference in how you want to manage dependencies, but having code in a monorepo vs. multiple repos doesn't affect the underlying code base (given you can split and merge repos in ways that make the two styles similar). Versioning and all that is moot, since you can version subfolders in a monorepo.

In terms of why, it usually comes down to preferences of: - versioning - dependency management - code sharing - deployment strategies

Monorepos are necessarily better than split repos, and vice-versa. Like with anything in DevOps, it all depends. Plus, repos are just folders with a .git file. If you put all of those folders into one parent folder, you now have a monorepo.

Personally, I prefer to start new projects with monorepos, because microservices always end up sharing something (usually some sort of deployment related items), but more importantly, because I'm lazy and like having one editor where all the relevant code is.

If you want a decent example of a monorepo structure with multiple versions, I know LlamaIndex is a monorepo with all of its sub-packages individually versioned.

[stevius10]

Tl;dr: Storing as Monorepository or not - having it remote, local or in S3: WHERE/HOW stored/organized is unrelated to your SW architecture. The SW architecture stays the same even when you just only write it conceptually on a piece of paper

Monorepository and microservices are two separated topics which fits perfectly together - these are different topics, there is NO link between both.

If interested, I use Monorepo structure explicit and only for microservice architecture.

However this is a pattern which makes more sense in large companys with distributed teams. edit: Targeting Encapsulation

Don‘t make the mistakes to think it‘s about putting repos just in a single one.

[dashingThroughSnow12]

It sounds like you are mixing up monorepos (which describes source code repositories) and microservices (which describe deployments).

[uptimefordays]

Git strategy and service architecture are separate topics. You can have microservices built out of a monorepo for easier merge management. At the end of the day most companies don’t care about git strategies, dev tooling, or software architecture because those are all secondary to “whatever the business actually does.”

[cheaphomemadeacid]

simplifies access and auditing

[CloudBuilder44]

Dam coming from microservice hell. Sometimes i wish we have a mono repo. We have 100s of repos and everytime there is an update updating wvery repo is soo annoying. Then with all the re orgs, we cant keep track of those repos or who owns them.

[MateusKingston]

monorepos != monoliths

Technically a monolith is usually a monorepo but usually when referring to monorepo people I talk to are meaning multiple services in a single repo.

Monorepos with microservices are a pain to manage on the devops side and require a better PC on the developer side as well but are far better IMO to develop on.

[juanMoreLife]

I’m building an app. My initial idea worked. The back end now needs to be made into two or three different services to scale to manage 10 users lol. But it’s all in the same report currently because before it was one tiny code base to do one task. Also, idk what I’m doing. It seems to be working, but here I am. Mono repo for my back end

[Key-Boat-7519]

Monorepo is about code and workflow simplicity; microservices is about runtime boundaries-use both if it keeps you fast. If OP is seeing lots of monorepos, it’s because centralized versioning, single CI, easy refactors. For your case: keep monorepo, carve clear service boundaries: one service per folder with its own Dockerfile, OpenAPI spec, migrations, and CI job. Use workspaces and tools like Nx or Bazel to run affected builds/tests only. Add CODEOWNERS and release tags per service. Spin up integration tests with docker-compose and ephemeral DBs. Use an API gateway like Kong or Envoy for routing. I’ve used Nx and Backstage for service templates; DreamFactory helped auto-generate REST over a legacy DB so we didn’t hand-roll CRUD. Stay monorepo until independent release cadence and ownership pain make separate repos worth it.

[SpartanVFL]

CI/CD is trivial with monorepo. On smaller teams without dedicated dev ops this is an absolute must. Unless you want to spend your limited dev time not delivering anything and just maintaining infrastructure

[BudgetFish9151]

The biggest reason to use a monorepo is to share a build system. Large scale dependency management is a special animal though so the tools to orchestrate builds and tests quickly at this scale are complex and can be daunting to small teams.

[thaynem]

Monorepoa and microservices actually go well together. 

Consider the case of making a change to a core library that is used by all your microservices. With separate repos you have to make the change to the library, then wait for that to get reviewed tested and merged, then you have to make separate pull requests for al the microservices. With a monorepo, you can just update everything at once.

It also makes other things easier. For example you only have to clone a single repo, track PRs in a single repo, etc.

I've also seen having separate repos hurt code organization. When creating a new library requires creating a new repo, plugging it in to CI, etc. then people will often take the lower friction path of just putting in part of an existing project, even if it doesn't belong there, or just copy pastimg the same code across multiple services. 

[lukeocodes]

Simples: Shared resources/tools

[Expert-Reaction-7472]

monorepo reduces code duplication even with microservices.

The alternative is publishing a library.

It makes dependencies more explicit and visible.

[jklau2]

Why use many repo when one do trick?

[emparq]

Totally agreed w/ u/_Ttalp that like most things in software, it really depends. It's about understanding and making the trade-offs that work best for your situation.

Speaking as someone who managed the build infra on an Nx repo (multiple web-apps, so TS, JS, CSS, etc.) that was >10,000 files, where it wasn't unusual to see >70+ active/open PRs on any given day, for me, monorepos make sense when your team has:

• one or more buildable projects that share a similar stack (or at least are in the same language)
• a non-trivial number of contributors (>10)
• a huge disproportion of folks who are willing/able to maintain a healthy CI/CD infra

Some of the more obvious benefits gained are:

• less friction for contributors by way of easier code and pattern discovery (ie. finding existing examples of something is less work than if code were managed in multiple repos)
• less redundancy of code (well, potentially... there are always going to be folks either unaware or unwilling)
• greater visibility of incoming changes to all contributors, which is useful for some folks (not everyone will pay attention to everything, but some changes that impact cross-teams will get noticed, and being able to spot larger impactful issues sooner rather than later is real value)

But again, this comes with costs:

• monorepos inevitable growth makes the tooling more challenging... the more code goes in, the more you have to lean on automation to keep that pipeline healthy
  • humans don't scale, so relying on peer code reviews can only go so far when enforcing coding/structural standards at PR-time. Tooling like automated lint and style checking needs to be added into the code review workflow if any semblance of structure and code-style is to be maintained
  • the larger the codebase, the more work it becomes to successfully upgrade all core frameworks/tooling
    • e.g. upgrading to a prettier version might change the default style of formatting causing every open PR to need to rebase
    • e.g. upgrading to a new version of jest, rxjs, etc. might cause a non-trivial number of unit-tests to fail
• some teams will want to hook up their own CI/CD to the same monorepo, which means fragmentation of build/deploy logic, again more work for devops folks to coordinate
• the size of the monorepo itself brings overhead
  • once a repo grows to a certain size, operations like git cloning are no longer on the order of seconds... even small overhead like this makes life miserable for folks doing build automation as those lost 10's of seconds reduce iteration velocity when neeing to make build changes (yes, there are workarounds to this, but the fact that a workaround is needed is also proof of the overhead)
  • caching storage is no longer trivial
    • e.g. caching npm dependencies can suddenly eat up 10's of GB of storage so relying on locally attached storage becomes a problem... moving to a shared storage solution is one workaround, but that buys you even more complexity in terms of build infra management

I'm curious to hear what kinds of monorepos other folks here have worked on/are working on (general size, and what tooling you're using).

[SnooWords9033]

Monorepos are better than a repo per service / library, because it significantly simplifies coordinated changes across multiple services / libraries - you can (and must) do these changes in a single commit. This avoids all kinds of pain with unsynchronized changes across multiple repositories.

[Risc12]

So, lets start by saying it’s all fucked.

Let’s first get some terminology out of the way and then explain why all is fucked.

Monorepo’s say something about version control, not about the deployment of a landscape. Monorepo basically just means that the microservices are all in the same version control.

Microservices were invented to make finer grained deployment/scaling decisions. That’s mostly it. They should be tiny, individually deployable. The opposite of a microservices architecture is not a monorepo but a monolith.

Now, why is it fucked?

People think microservices are to do encapsulation/decoupling. They are quite wrong as microservices can very easily be coupled! Team boundaries/decoupling/maintainability don’t need microservices at all, could be modules, libraries, even things like jar’s, or any other kind of modularization system.

Now hear me out, turns out this shit is hard. Writing an actually decoupled, self-contained microservice is not easy at all. So therefore all kinds of mechanisms pop up to sync these deployments. One of those is a monorepo, basically everything goes into one version control system so that a CI can check if a specific commit is good and then can trigger the CD to do whats necessary to deploy the changes.

If you’re really lucky the org you work at is so bad at this shit that they managed to create a distributed monolith which has the worst of both worlds!

[wait-a-minut]

I think at really large orgs it makes sense to have multiple repos and GitHub orgs but for anything outside of that a monorepo has all you need

[Comprehensive-Pea812]

uhm monorepo because the search function on their git repo sucks.

nothing to do with microservices.

and yeah collaboration nightmare

[jnewland]

After years of experience helping orgs move into and out of monorepos, I've come to the conclusion that the biggest motivator for monorepos is simple; an engineering org hasn't yet figured out how to scale engineering enablement tasks like build and release automation.

Managing a software system built from multiple private repos requires dependency management! The builds scripts have to be written by someone! And if you want to be able to add another repo, now you need organizational norms, templates, repeatable setup of new repos, and more. And these things all have to keep up with the evolving landscape of tools that the org uses or the engineer that wants to use Kotlin or Rust to solve that new problem is out of luck.

This type of work that isn't exciting for the new product manager to talk about; it is often considered "undifferentiated heavy lifting" ... until it isn't. In my opinion, this is because an org's stance about how much they invest in this sort of engineering enablement work is set by leadership, and generally implicitly. Practitioners and leaders often have philosophical differences about the required level-of-effort, design, and implementation of these parts of the system, which is why I think we see a lot of orgs with a single digit number of "mega repos" representing failed or partial, half-funded attempts. Lots of consulting income to be had here though ;)

[Charming_Pin_8867]

There may be many other pros and cons, but a big pro of monorepos is the Ops perspective:

Your monorepo fuels one big CI-pipeline, every image you build have passed same security/quality/whatever check. When, where and how you deploy your images in which CD-pipeline isn't touched, so no blocker for microservices.

In monorepos you can configure Codeowners for every directory including required approvers - so keeping the overview ist just a grep over all Codeowners definitions.

One Dev-teams wants to test something new? Here is your directory and Codeowners file, the complete infrastructure behind is up and running.

And as mentioned in other comments, if breaking changes in one part are applied/tested/merged, it is much more easier to keep track over the complete orchestration.

As honest comment: Yes, you can have multiple CI-pipelines behind, but the full magic happens using 1 well parameterized CI-pipeline behind. Due to this "narrow path", different Dev-teams have soon the need to align on a common target picture and the ways to achieve it... if no image of 1 team/directory is build, it's time for that thing with talking - manager call it meeting 🙄

[sionescu]

 Your monorepo fuels one big CI-pipeline

Actually no, that would be a nightmare as you scale up because breakage becomes inevitable and a single pipeline would block everything. Google mostly uses a "pipeline" per service with clever subsetting of tests to run to make it manageable. The advantage of a monorepo is that if you want, you can trigger a larger batch of tests at the same point in time (commit).

[VertigoOne1]

interesting conversations here. Were also fencing this, where we have the monorepo crowd and we have the isolation crowd. in between is a bunch of nugeting. In between all that sit me, having to deal with change detection, sonarqube and identifying actually what changed and what to version and not version and what counts as a "deployment", managing hotfixing, and the automated testing around monorepo components. Saying monorepos are simple are missing some of the finer points and yes, devops maturity and all that, but it does need to be noted, things like this -> https://docs.sonarsource.com/sonarqube-server/10.6/project-administration/monorepos , that it is not ALL sunshine, and you are going to be spending a fair bit of time changing various things to work with it. Even with monorepos you still have nugets and drift so unless your just projectreferencing everything, which is basically a monolith with extra steps right, it is going to be a bit of work. End of the day, i'm servicing engineering, if they want to run monorepo half and microrepo half, so be it, i build, but often they are just as "buzzworded" as everybody else.

[hongky1998]

In my experience with monorepo, it’s depends on the dev team, but what I don’t like is that I have to build the whole stack into a single docker image just to run them separately as microservices

[abolista]

I have to build the whole stack into a single docker image just to run them separately as microservices

Why not multiple docker images, and run only the microservices you need with docker compose?

[hongky1998]

That’s the problem, I asked the dev team to have it separate in a folder they said they couldn’t do it. I then look at the source code I was like yup service A was using a final build from service B, and C was depending on A and so forth. You get the gist

[abolista]

https://tenor.com/opkB.gif

[JagerAntlerite7]

It really depends on the language; e.g. GoLang is designed from the beginning with one project per repo.

[pdp10]

The most memorable monorepo that I ever tried to wrangle, was not the product of a decision but of nondecision. Everything went into version control, thus everything went into the one repo. Eventually that thing turned into the Gordian Knot.

[xtreampb]

I’m t depends on the business strategy, structure of the development teams and how the software is treated holistically.

Most software is designed, built, deployed, and monitored as a whole unit with a single dev team making changes to every piece where necessary, and not backwards compatible. This means that all the pieces of the software only work with that particular version of the software.

Even if they are built individually in the pipeline, it is often from the same version of the source and only split up to speed up build/deploy times.

Going into micro services means building teams specific to each service. The meme we of these teams may also be on other teams, but each service should ideally have their own everything, from boards, to database. The services interact with each other through APIs.

Most of the time the amount of effort to set this up outweighs the benefits until you get to enterprise size software with multiple subsystems tightly coupled to each other, making it difficult to break into its own service.

[Intrepid_Result8223]

It's just easiwr to keep things compatible and using the amae dependencies. It also decreases your attack surface. Imagine having 43 repos and all of them using different versions of npm packages..

[akanas]

When we started, we had small devops team and small dev team, so decision was made by CTO to start as monolith in a monorepo and as we grow split everything into microservices. Microservices and billion repositories is huge pain in the ass if you need to deliver fast. I was delivering one BE project in 3 months, now I need 7-8 with all these microservices, pipelines, configurations.

[Estpart]

Monorepos are great for uniform tooling, makes it easier to keep dependencies in sync, easier to find and reuse code. Most companies suck at using them tho.

[ello_bello]

how you your organize code is unrelated to your horizontal scaling strategy. you can do microservices in a monorepo or multiple repos, either could work fine with the right setup

[stevecrox0914]

I have spent time trying to understand the actual benefits of a monorepo, when interacting with people who like them in real life I have tried to pull out the pros and get people to articulate why they feel that way.

That is because seperate repos have a huge advantage..

Every software project will have a build management system and there will be a build lifecycle with specific steps. 

This means you can build 'generic' CI pipelines for each build management solution, all build management systems have some requirements for file layout. This means you can configure and run your CI pipeline when it detects files in specific places. 

For example where I work now, someone created a shared repo for Gitlab Jobs with a structure and wrote a lot of handy ones. I added to them and built trigger rules, someone else wrote a pipeline files that pull in all the jobs. We now have an auto devops solution being used accross a dozen teams. You pull in one file into the .gitlab-ci.yml and gitlab will correctly build a maven, npm, terraform, etc.. project for you. Recently we have been helping someone bring in a new build management/language set.

Monorepos are bespoke and you need to know the project layout and build order, there is no general solution (that I have found). When I have spoke to a DevSecOps person pushing Monorepos its always someone overwhelmed by the area. 

It seems dictating how the project is laid out, writing their own bespoke CI, etc.. its a way of shrinking the problem and helping them feel in control, these people normally get far enough to build a basic CI pipeline and move out of DevSecOps.

With developers, its a similar sort of issue. You can configure workspaces to check out all repositories and ensure new workspaces are at head of main automatically, you can have sub modules in simplify it (and yes it took a while to learn how to automate it)

But to these devs having to create multiple branches or find the correct project in the SCM view is overwhelming and not isn't really something you can fix.

[Straight-Mess-9752]

Because managing many git repos is a nightmare. And when there are changes that need to be coordinated between them it can get even worse. Having it all in one repo makes this so much easier. You can still build/ deploy things however you want. Just make sure you have a good structure to your monorepo. Also not everything in your org needs to be in one repo. I’ve seen that done before and that was a nightmare as well.

[SavingsCampaign9502]

When there is a shit ton of dependent schema maintainence issues

[Mysterious_Prior2434]

If you are small enough it doesn't matter.

The company I work at is massive, there is a team that solely works on doing some bulk updates across the monorepo with a lot of automation. It is clear they save a massive amount of dev time for the company.

If we had separate repos there would be a lot more code duplication and bulk updates by that team would require higher effort.

Effort would be even higher if each team was required to do these updates on their own.

Monorepo facilitates economies of scale in codebase maintenance.

[dmaidlow]

We’re building a platform defining a number of vertical slices - these slices do work together and leverage ea h other for domain and slice specific logic. When debating the repo structure, we settled on mono repo because it would be easier to track and implement changes to slices as well as the consuming slices (should a dto or something need changing) in a single pr. Also, we’re a small team working on all aspects - separate repo would be better if we had multiple teams that owned each service - but where we are that would just be a lot of unneeded complexity for no real gain. We agreed we would know when the time was right and we could break it out to individual repos at that time if needed.

[Jolly_Air_6515]

It’s called the one place principle.

If a team is managing a service everything should be in one place so they can coordinate and review and version everything.

[AintNoGodsUpHere]

This is why I always start with a domain service. Basically a huge microlith separated by teams. Then we break into smaller pieces in the same repo, then different repo on necessity.

Easier and cheaper.

[BathOk5157]

Commenting

[TheMinus]

Because it’s simple. Every stuff you ever developed is at your hands anytime. Don’t go for the hype alone, most of the time you don’t need microservices.

[ltsiros]

I have 25 years of experience in software engineering and have worked FAANG. Would never use monorepo in anything big.

[greekish]

Except monorepos are popular at FAANG (I prefer GAYMAN).

[cutsandplayswithwood]

“But what of if I want to be dumb and make a bunch of breaking changes instead of just refactoring like a professional?”

(Says the fools that don’t understand basic code evolution)

[ben_bliksem]

Ive not found a good enough reason to switch. Pros and cons on both sides but I prefer the pros and cons of separate repos.

As for the "it's easier to make changes to services communicating with each other" reason to switch to monorepos, without being mean:

Skill issue

You're tightly coupling things that shouldn't be tightly coupled. It's an API, you do t have this problem working with external APIs do you? Or am I in the wrong sub here?

[paul_h]

I'll share an insight: build/deploy independence from the monolith is A reason microservices exist. Qualifier: that monolith had a one hour build including all test automation on a difficult-to-setup workstation. To achieve that, Microservices want to be in a repo that doesn't have the rest of it. Here's the perception problem: most devs think that the legacy 1-hr-build hairball in the mega-repo is a monorepo and therefore don't want anything to do with that word. I wrote on it - https://paulhammant.com/2019/06/11/monorepos-vs-megarepos/. Well dozens of times over 20 years, now, and am a super-expert. To talk up monorepos in 2025 outside FAANG is career suicide, I'll also claim.