The speaker discusses the concept of monorepos and their comparison with traditional repository structures like Poly repos. The speaker shares personal experiences and initial thoughts on monorepos, highlighting their potential benefits such as reduced management overhead and simplified CI/CD processes. Pros and cons of both monorepos and Poly repos are outlined, including considerations such as scalability and security. The transcript concludes with a discussion on team preferences and the importance of making informed decisions based on specific needs, as well as a call-to-action regarding the Snowpal platform and app. Overall, it offers insights into the considerations surrounding repository management and encourages exploring different approaches to find the best fit.
Summary
Introduction to Monorepos:
- Brief introduction to monorepos.
- Personal experience and initial thoughts on monorepos.
- Definition and comparison with traditional repository structures (Poly repos).
- Mention of hybrid repos and the possibility of combining both approaches.
Pros of Monorepos:
- Reduced management overhead with multiple services.
- Simplified continuous integration and deployment (CI/CD) process.
- Facilitates onboarding new developers by providing an overview of the entire ecosystem.
Pros of Poly Repos:
- Emphasis on separation of concerns.
- Security advantages in terms of access control.
- Scalability considerations regarding repository size and performance.
Conclusion:
- Discussion on team preferences, biases, and decision-making.
- Mention of hybrid repos as a potential solution.
- Encouragement to explore options and make informed decisions based on specific needs.
- Final remarks and call-to-action regarding Snowpal platform and app.
Podcast
Check out on Spotify.
Transcript
0:02
Hey there, let's talk about monorepos. You've probably seen me do these tech videos. It's not to say that I know a lot about what I'm talking about. Actually, to be honest, more often than not I don't.
0:18
But I still want to share. I'd like to share what I do and don't know in the hope that it's going to help you solve your problems a little bit quicker. So you've probably heard of monorepos. I've never used one or used that approach in the past.
0:35
I love to keep my repositories separated, so I don't believe I've ever... I always say "ever," rarely ever knowingly worked on a monorepo. So every time I want to do something, my default, my natural preference is to create a new repository.
0:53
Language agnostic. It doesn't matter. Whether I'm working on two or three Node.js repos or three Ruby repos. It doesn't matter what they are. I still like to keep them separated. That's my natural inclination, the way I've done things, prefer to do them in the past, but of late.
1:11
I've seen the use of monorepos. They've been around for a while as I understand, but they're maybe... they are getting more popular one more time possibly, right? So let's talk a little bit about monorepos and at least my initial thoughts on that.
1:29
The first thing is, you know, for those of you who may or may not know what it is, it's simply saying that if you want to solve, let's say you're building like 10 different microservices or applications or whatever it is that you're building, you can choose to create a separate git repository for each one of them or which is a traditional, right?
1:47
I think it's called a Polyrepo. Or you could create 1 repo and create your directory structure such that it supports all of these microservices or the applications, right? So there's one place for you to go. Now let's take a simple example, right?
2:04
Let's say you're building a UI application and API application, maybe a middle-tier service. You could choose to have three different repos, which is what I would have done. But you can also choose to make them part of the same repository, and by virtue of doing that, that repo becomes a monorepo.
2:24
Now there's pros and cons, just like with everything else. And there's one more thing, actually, there's also a hybrid repo, as I believe it's called. You can have a combination of Polyrepos and monorepos. So it's not all or nothing. So you may want to be consistent and go one way or the other.
2:42
But as a team and the company grows, it's sometimes you don't want to kill an interest of consistency, right? So you may want to have a combination of these. So let's say you go with the... sorry, monorepo. Let's see what are some of the pros? I personally again haven't used them, but here's what I think the pros might be.
3:03
One is as you build more services, there's going to be a proliferation of repositories, so there's a cost of managing them. Now if you have a larger team, people dedicated to doing these things, some of these may not matter as much. But if you're a smallish company, you have to do the additional bit of work to managing these repos.
3:22
So as we have, like at Snowpal, we have quite a number of repos, some that are directly relevant to our apps, mobile or web or API in production and others that are in some phase of development or some test repos and whatnot, right?
3:39
So we have a number of them. It does take me a decent amount of time. Not every day, not on a weekly basis, but I do have spent a good amount of time in managing them. Now if we had gone the monorepo route, that would have saved me time right there, right?
3:55
So that's the positive, that's the first pro. There's others, right? In terms of continuous integration and deployment, well, you can obviously get it working in both cases. But from what I'm reading, there are some positives that the monorepos bring to the table and maybe it's not a pro or a con, maybe it's right smack in between because you have to kind of define your CI/CD classes so it supports a notion of these monorepos.
4:27
So the second variation to having a Polyrepo versus a monorepo is essentially, sorry, continuous integration and deployment, right?
4:44
So those are two items. Let's continue here. So we talked about two pros of monorepos. The third one that I can think of is as you onboard new developers into your team, either they're joining your company or they're switching between teams.
5:04
Because you know these days you want all of your dev team to be generally polyglot and flexible so they can work on different languages and frameworks and different applications almost at the same time. That's the nature of the beast, right? So I think I personally feel like the gone are the days where you could just be a Java developer or Ruby developer and do just that.
5:24
I'm sure you can still do just that, but I wouldn't do it right. That's what I feel. So as you onboard new members, team members, either into your company or into the particular team, it will help for them to get an overall picture, like a high-level overview of the suite of applications that that part of the ecosystem, that part of your ecosystem comprises of.
5:49
Now you may have like hundreds of repos, right? And if you're a large company, maybe even thousands, I don't know. But I still feel there's a grouping of these repositories. So you want to group related repos into a monorepo, essentially by putting them all, making them part of the same repository.
6:09
It is actually going to make onboarding certainly one step easier than it might otherwise be, right? So that I see is another positive that monorepos actually bring to the table. Okay, let's talk about pros of Polyrepos where you have a separate repository for every service Oregon application that you're working on.
6:36
That's been 95 plus percent of my experience and I like the separation of concerns, right. So I know they're separate. Yeah, there is a maintenance headache and overhead that comes to the table. But beyond that, I think it's... it's cleaner, quote, unquote, right?
6:53
It's like each repo has its own... it's solving a particular problem from a deployment standpoint, from a business standpoint, from an architecture
standpoint, it's completely separate from the other. It almost has no knowledge on the surface right now they your services are most likely going to integrate with each other, so they will have knowledge about the other repos.
7:18
But what, I mean by they don't have that. What I meant by what I said earlier was as a developer who's cloning one of the repos, you can choose to, at least by default, keep your focus on that, on just that singular repository and not worry about everything else that it integrates with.
7:36
Plus you know the other Pro is it's it'll also be smaller relatively. So when you have 10 repos that a single if a if a owner repo comprises of 10 different repos, obviously a code base is going to get pretty large there, the size of the repo.
7:54
And then if I have a feeling maybe if it's 10/20/50, whatever, there must be a number at which point cloning it and managing it is going to actually get slower. I don't know, but that would be my hunch that you know there's bound to be a point at beyond which it's probably not going to scale naturally, but maybe that's maybe that's a good problem to have.
8:18
That means you're growing as a company, but it also might mean that it's one of those 80-20 cases, maybe it doesn't happen to 80% of the of the developer base there, right, Because we don't maybe work with that number of repos, other repos of that size necessarily energy working for one of these big tech companies which I'm sure have like thousands of people.
8:40
So that's that's the other thing, right. What is in terms of, I mentioned separation of concerns. The other pro of Polyrepo which becomes a direct con of a monorepo is as you onboard members.
8:56
I mentioned that it's easy for them to get an overview because it's all in one place. The problem is also that now you're going to, from a security standpoint, you're going to have to share all of that with everybody. Now what if you want to keep your team separated? What if different teams are working on different repos and you don't want them to actually have access to the other code bases?
9:19
Well, too bad. If you go down the monorepo route, you're obviously not going to be able to support that. So your dev team, the developers are going to get it's all or nothing, right? Which directly, which in itself will not work for us given the way we function at Snowpal.
9:36
So we want to... we like to maintain that level of those levels of separation. So that's what you'll have to make sure that that works for you. Or like I said earlier, you got many repos, 10s of repos and you find the group of repos that make the most sense to be part of this or a monorepo, right.
9:57
But remember that these repos actually have to have nothing to do with each other. They could be web apps, mobile apps, API repos, integration layers. It doesn't matter what it is, you could have 10 different or 10 disparate repositories that are all part of that monorepo.
10:15
So how do you want to do it is completely entirely left to you and your team and what works best for you. But, you know, make sure you give this a thought and you might lean in One Direction or the other naturally. And then you ask yourself, hey, do I want to do it the other way? Because we all have our biases and preferences and we are.
10:35
I don't think we'll be limited by that, but it's going to drive a lot of your decisions, right? Sorry. So I'm sure I missed a ton of other pros and cons, but hopefully this gives you the idea.
10:52
I don't know if you have any questions, just hit me up and tell me if one worked for you better than the other, or if you're a company or a team that actually uses the notion of hybrid repos where you have some Poly and some hono repos, which I feel like might actually be the best solution, right?
11:09
There's never a silver bullet, so you want to pick the best and maybe there are some cases where one might serve you better than the other. That's essentially it. And before I end the video, remember to sign up if you haven't already done so, on snowpal.com and manage your projects better, whether it's projects at home, at work, school, college, if you're making any travel plans for the summer, you can do it just about everything.
11:36
Just do it in a more structured manner and the platform gives you those options and features. And download the app from the Play Store and App Store. Have a good weekend.
Thanks.
Top comments (0)