The developers Facebook, Google and our Webmail team consolidate their code into a single repository where dependencies are shared (the monorepo or mono-repository). AWS, Leboncoin.fr and the rest of the Infomaniak teams segment their code in independent repositories with small autonomous teams (these are called multirepo or “multiple repositories”). Choosing a code management method is a strategic decision for the company, regardless of its size. How to define your strategy and with what impacts? In this article, we share with you our experience in making the best choice based on a specific example: the evolution of our Web Hosting services.

From monorepo to multirepo: the evolution of Infomaniak’s Web Hosting solution

V1 hosting: Infomaniak’s unique hosting offer

In the late 90s, the Hosting V1 platform was launched. This was Infomaniak’s first-ever hosting offer.

This first platform was based on a monolith architecture, which means that the entire application was developed as a single software package. At its inception, this architecture was the norm in our nascent industry. It was tailored to the needs of the development team and was suitable for our lower traffic volumes while providing good development speed.

V2 hosting: the current web and WordPress hosting solution

In 2013, we launched the Hosting V2 platform, our current hosting offering. It is also based on a monolithic API common to all Infomaniak products.

At that time, microservices architecture was beginning to gain popularity, but we decided not to adopt it immediately for this new platform. This would have meant a massive change in practices:

  • rethinking the code in depth,
  • changing deployment and observability methods,
  • adapting many processes and
  • training people.

This was a premature change because at the time, the tools to implement such an architecture were insufficient. They added more complexity than they removed for a team the size of Infomaniak.

In 2024, with 6 times more staff than back then, new perspectives are possible and new needs are emerging.

Hosting V3: Infomaniak’s next hosting platform

The future hosting platform is in full development and will be based on a multi-microservice architecture.

This is an ambitious and complex transition phase that will enable us to meet the challenges of tomorrow and create new hosting services. This evolution will be complete and will affect both the interface and the cloud architecture in the background.

We want to maintain our ability to quickly turn our ideas into products for our customers. This new architecture provides the speed needed to keep pace with growth and anticipate future needs.

Julien Viard, VP of Engineering at Infomaniak

Implementation of the transition from Monorepo to Multirepo

From a monorepo architecture with Hosting V2…

With the growth of Infomaniak, the creation of new products and the expansion of our teams, the monolithic architecture originally chosen for Hosting V1 and Hosting V2 is now showing its limits. It increasingly falls short of our organisational structure and current needs. That is why we are developing the future hosting platform (Hosting V3) with a new microservices architecture.

Technically, here is what the monorepo architecture of the Hosting V2 platform looks like (in a simplified way):

Ce schéma représente la relation entre les différents services de nos solutions d'hébergement.
This diagram shows, in a simplified manner, the relationship between the main services of our hosting solutions.

In this diagram:

  • First of all, the Infomaniak Manager is the monolith used on the front-end side. It handles all the visual aspects of managing Infomaniak products. The Manager is connected to all our APIs and allows our customers to have a single interface to manage all their services. With the architecture in place, every update to a hosting service impacts all the other products, which requires a very strict update policy so as not to jeopardise the stability of the Manager as a whole for customers.
  • Infomaniak Legacy (i.e. the “original” or “historic” code that has become obsolete or difficult to maintain) contains a large part of the Legacy Hosting code and the Infomaniak Legacy General code: all of this code is currently in the same project. As with the front-end section, updates to the Hosting monolith back-end impact the entire Infomaniak Legacy code relating to all services, which reduces the speed of our product teams.
  • Infomaniak Core is a microservice that contains several cross-functional features such as the retrieval of a user profile.

In short, this architecture makes it more complex to update some of the services without impacting all of the projects, which has a negative impact on the speed of an ecosystem that contains many interdependencies. The two large monoliths, Infomaniak Manager and Infomaniak Legacy, are complex to evolve because they have an impact on all our services, whereas with the current redesign (Hosting V3), we will have several microservices that are easier to update.

A monolithic architecture is like a building: when you change the heating, you impact the entire building. With microservices, it’s like single-family homes: if you change the heating in a house, it doesn’t affect the houses next door.

Matthieu Mabillard, Team Lead Developer

…to a multirepo architecture with Hosting V3

Hosting V3 represents a fundamental overhaul of our architecture.

This diagram summarises, in a simplified manner, how the new hosting platform under development works:

With this new architecture:

  • Firstly, the front-end part of the hosting services is now uncorrelated with the Infomaniak Manager to facilitate their evolution.
  • Legacy Hosting recovers and isolates the historical code of the old Infomaniak Legacy monolith. This code is modernised into a microservice to make it easier to maintain, but it is not entirely rewritten.
  • The proxy takes care of translating the customer’s authentication to the Manager in order to allow him/her personalised secure access. It is the entry point for all interactions.
  • Hosting API contains the new code for the new Hosting V3 platform. Its role is to dispatch information to Infomaniak Legacy General or Legacy Hosting API if it sees that the requests correspond to features that have not been redeveloped.
  • SSL Certificate management (SSL Certificates) is isolated within a microservice to facilitate its development and integration into all services.
  • Infomaniak Legacy always contains the dependencies of the Infomaniak monolith for the cross-functional features.
  • The user authentication microservice (OAuth2.0) also remains unchanged.
  • There is also the Infomaniak Core microservice, which combines several functions such as recovering a user’s profile.

This division into microservices makes it possible to reduce dependencies between microservices and to control technical debt. We have complete control over the deployment and lifecycle of our code, be it the new one or legacy. This approach allows us to live with a hybrid model that combines speed and scalability.

This architecture shines in environments characterised by highly distributed execution. It offers strong resilience, great redundancy and high adaptability to load variations.

Matthieu Mabillard, Team Lead Developer

Moving from monorepo to multirepo: the importance of well-prepared teams

As part of this transition, we are introducing measures to foster the adoption of common standards across teams and strengthen exchanges between specialists with:

  • Non-hierarchical expertise guilds that allow experts to share knowledge across the board at the level of developers. They discuss topics such as APIs, DevOps, Laravel, Angular.
  • Quality guidelines to harmonise practices across teams with standardised criteria. This point is linked to our ISO 9001, ISO 14001 and ISO 50001 standards.
  • Accountability of Team Leads who have operational management of all microservices in their team. This strengthens the autonomy and responsibility of the teams. The technical management is therefore relieved of certain tasks and can focus entirely on strategy, technology, implementation of best practices, supervision and accompaniment.
  • The implementation of auditing tools (SonarQube, Renovate, Gitlab CI) to monitor all the entries that are generated and to be able to monitor the state of the repositories as a whole.

Monorepo vs multirepo: a strategic choice for the company

The method of managing the code has major implications which are difficult to revisit. So you need to think carefully before making your decision and defining your strategy.

The benefits of the Multirepo approach

In the context of the future hosting platform, the Multirepo approach makes it possible to use the latest technologies without having to wait for other company projects to be up to date. Rights management is also more precise: Access to the base code is finely controlled, including in read-only mode. We know exactly who is responsible for what, which facilitates the transfer of responsibility for a microservice from one team to another and even the restructuring of the DEV division.

The multirepo architecture allows teams to specialise more by clearly allocating responsibilities and linking specific technologies to each project.

Matthieu Mabillard, Team Lead Developer

This results in greater autonomy for the teams: the division of responsibilities improves the efficiency of the teams, who can focus on their own microservice because their repository is independent of the others. This represents increased freedom on several points:

  • lifecycle,
  • specific recruitment,
  • technology choices.

It is also easier to experiment with new projects: multirepo speeds up the development of proofs of concept (POC) that can be done independently of other branches. This makes it possible to validate the feasibility of an idea quickly. Speed is unique to each project: each service in the Hosting team can accelerate or optimise its development cycle, have its own acceptance criteria, all without being held back by the impact it could have on others.

Multirepo facilitates open source contributions: the base code is reduced and the segmentation of services makes it possible to publish some parts of the code and not others, for example for security reasons or to protect (secret) industrial know-how.

This approach speeds up the development cycles: the production run is shorter than in our monorepo projects. In Hosting V3, each component is decoupled while the monorepo Webmail build is longer.

This choice can also have a significant impact on recruitment:

Having attractive technology stacks with a reasonable learning curve is a key factor in attracting talent. No one is attracted to a company that increases technical debt with technologies that are not taught anywhere.

Julien Viard, VP of Engineering at Infomaniak

Limitations of a Multirepo approach

Multirepo calls for greater rigour to synchronise the evolution of one microservice vis-à-vis the others:

  • It is necessary to systematically update the dependencies of your project so that it benefits from the improved quality of the subprogram code or from bug fixes, etc. by using the right library, the right piece of code, etc. It is necessary, for example, to ensure that two APIs retain a common base if they work in a similar way using the same authentication microservice.
  • Setting up integration testing is more complex and requires scenarios in which several microservices can communicate with each other. For example, a client performs only one action to create a website, but this triggers 3 actions on the Hosting side: SSL API, preview image, hosting API.
  • As the code is segmented, it is harder to have continuous traceability and feedback across the entire code.
  • The granularity makes it harder to detect problems, as each microservice has to be checked one by one. On the other hand, it is easier to act because the correction to be made is often better defined.
  • Finally, maintaining synergy between technologies, libraries and development practices requires more skills.

Monorepo vs multirepo: what is the right choice for your developer teams?

This choice calls for several internal considerations:

  • What is the profile of your company? For a start-up with a short time to market, it is not easy to adopt a microservices architecture that takes a long time to implement. It is often necessary to launch a product as quickly as possible and thus strategically choose the solution that brings the greatest development speed.
  • What speed do you need?
  • What are your current technical capabilities? If the company has many specialists with a high technical level, it will make a different choice from the one with a more generalist and versatile team with a more global technology competence.

Here are some more questions that can help you make the right choice:

    • How would you like your code and your development teams to evolve in the medium term?
    • What are the internal strengths of your organisation?
    • What are your recruitment needs and resources?
    • Do you need a dedicated team?

Considering the alignment of competencies, budget capabilities and the stage your business is at, you should now have a clearer vision with regard to choosing the best possible architecture for your developments. Feel free to discuss it with us on X or LinkedIn by mentioning this article.

You might also like…