What is a Monolith?

A Monolith is a single, self-contained software application or system containing all the necessary code and data to perform its functions.

What's the problem in Monolith?

• Lack of Scalability: Monoliths can be challenging to scale because all components are tightly coupled, making it difficult to scale specific functionalities independently.
• Limited Agility: Making changes or updates to a monolithic application can be slow and risky, as a single codebase may require extensive testing and downtime.
• Maintenance Complexity: As monolithic applications grow, they become increasingly complex and challenging to maintain, leading to higher maintenance costs and longer development cycles.
• Technology Lock-In: Monoliths often use specific technologies and frameworks, making adopting new technologies or tools difficult without major rewrites.
• Lessened Fault Isolation: A failure in one part of a monolithic application can affect the entire system, making it harder to isolate and address issues without impacting the entire service.

How do you solve those problems?

Microservices is an architectural approach in software development where a complex application is decomposed into independently deployable, small, and loosely coupled services that communicate over networks, promoting flexibility and scalability.

• Scalability: Microservices allow individual components or services to be scaled independently.
• Agility: Microservices are smaller, decoupled services that make it easier to add new features, fix bugs, and update code without affecting the entire system, reducing the risk of errors and downtime.
• Maintenance: With microservices, each service has its own codebase and development teams to focus on specific requirements.
• Technology Diversity: Microservices enable the use of different technologies, languages, and frameworks for each service.
• Fault Isolation: Since Microservices are loosely coupled codebases, if one service fails or experiences issues, it typically doesn't affect other services.

What's the problem with Microservices that the Mono repo solved?

A Mono Repo is a software development practice where all the source code for multiple projects or components of a software application is stored in a single, unified version control repository. In a monorepo, code for different services, libraries, or modules is organized and managed together rather than split into separate repositories as in a traditional multi-repo setup. This approach can simplify code sharing, version control, and dependency management across the various parts of a software project.

The charm of the Mono repo is to bring several loosely coupled code bases into one place and make it easily manageable.

• Complexity: (out of sight, out of mind) Microservices manage numerous codebases, dependencies, and deployment pipelines, leading to increased complexity. A monorepo simplifies code management by consolidating all code into a single repository, making tracking changes, managing dependencies, and maintaining consistency easier.
• Versioning and Dependency Hell: Coordinating versions and dependencies across multiple microservices can be challenging. A monorepo allows for centralized version control and simplified dependency management, reducing the risk of version conflicts and compatibility issues.
• Testing and Integration: Integration testing between microservices can be complex and time-consuming. A monorepo enables more straightforward integration testing since all components reside in the same codebase, simplifying the testing process.
• Code Sharing and Reusability: A monorepo facilitates code sharing and reusability across different application parts, promoting efficient development practices and reducing code duplication.

Advantages:

• Easy Collaboration: All code is in one place, making it easier for developers to work together on different projects.
• Easy Grant Access: It's easy to give developers access to the code they need without worrying about managing multiple repositories. Easy to understand boundaries, which is who's responsibility – If you decide to create reports based on which team owns it.
• Easy to Understand Boundaries: It's easy to see who is responsible for which code because everything is in one place.
• Clone One Repo: Developers only need to clone one repository, which simplifies their workflow. However, individual cloning could also be done in one directory. In that case, you all have to follow which branch you are currently in actively. In case of any changes that can potentially have lots of changes in several repositories, it could be not easy to track. In that way, mono repo could be a bright and shining option.
• Simplified Dependency Management: It's easy to manage dependencies in a monorepo because everything is in one place. Also, shared dependency management has a huge advantage — it solves the problem of incompatible or not matching versions. It's straightforward to manage dependency in the mono repo – because you can put everything in one place and share that in several projects. Imagine only one composer.json shared by rosetta and every Erasys PHP library. That would be simplified.
• Easy Refactoring: Monorepos make it easier to refactor code because developers can see all of the code affected by their changes. This can help to reduce the risk of introducing bugs.
• Discovery: It can be easy to discover code in a large monorepo. Other than that, discovery and searching could be done in GitLab

Disadvantages

• Coupling: If not managed carefully, a monorepo can lead to tight coupling between different projects. However, “Clone one repo” brings a problem that rosetta and other PHP libraries would be a bit coupled. If you didn't consider the subsequent feature integration, you might gradually tighten the coupling between libraries, eventually bringing the issues with Monolith. The problem is when the sprint is not focused on a single goal – Which is very usual. Also, systematic rebasing and conflict resolution could be induced in the mono repo in daily practice.
• More Complex CI/CD Pipelines: Pipelines must be intelligent enough to know which tests should be executed and what should be built.
• Performance: Monorepos can be slow and challenging to build and test.
• Cloning a Huge Repository: Monorepos can be very large, making it slow and difficult for developers to clone.
• Broken Master Situation: If the master branch of a monorepo is broken, it can prevent developers from releasing new features or bug fixes. Suppose something is broken in the master; 2 developers are working on that, and one is ready to deploy a new feature in another project. Which should go first? Is it okay to merge a new feature on a broken master? Potentially, a broken master can put a hold on releasing a feature because those 2 repositories are not in one mono repo.
• Code Review Becomes Crucial: It's important to have good tooling in place to manage a monorepo effectively. This can include tools for dependency management, code review, and continuous integration and delivery.

All these problems are not unsolvable, but you might need to change quite a bit of our existing system to accommodate the Mono repo.