Monorepo

CodePen's DevOps practice: Advantages of regressing monolithic code base (Monorepo)

While I'm not a big DevOps expert, CodePen is moving to monorepo, which has many advantages over systems with multiple small code bases, at least for us. Your challenges and conclusions may be completely different.

I thought of this after reading Ben Nadel's "Why am I merging microservices back to monolithic architecture in InVision". Although our conclusions are similar, I can tell he is facing a completely different set of problems.

Microservices solve technical and personnel problems

Technical issues are when an aspect of the application puts too much burden on the infrastructure, which can lead to a poor user experience (UX). For example, image processing requires a large amount of CPU. If this CPU is overloaded, it may start to make other parts of the application lack processing resources. This may affect system latency. And, if the situation is serious enough to affect system availability .

The personnel problem , on the other hand, has little to do with the application, but with how the team is organized. The more people work in any given part of the application, the slower the development and deployment will be, and the more likely it is to make mistakes. For example, if you have 30 engineers scrambling to "continuously deploy" (CD) the same service, you'll get a lot of queues; this means that many engineers who would have delivered products are actually waiting for their turn to deploy.

Advantages of Monorepo (Monorepo)

• Unify the world. You just need to git pull a code base and you can be fully synchronized with others and have everything you need for a full development environment.
• in Apple pie order. The location of operations on GitHub will not cause confusion. You make pull requests for the monolithic code base. You open the issue on the monolithic code base. This avoids dispersed activities resulting in loss of information.
• Code Sharing. You can share the code. Sharing utilities or components throughout the code base is especially useful. We've tried publishing the shared section to npm for use with other code bases, but the workflow is clumsy compared to having the code in one place.
• Unified maintenance. There is only one code base, and no old and ignored code bases exist. For our small team, having dozens of code bases means some of them have old outdated dependencies, old versions of Node, code style checking and formatting rules that are out of sync with other code bases, and more.

Disadvantages of Monorepo (Monorepo)

• Deployment complexity. I think the main reason we split the code base in the initially is that the code in these code bases needs to be deployed to different locations. They may represent separate services on some separate Lambda or other server. A single code base means it is easier to connect to components specific to that server/service, such as CI/CD.

Yes, I know this is controversial.

I don't really care. I won't be too harsh about it like the air fryer lovers and CrossFit enthusiasts. This is Matt Klein's powerful argument for the monolithic code base.

I just said: This is very useful for us. I can see that other companies will be different. I can see that companies working with contractors may want to limit their access to less than the entire monolithic code base. I can see that the git codebase can become huge and difficult to manage. None of these are currently problems for CodePen, so the monolithic code base has the advantage.

The above is the detailed content of Monorepo. For more information, please follow other related articles on the PHP Chinese website!