Podcast | Episode Four : Monorepo

The move from Monolithic applications to MicroServices often leads to many repositories; one repository for each service. Handling many repositories leads to complexity and may slow down our development process as we handle changes (pull requests) that touch multiple repos … resulting in even more complexities and errors. 

So, which one is better? Should you keep everything together in one repository? Or should you divide up into multiple repositories? Monorepo == Monolith? Why did Google, Facebook , Twitter move to Monorepo ?

In this podcast Dor Atias and Alex Molev discuss the pros and cons of using Mono Repo vs Many Repo. Dor also shares his previous experience at BlazeMeter as well as his current experience with his new security startup Cycode – Listen now! 



Additional Resources:


Guys welcome to a very special edition of our Tech Talk Cloudify podcast. Today, we have some very special guests and we are going to be talking about all things mana repo. So without further ado I’m going to hand it over this week to Nati Shalom our co-founder and CTO to discuss a bit more about the layout and introduce our guest speakers today.

Thanks so much, Jonny. So my name is Nati Shalom for those who are visiting the podcast in the first time with Alex and Dor Atias. Alex and Dor I’ll let you introduce yourself; Alex why don’t you start?

Hey I’m Alex Molev – I’m Head of R&D at Cloudify.

So Alex is a regular guest in this podcast and hopefully Dor will be joining us as a regular guest speaker as well. Dor, you’re new to this podcast, I’ll let you kind of do a longer introduction. So go ahead.

Thank you, Nati and hi guys. My name is Dor Atias. I’m the VP RND of a company called Cycode. Basically Cycode is the first and unique platform of protecting your source code in the cloud and also on premise. Before Cycode I was five years in BlazeMeter, a company that was acquired by CA technologies and I was backing developer, then I was promoted to R and D manager and then to R and D group manager. In these years I was focused mainly on back end engineering and DevOps engineering. So I have a lot of experience of DevOps and cloud and SAAS areas. Before BlazeMeter, I was four years and a half on the intelligence as an officer there also a software developer and that’s it glad to be here?

Dor, you you’ve been in writing the patent, I think on some of the relevant area. Why don’t you say a few words about that as well? I think that’s also interesting that part of the background.

About the DevOps area?

You wrote a patent if I recall correctly on the options of doing the development. If I recall correctly, I don’t remember the exact name of the patent that I’ve seen you posting on LinkedIn.

Oh, the patent. Okay. Yes. Basically BlazeMeter is a SAAS company that provides load testing platform. Basically you can load test your platform from various countries in the world and in some point of the start-up and we started to work with banks and financial companies that said to us, hey, we want to use your BlazeMeter and we want to use your capabilities of the load testing platform, but we can’t allow our data will be on the cloud. We trust you, but we can’t allow it. We have regulations and all kinds of stuff. So we want to use BlazeMeter as an on premise tool and we as BlazeMeter decided not to go to this path because we didn’t want to have our SAAS version and also on premise version for every customer that wants on premise version. So what we did is to have like an average solutions that we have a patent on it and the idea behind is to combine these two ideas, the on premise and the cloud and basically to give the customer the SAAS versions, but all the business logic and all the heavy lifting is behind the firewall in their premises. So you get best of two worlds. We keep the data in your premises and also we give you the advantages of using SAAS, quick releases, quick back fixes, and a lot of cool features that SAAS brings if it’s an enterprise features like adding users, connecting to single sign on all kinds of these things, we are delivering these features, every sprint and all you need to do is to give us one or two machines to keep the data on your premises.

Excellent. Why don’t you say a few words about where you’re working right now? I know that you’ve switch from performance testing to security. I know that with that word security, you probably can’t see everything, but at least give the audience some hints.

Yeah. So before Cycode, as I said [Inaudible 05:17] or testing tool, and before BlazeMeter, I was in the intelligence and in intelligence, I did some security missions, let’s call it that and after the army I wanted to go to another thing, not security, not cyber. So I went to BlazeMeter and it was a great decision. I learned a lot on BlazeMeter; after I did my service, let’s say five years on BlazeMeter I wanted to go to security because after the army security field was a change and was extended to a lot of areas. So I wanted to go back to what I liked and what I did in the past and today I joined Cycode, the start-up. It was founded by two founders. They all live in a [Inaudible 06:11] in September 19 and I joined five months ago and the beauty of Cycode is that it’s not only a security product, a cyber security product. It’s also a DevOps and SAAS product. I mean it’s all the areas I love. It’s DevOps, SAAS, cloud, and security altogether and that’s why I decided to join Cycode and that’s it I think.

Excellent background. So I think that kind of explains what we’re about to discuss here today. The topic is it’s called modern repos, for those who are less familiar it’s basically the question is whether we using and breaking the project into different repos within a regular social project, like in gate, or are you using a single repo where you put the entire source code in one report. There’s the differences between the approaches. I would say that large companies have built their R and D structure or their software project in a single repo to name a few [Inaudible 07:23] who’s been doing work around that and also Twitter and Facebook, so the term modern repo becoming kind of a hot topic these days and maybe Alex, you can start with introducing the topic to the audience here. What’s the background around it and a door you can add to that there?

Okay. So what you’re looking at usually has not Monorepo versus [Inaudible 07:56] and a topic actually became a really hot once it was starting to see architecture more and more moving from a [Inaudible 08:08] to microservices. By default, so many companies started to work with the microservices that for each microservice had the indicated the repo and as an application or that format development grow, as a side effect, what happens is that more and more repositories are added there for each microservice. There were some really main issues that companies try to avoid. So now where each developer, if I have a 5,100 and different microservices, what does it mean? Does it mean that each developer now has to go through each one of the repos and the cloning inside his or her laptop and how the collaboration is done, what does it mean? They don’t keep the changes. And the new hybrid actually was born that what it provides to do is to have a wonderful story that it has the oldest services and each service represented by a sub folder in it and so what it provides actually it gives you the one comment actually to have the entire development on your laptop and it’s really great. It provides a really great key benefits.

Now I’d say, as I mentioned, super simple for employees to get access to everything, it’s easier to collaborate. If you have for example [Inaudible 10:01] that it combines multi-microservices, for example, one microservice expose and bind to another, you actually consumes it. It’s very easy to have a one bullet press that combines everything. So you’re for sure that once someone does a contract, it has all the details to cover everything. As I’ve mentioned more and more big companies like to Google, Facebook, Twitter started using it because it’s a great, it has many benefits, but with all this in place, I think the important part is not to use it as a golden hammer rule and try to solve everything. With each shared technology there is pros and cons and of course some cons, some side effects come with it.

So maybe that would be a good point for Dor to cover. Dor, why wouldn’t they use it, of the disadvantage of using it?

So one of the disadvantages of using a one repo is that everyone has access to everything. If you have more than a, I dunno, for example, in Cycode, we have a lot of microservices. So all the R and D as an access to all these microservices, I can’t do any access limitation for the developers. I mean, one developers would have for these microservice for this project and the other one won’t have access. So this is one, of the disadvantages. Second thing is that most of the [Inaudible 12:01] tools we have currently, for example, data actions or secrecy, doesn’t have native support of Monorepo. Let’s take [Inaudible 12:13] for example. So [Inaudible 12:14] has one config file that you can upload and in this file you’re basically saying, what are the jobs you want to do, what you want to be, what do you want to deploy and it has to be on one file. So imagine you have like one repo with 20 microservices and every microservice as his own workflow, you have one file with a lot of lines and you can’t maintain it for a long period of time.

So if you want to do small thing, you need to know all the structure of the file and instead of going to multiple repositories that each repository has his own config file or workflow flight file that you know when you can play with and you can edit and you can be sure that you are not doing mistakes. You are not affecting other pipelines in your building or deploying process and that’s the main two disadvantages.

So let’s summarize it basically what you’re saying is that the reason they kind of the control like security control aspect, how do you control which user has access to which files, which are kind of built with repose, but when you go into mono repo, you kind of have to deal with it yourself and the other point that I think you’ve touched on just now is really helpful. You get to the point where the tooling around it can support that type of segmentations of the project, which they used to also be structured around repose and the question becomes, how do you go about that? And you mentioned secret CI, which the limit of even a single file means that if you want to probably be on a single microservice within the repo, a single repo, you have to have with all of these, if else come conditions and with the addition of more microservices and that repo it becomes very cumbersome and hard to maintain. I think that’s kind of the gist of it, right? Is that a good summary?

That’s a good summary. One more example, is that even not on CICT it was a, like you said, in tools in general, there is no native support where, for example, we are using, we want to know in our main, I’m on a repo that holds all the microservices. We want to know what is the coverage of our code. So in order to do that we are using a third party tool called the [Inaudible 14:58] to operate our test results and our test coverage results and a lot of times we have problems with it because Cutco does not a make support of it. So we need to tweak the code for a configuration file in order to support it. Also, sometimes you’re not doing changes in one microservices, you are doing the changes only on the second microservice. So you are uploading only one coverage file, and it can cause a lot of issues on how to calculate your coverage. So you have a lot of good things of using mono repo, but you have a lot of also pain and headache on using it.

So I’m reading here that Google is using [Inaudible 15:48] this was 2015, I’m assuming that this is bigger and this is a question for you, Alex and for Dor, but using 86 terabytes, 2 billion lines of code, 9 million unique source files, which is huge. So how do they do it?

So basically what they do; so usually when we are talking repository and I guess that’s the nature of start-ups, we usually looking at the results that they usually goes to get based like [Inaudible 16:23] and so on a what Google actually is able to do. So they have their own VCS, the code, the hallux that actually enables them for those version controls, especially when it’s systems, sorry and that actually helps them to build a virtualization and access control that only required a sub modules are available. So of course, when we are talking about working in scale, it’s much easier, and it has a much better performance aim.

Basically the solution was not to use [Inaudible 17:11].

So that’s sent from Google, but what an interesting thing is that; so when Microsoft, they have something that’s called VFS, it’s a virtual filing system and it kind of providing an obstruction layer on top of itself that provides a capability of access control. So for example, if we are talking about another repo with, let’s say, 50 different services, and we have more than one developers, the developers working on it with the, just working with GitHub, but will actually experience that comments like a status check checkout to pull usually to take lots of time and with the combination of the Microsoft VFS. So with this extra layer and they will provide you to run those comments only on the services you have access to. So that’s actually spit it up and because GitHub and VFS also of them now owned by Microsoft, I think it’s just a matter of time when we’ll see that the one is incorporated into another, or as we can see the mono repo is a very hot topic and more and more companies are trying to adopt it. And as Dor mentioned before, there are still tools that they’re missing a different capabilities about it. And it’s, I believe it’s just a matter of time that everyone will be aligned and with the technology.

So Dor you mentioned that one of the consideration to be inserted in circuit CI was actually run that maybe you can elaborate on that specific.

Yes, of course. [Inaudible 19:11] Israeli start-up that is competitive with Circuit CI. Basically a company that allows you to use their platform for your CICB pipelines and the beauty and the difference between [Inaudible 19:26] and Circuit CI, although I’m using Circuit CI but the good thing in conference is that they have mono repo native support or maybe the right term is partial support. They let you decide when the projects inside the mono repo will be built, you give them the pattern, for example, and file a names or folder name and they know when to build the project inside the mono repo while the Circuit CI doesn’t let you do that. I mean, if you want to build your pipeline, you need to put, like you said before [Inaudible 20:13] in the code, we in Cycode, they have like a small bus scripts that look for specific patterns. For example, we have service A and service B. So only if service was changed, we will build service A and if not, service B will start it’s workflow but will stop in the middle after this check. While code fresh, doesn’t start the workflow at all. So this is one cool thing.

How do you define a project based on folders in that case?

Yeah. So we have in the workflow configuration, we have like a field name called service pattern and we give in the service pattern field for each service for each microservice, we give a list of strings that; list of file names and file path. But if one of them was changed in the gate commute we will build the microservice and deploy the microservice. For example, we have one folder called common in our mono repo. So if there is a change in the common project, all the microservices will have the build process and we’ll have the deploy process

Now that you remind the common thing, I think in a previous discussion at the end of the topic, you mentioned that one of the challenges with repos is sharing a library and sharing common libraries. Can you elaborate on that as well?

Yeah, I will give an example from BlazeMeter. So we had like two repositories. One is APA testing that it was an internal repository called APA testing for our integration and end to end testing and the second one was pipelines decay for internal tool to use a BlazeMeter API in Python. So we have like two repositories and every time it happens, I mean, more than one time in a week, let’s say that. Every time a developer opens a public Western API testing, he probably needs to add the new capability to the pipelines decay. Every time you want to test a new feature, you need to open a public request in the APA testing repository and also in the Python instigator repository and it happened a lot of time that developers forgot to merge the two pull quest, although they depend on each other and then we got evals, false positive evals in our APA testing. As part of our monitoring and logging mechanism in placement that we have like [Inaudible 23:02] and AP testing in productions are failing and it was one of the false positive we had. We had a lot of discussions do we need to manage these two repositories? And we decided not to, because we wanted that the pipeline decay will be at the end released to the customer. So if we want to release them to the customers, we can’t have the pipelines decay. I mean, in the AP testing repository because we want to separate between them. So that’s why we didn’t do the mono report.

So one reason not to use mono repo is if you want to open source or to publish your repository, your project as part of the community. Also we had a one more example, is that in placement that we have, we had like a Monolito that holds all the back end services and a few more minor microservices and that was on separate repositories and every time we wanted to develop feature, we had to request in a lot of our repositories. And again, it caused bugs because developers forgot to merge the request and then the dependency was broken between them. When we just, let’s say the QA found the bug, and then the developer said, oh, I forgot to merge these folders. So that’s something that in mono repo we don’t have.

So basically one of the main issues with the mono repo [Inaudible 24:48] option is that all requests, the process of doing the pull request and merge becomes much more complex and cumbersome at least with the current tooling and I think Alex, you mentioned that a gate is providing some utilities to address that like; so what we’re seeing is kind of a two dimension of addressing that challenge. One of them is creating a single repo and building kind of a visual version control system on top, which we’ll talk about probably the Microsoft approach and that goes in line with the model repo. I think the direction that we’re discussing and it is because of the monetizing on having many repos and others, trying to make multiple repos simpler and addressing that in that direction. So it’s kind of two opposite direction for addressing the same issue of complexity.

Yeah. So for [Inaudible 25:47] hub, of course, if you’re using the pricing part, if you section [Inaudible 25:58] you have the actions part but you are a price for execution units, you’re priced by the amount users that have access to our organization and the last part, the one you mentioned is actually how many private drinkers you are allowed to have. Of course when you’re working with multiple repos once you reach a threshold, you need to operate usually your monthly price plan growth with it and once you’re working with the mono repo you actually have all repos, like you have actually one repository. So, it is a kind of like goes against the pricing model. But again, it’s more pattern and architecture and then the company culture of how they work around the version control and not sure what actually; it would be interesting to see that more and more companies adopt it how if they were going to changes on their side as well.

But you mentioned that they’re building some tools to manage multiple pull requests as a single operation and things like that.

Yeah. So once you’re working with a multi repos I came across the two tools. One is Metta, the other one gates. So once, for example, you want to keep [Inaudible 27:40] for example, you’re working on the multiple layer services and each one has a different repos story. So you can [Inaudible 27:49] change across multiple services? So with a simple command you can actually open a branch with the same name on the target services and the same goes with commits and the pull request. So it’s kind of like tape on there and the common lab level, common line level. It allows you to simple the KPIs, some standardization but on the other hand, this still keeps you to make sure that each pull cross requests is in the different repos. So everything is approved. Everything is merged and everything is packaged and deployed.

And then Dor are you familiar with the usher type of approach on how to deal with that with the PCs and adding on top of gate to address that?

So I looked on Azure dev ops and they have this native support on the CACD pipeline as give you similar to coffers, but a better, they give you like a folder for each service. So for each of service you can put a young man or config file describing your workflow, and it’s more native support for a mono repo. One thing I wanted to mention is that I know when I talk with people about mono repo they are saying okay, but I have a lot of projects and I have this person responsible for a service A and this person responsible for service B and I want to make sure that they will review the pull request and each be in charge of the project. So what people are doing is that they have teams that are responsible for specific microservices and specific repositories and then in this case, you can say that, Alex you’re not responsible for this service and I am responsible for this service and its different repositories. So I can be sure that I will see everything on the repository. What I answered to these people is that you have the code owner’s file and code owners file is late. You decide who is responsible for every project and every file in the repository, you can use the code owner’s files to make sure that the relevant person will review the pull quest and the relevant person will see every change that being made on the specific repository or project that he’s responsible for.

So this is one thing I wanted to mention. I forgot at the beginning and the second one that I wanted to mention, the second thing I wanted to mention is in mono repo it’s much easier to do changes, to do base changes. Let’s say you have a document image that all of your microservices are using and you’re now in document file, you’re having the first line from X and this X is document image you build in your company, in your R and D organizations and you want to do it for all of your microservices and so in mono repo it’s much more easier. You can do the change in the mono repo because you have a folder, you have a project called base document image. You can do the change there, and then all your services will be built because they notice that; your pipeline notice that there is a change in some base image and then all the microservice will be built from this new change on the new document image. For example, you want to use a new APM application performance monitoring tool. So you need to add it to the document image, or you discover that there is a new security vulnerability on the base image you’re using. So you want to update it for across all of your microservices. So instead of going every repository you have for every service you have, you’re doing it in one place and all the microservice are getting it automatically. So these two things I wanted to…

Yeah, that’s a huge advantage. So I think it maps directly to velocity, I think, right? In terms of how agile you could be in terms of your development cycles and when that process is much simpler, right?

Yeah. Especially in start-up journey, or you want to do things fast and you don’t have time to manage every repository. So you do the change in one place and it’s affects automatically. If you are doing it right on your CSD pipeline, it affects all your microservices automatically and it saves a lot of time and it saves a lot of headache and it saves a lot of what is the image I have? What is the common function I’m using? Everything is in one place. So it saves a lot of time and a lot of energy when you already bugging bugs, because maybe if you have a multiple repository, maybe you forgot to do it for one and then you can lose yourself when you’re already buying a bug, but when you have everything in one place, you know that all repositories are using the same thing, you have one source of truth. So you are more relaxed when you’re coming to debug a problem.

So I think it touches also to culture as well, at least from what I’m hearing and reading on the Google choice of monorepo and Facebook and whatever. Part of the rationale beyond them was a collaboration and the ability to create a culture of kind of openness so that you don’t restrict necessarily on repos also fits with that everyone have access to, but have different roles and that type of transparency, if you’d like culture is also part of that. So maybe Alex, you could say a few words about how that affects when you’re managing development and if they’re structured into repos, how does that affect the culture of the work. Are people getting siloed as a result, or kind of put themselves in a certain bracket or [Inaudible 34:38]?

So again, I guess even; as you mentioned, its lots of to do about the culture and the first of all, there are two ways of work in monorepo. The first one, Dor mentioned is that there is a dedicated team to dedicated service and they of course said the [Inaudible 35:08] co-operation is the culture base is probably if you want to introduce new features and only one service and it’s probably you’ll have to keep in mind things like a backward compatibility and [Inaudible 35:26] is broken your end game feature production and then the main thing is that they could say, you can see in the one repository, all the pull requests, what is the [Inaudible 35:41] is not so easier to track. And on the other hand, the cultural part, especially in start-ups where you don’t have this privilege to have a dedicated gateway for a microservice and it’s more about a team that being across and actually there are more and more companies that they goes that way, that the teams are more known for not around services, but more around the features. And usually features are across multiple services. So from this perspective, it’s a great enabler for a developer to have multiple requests across multiple services that everything is in one pull request and for [Inaudible 36:30] it’s much simpler to understand the intent of the developer, if there was a bug, what is it about and the terms like scalability, security and vulnerability and so on and so on and so on because it’s all in one place.

Yeah, I think that’s something that usually is, there’s some oversight to that. Is that the way you organize the information in your organization have almost a direct effect on the culture of collaboration and some of them, we could see that, with Google docs versus Microsoft, and we can see that with Slack and other things there is almost a direct correlation between the choice of how structure of information is being used and how that affects the culture within an organization. Dor, you mentioned place where you are in your work there, and you haven’t changed your view on a monorepo as a result of that experience. Maybe you could describe that experience like what was the reason that they use monorepo and the reason that you thought that would, that was the wrong reason for not using monorepo which is related to culture related to how much you trust your developers from that experience and I think that’s also interesting to see how that affects culture.

Yeah. So, I wanted to answer this question also, your previous question, what you asked Alex. So I think as an R and D manager, you want to have a culture that everyone wants to know everything. I don’t want to have a developer. I mean, that’s the vision, that’s the dream. I know that there are developers that wants to live on their bucket, as you said, but as R and D manager you want to have a culture that everyone wants to be involved on everything, even if they are not developing the feature itself or the service itself, they want to know that’s the culture I want to have and the organization that I am leading, and I will lead. I want that my developers will want to know as much as they can.
So in repositories if you have multiple repositories, maybe I won’t see because I’m not following the repository. I won’t see any polar questions. I won’t see any GitHub issues. You having the repository and then I’m not familiar with what my colleagues are doing and what my friends are doing as a developer perspective, I’m talking. But if you are having monorepo and you are subscribed to this repository because we are working on this repository and you have a lot of projects inside. You can be involved in the development process on every project and then the people can have a lot of conversation and not focusing only on what they are doing.

I had one developer on BlazeMeter that got his tasks and focused only on his task. One of the things that I had with him on our calls is that I want him to open his mind, open his eyes, to what other people are doing and not only what he’s doing and to learn more. I mean, people, I mean, I think that developer can learn a lot of things if only by talking about it and only by seeing the call and only by hearing what other people are doing and not only focusing on their features and their service and their project. That’s my answer for the previous question. What you asked now is that I have in BlazeMeter, we had DevOps call every week and one week, we have a call about combining all the all the microservices to one repository, the mono leads and the microservices to one repository and then if we’re doing a change in the UI it will be in the bullet price with the back end, because it will be the same repository. One of the managers said that we are not working well together. The teams are not working well together. The UI developer is waiting for the back end developer for his APIs and the back end developer wants to manage his code without the UI and et cetera, et cetera, and he thinks that we should have and he thought that we should have a monorepo to prevent these kinds of issues that one is not ready yet and we have like conflict issues between the two projects.

He said that because we’re not working properly, we need to do it and I said in this meeting that it’s not the reason. It’s not the reason to change your repository is in your pipelines and I don’t know what people are regular to do, because we are not working properly as colleagues. We need to focus on this issue and not to fix it by doing tech things.

What you’re saying is that this is coming the opposite way of looking at things you basically saying, yeah maybe doing a single repo may solve indirectly a culture issue, but the order needs to be the opposite. Meaning that if the way the organization works is not sufficient enough to fit into the way you want to structure the information within the organization, then you need to deal with that rather than to deal with the opposite way around. So that’s kind of [Inaudible 42:34] the comment there. I think that that kind of bring us towards the end of this topic and this discussion. I know that as in many of those discussions, we can probably continue to go over and over that and I want to start wrapping up with the question of I’m a new start-up. I’m starting a new project and then I’ll switch to a new start-up and ask the same question and what would be your recommendation? I’ll start with you Alex.

So I guess say it’s all about which stage you are and if you are a start-up in the garage then all we need to do is a quick care advocate, probably the best thing is all about using microservices, but go to the model to have Monorepo and to provide the solution as fast as possible.

So you’ve been saying monitor it, not microservices.

Yes, because even with microservices, it does provide you a bit complexity regarding demos. But if you’re already in the stage of a microservice and microservices that you have a multiple repos, and I would suggest definitely go with monorepo as long as you have the right tooling to work around it that emphasizes the velocity. If you don’t have and you see that the velocity is impacted by things that tried to avoid it, that’s my response.

Dor, what’s your take?

So I agree and disagree with Alex. I must say, because I have like…

We like it when we don’t disagree on something.

So I have like a bad memory from BlazeMeter that we kept them monoliths because when the founder founded the company, like Alex said he used one repository with everything inside and even five, six years ago, it’s still a Monorepo. So I think that even if you’re a start-up and you’re walking on the garage, you should start with microservices and you should start with Monorepo. It shouldn’t be a monolith, and it shouldn’t be a repo service. It should be Monorepo because in this way, you can promise yourself that you are not doing things in a bad way now and maybe in the future, we will fix it because if you are a start-up you are not going to fix it. You have customers, you have a lot of things to do and you won’t fix it and this is something that it’s very important in the beginning, because then even your developers will be unhappy that you have a monolith and they need to do facto. I see now in Cycode that we have a lot of microservices and the architecture is amazing. Seriously. It’s amazing and I see how much the developers are happy because of it.

So, yeah, we are using a Monorepo, but we have a microservices and I think that’s the thing that a new start-up should do using a microservice, think about your architecture. I mean, don’t couple your decision with repo and multiple repositories for your architecture. Think first about your architecture and then decide on microservices because that’s the, the right way and then decide if you want to invest time on building the project that it was only because you can’t do it. You can use like Gita repository template for this, and you can do a lot of cool stuff, but because you are a beginner and because you want to do a quick wins and you do an FMP, like Alex said, maybe the right thing to do is using Monorepo and maybe when you are becoming a big company after you get investments and all kinds of stuff, you can build the repository. So everything will have the repositories that they are in charge.

Something that they haven’t touched. For some reason, we were always speaking about monorepo and microservices, and we actually haven’t touched the entire topic about servers. Servers are the only right way to go in monorepos. So for example, if you, the good examples for it, it’s a circular framework. So once you’re talking about a functions and the small pieces of code that you need to develop and especially in such big scale, it’s just impossible to have a repo function.

Yeah, that will be insane, I’m assuming.

Yeah. And especially, and so for example, [Inaudible 47:47] as a really good [Inaudible 47:53] that they have a one Monorepo with all the services, all the functions and [Inaudible 48:00] you can deploy, I know where some other companies as well, that are right in it and exploring it and providing some solution around the server lists, having the same approach that all of them need to have, need to be is Monorepo.

So I think if I’m kind of summarizing both of your options that you basically saying that philosophy and agility are probably the main factors and even if the tooling is not necessarily optimized for that and we are seeing a change towards that. That will be the more dominant factor in the balance between tooling and velocity and Monorepo has a much greater advantage right now in that regard. Also project management from a sequel managing version control. I will add my perspective to that is that in clarify, for example, we have a version that is a single container and a version that is broken into microservices and also there we’ve seen the differences between agility and velocity and there is some tension between the two. So for development, for one of the simple version that will run on my local desktop having a single container that runs everything was much simpler than having multiple containers. Even if they have rocked within a swarm file or whatever, the fact that it’s broken down into many containers is making it already a little bit more complex to manage maybe right from an architecture perspective.

So we ended up doing both we have the software itself can be broken down into microservices, but can also be packaged into that single container. That’s kind of how we address the trade-offs. So I think my perspective to that being the older in the room here in a sense that there is no necessarily black and white in their trade-offs, I’m assuming that there would be cases in which at least part of the project and the main part of project would probably fit well within the Monorepo, but it doesn’t mean that it will have other repos as well. For other things you mentioned open sources and examples also, maybe if you have components that are open source, you want to still keep them in a separate repo, then the rest of that, not open sourced and so forth until we’ll have something kind of a metal project that we can put around that and make those decisions much easier around that. So I think that’s kind of my, I would say the older person in the room here in the discussion, just to make sure that we understand that at the end of the day, it’s a [Inaudible 50:41] decision. It’s not a black and white question and that’s yeah, Dor you can to that.

I agree, it’s basically you need to take a decision and there is no like the right thing to do. It depends on what are the reasons to do what it says. It’s basically cost benefit. It’s not like that’s the right thing to do and that’s it. Every company has its own set of rules what to do and like you said, it’s not black and white.

Excellent. So I think that’s a great way to end the discussion. Again, we could probably extend it to servers and other topics that was brought up in discussion. Dor, thank you for joining us. I think as a first call, it was really good and I really liked the dynamic of discussion. So hopefully the audience will think the same way. So with that, I think we’ll turn it over to you, Johnny.

Thanks so much, Nati, thanks to everyone for taking part in this really interesting session and thanks to all, thanks Alex. Thanks, Nati. Okay, cool. So as always any supporting material you can find on our podcast page that’s clarify.co/podcast and hang around for the next session and for the next couple of sessions, we’ve got a few exciting things going on. We’re going to be talking about EKS and we’ve got a very special guest from next insurance. We are going to be taking a deep dive into that. That’d be very cool. So guys, this has been great and stay healthy, stay safe and see you next time.


    Back to top