Los desarrolladores de Facebook, Google y nuestro equipo de Webmail agrupan su código en un repositorio único donde las dependencias se comparten (es decir, monorepo o mono-repositorio). AWS, Leboncoin.fr y el resto de los equipos de Infomaniak segmentan su código en repositorios independientes con pequeños equipos autónomos (se trata del multirepo o repositorios múltiples). Elegir un método de gestión de código es una decisión estratégica para cualquier empresa, independientemente de su tamaño. ¿Cómo definir la estrategia y con qué impacto? En este artículo, compartiremos nuestra experiencia para tomar la mejor decisión basada en un ejemplo práctico: la evolución de nuestros servicios de alojamiento web.

De monorepo a multirepo: la evolución del alojamiento web de Infomaniak

Hosting V1: la oferta de alojamiento única de Infomaniak

A finales de los años 90, se lanzó la plataforma Hosting V1. Fue la primera oferta histórica de alojamiento de Infomaniak.

Esta primera plataforma se basa en una arquitectura monolítica, lo que significa que toda la aplicación se desarrolla como un único bloque de software. En el momento de su creación, esta arquitectura era la norma en nuestra naciente industria. Se adapta a las necesidades del equipo de desarrollo y se adapta a nuestros volúmenes de tráfico más bajos, al tiempo que ofrece una buena velocidad de desarrollo.

Hosting V2: el alojamiento web y WordPress actual

En 2013, lanzamos la plataforma Hosting V2, nuestra oferta de alojamiento actual. Se basa también en una API monolítica común a todos los productos de Infomaniak.

En este momento, la arquitectura de microservicios comienza a ganar popularidad, pero decidimos no adoptarla de inmediato para esta nueva plataforma. Habría implicado un cambio masivo de las prácticas:

  • repensar profundamente el código,
  • cambiar los métodos de despliegue y observabilidad,
  • adaptar muchos procesos y
  • formar a la gente.

Un cambio prematuro, porque en ese momento las herramientas para implementar esa arquitectura eran insuficientes. Añadían más complejidad de la que eliminaban para un equipo del tamaño de Infomaniak.

En 2024, con seis veces más empleados que en aquel entonces, hay nuevas oportunidades y nuevas necesidades.

Hosting V3: la próxima plataforma de alojamiento de Infomaniak

La futura plataforma de alojamiento está en desarrollo y se basará en una arquitectura de múltiples microservicios.

Se trata de una fase de transición ambiciosa y compleja que abordará los retos del futuro y creará nuevos servicios de alojamiento. Este cambio será completo y afectará tanto a la interfaz como a la arquitectura cloud en segundo plano.

Queremos conservar la capacidad de transformar rápidamente nuestras ideas en productos para nuestros clientes. Esta nueva arquitectura ofrece la velocidad necesaria para mantener el crecimiento y anticiparse a las necesidades futuras.

Julien Viard, VP of Engineering en Infomaniak

Implementación de la transición de Monorepo a Multirepo

Desde una arquitectura monorepo con Hosting V2…

Con el crecimiento de Infomaniak, la creación de nuevos productos y la expansión de nuestros equipos, la arquitectura monolítica elegida originalmente para Hosting V1 y Hosting V2 ahora muestra sus límites. Cada vez se ajusta menos a nuestra estructura organizativa y a las necesidades actuales. Es por eso que estamos desarrollando la futura plataforma de alojamiento (Hosting V3)con una nueva arquitectura de microservicios.

Técnicamente, este es el aspecto (en pocas palabras) de la arquitectura monorepo de la plataforma Hosting V2:

Este diagrama representa la relación entre los diferentes servicios de nuestras soluciones de alojamiento.
Este diagrama representa de manera simplificada la relación entre los servicios principales de nuestras soluciones de alojamiento.

En este diagrama:

  • Se observa en primer lugar que el Manager Infomaniak es el monolito utilizado en el front-end. Este último maneja todo el aspecto visual de la gestión de los productos Infomaniak. El Manager está conectado a todas nuestras API y permite a nuestros clientes tener una única interfaz para administrar todos sus servicios. Con la arquitectura implementada, cada actualización de un servicio de alojamiento afecta a todos los demás productos, lo que requiere una política de actualización muy estricta para no poner en peligro la estabilidad de todo el Manager para los clientes.
  • Infomaniak Legacy (es decir, el código «original» o «histórico» que se ha vuelto obsoleto o difícil de mantener) contiene gran parte del código Legacy Hosting y el código Legacy General Infomaniak: todo este código está actualmente en el mismo proyecto. Al igual que en la parte front-end, las actualizaciones del monolito Hosting back-end afectan a todo el código Legacy Infomaniak relativo al conjunto de los servicios, lo que reduce la velocidad de nuestros equipos de productos.
  • Infomaniak Core es un microservicio que contiene varias funciones transversales, como recuperar un perfil de usuario.

En resumen, esta arquitectura dificulta la actualización de una parte de los servicios sin afectar a la totalidad de los proyectos, lo que repercute negativamente en la velocidad de un ecosistema con muchas interdependencias. Los dos grandes monolitos Manager Infomaniak e Infomaniak Legacy son complejos de evolucionar porque tienen impacto en todos nuestros servicios, mientras que con el rediseño en curso (Hosting V3), tendremos varios microservicios más fáciles de actualizar.

Una arquitectura monolítica es como un edificio: cuando cambias la calefacción, afecta a todo el edificio. Los microservicios son como las casas unifamiliares: si cambias la calefacción de una casa, no afecta a las casas de al lado.

Matthieu Mabillard, Team Lead Developer

…a una arquitectura multirepo con Hosting V3

Hosting V3 es un rediseño profundo de nuestra arquitectura.

Este diagrama resume de manera simplificada el funcionamiento de la nueva plataforma de alojamiento que se está desarrollando:

Con esta nueva arquitectura:

  • Se observa, en primer lugar, que la parte front-end de los servicios de Hosting está ahora desvinculada del Manager Infomaniak para facilitar su evolución.
  • Hosting Legacy recupera y aísla el código histórico del antiguo monolito Infomaniak Legacy. Este código se ha convertido en un microservicio para facilitar su mantenimiento, pero no se ha reescrito por completo.
  • El proxy es el encargado de traducir la autenticación del cliente al Manager para permitirle un acceso seguro personalizado. Es el punto de entrada de todas las interacciones.
  • API Hosting contiene el nuevo código de la nueva plataforma de alojamiento Hosting V3. Su función es enviar la información a Legacy General Infomaniak o API Legacy Hosting si ve que las solicitudes corresponden a funciones que no han sido rediseñadas.
  • La gestión de certificados SSL (SSL Certificates) está aislada en un microservicio para facilitar su escalabilidad e integración en todos los servicios.
  • Infomaniak Legacy sigue conteniendo las dependencias del monolito Infomaniak para las funciones transversales.
  • El microservicio de autenticación de usuarios (OAuth2.0) tampoco cambia.
  • También está el microservicio Infomaniak Core que reúne varias funciones, como la recuperación del perfil de un usuario.

Esta división en microservicios permite reducir las dependencias entre los microservicios y controlar la deuda técnica. Tenemos un control total sobre la implementación y el ciclo de vida de nuestro código, ya sea nuevo o legacy. Este enfoque nos permite vivir con un modelo híbrido que combina velocidad y escalabilidad.

Esta arquitectura brilla en entornos caracterizados por una ejecución altamente distribuida. Ofrece una gran resiliencia, una gran redundancia y una gran capacidad de adaptación a los cambios de carga.

Matthieu Mabillard, Team Lead Developer

Pasar del monorepo al multirepo: la importancia de preparar bien a los equipos

Como parte de esta transición, estamos implementando medidas para promover estándares comunes entre los equipos y fortalecer la interacción entre los especialistas con:

  • Gremios de expertos no jerárquicos que permiten el intercambio de conocimientos entre expertos de manera transversal entre los desarrolladores. Hablan de temas como API, DevOps, Laravel, Angular.
  • Directrices de calidad para armonizar las prácticas entre los equipos con criterios estandarizados. Esto está relacionado con nuestras normas ISO 9001, ISO 14001, ISO 50001.
  • El empoderamiento de los Team Leads que tienen la dirección operativa de todos los microservicios de su equipo. Esto refuerza la autonomía y la responsabilidad de los equipos. Por lo tanto, la Dirección Técnica alivia su carga y puede dedicarse por completo a la estrategia, la tecnología, la aplicación de buenas prácticas, la supervisión y el apoyo.
  • La implementación de herramientas de auditoría (SonarQube, Renovate, Gitlab CI) para estar al tanto de todas las entradas que se generan y ser capaces de supervisar el estado de los repositorios en su conjunto.

Monorepo vs multirepo: una elección estratégica para la empresa

El método de gestión del código tiene implicaciones importantes que son difíciles de deshacer. Por lo tanto, es necesario reflexionar detenidamente antes de tomar una decisión y definir una estrategia.

Ventajas del enfoque Multirepo

En el contexto de la futura plataforma de alojamiento, el enfoque Multirepo permite utilizar las últimas tecnologías sin tener que esperar a que otros proyectos de la empresa estén actualizados. La gestión de los derechos también es más precisa: el acceso al código base está controlado con precisión, incluso en lectura. Se sabe exactamente «quién hace qué», lo que facilita la transferencia de la responsabilidad de un microservicio de un equipo a otro e incluso la reestructuración del polo DEV.

La arquitectura multirepo permite a los equipos especializarse más, al asignar responsabilidades claramente y asociar tecnologías específicas a cada proyecto.

Matthieu Mabillard, Team Lead Developer

Se logra una mayor autonomía de los equipos: la separación de responsabilidades mejora la eficiencia de los equipos, que pueden concentrarse en sus propios microservicios, ya que su repositorio es independiente de los demás. Se gana libertad en varios puntos:

  • ciclo de vida,
  • contratación específica,
  • elecciones tecnológicas.

También es más fácil experimentar con nuevos proyectos: el multirepo acelera el desarrollo de pruebas de concepto (POC) que se pueden hacer independientemente de otras ramas. Esto permite validar rápidamente la viabilidad de una idea. La velocidad es propia de cada proyecto: cada departamento del equipo Hosting puede acelerar u optimizar su ciclo de desarrollo, tener sus propios criterios de aceptación, todo ello sin verse limitado por el impacto que pueda tener en los demás.

El multirepo facilita las contribuciones open source: el código base se reduce y la segmentación de los servicios permite publicar algunas partes del código y otras no, por ejemplo, por razones de seguridad o para proteger el know-how (secreto) industrial.

Este enfoque acelera los ciclos de desarrollo: la puesta en producción es más corta que en nuestros proyectos monorepo. En el Hosting V3, cada componente está desacoplado, mientras que el build de Webmail en monorepo es más largo.

Esta elección también puede tener un efecto importante en la contratación:

Tener pilas de tecnología atractivas con una curva de aprendizaje razonable es un factor determinante para atraer talento. Nadie se siente atraído por una empresa que aumenta la deuda técnica con tecnologías que no se enseñan en ninguna parte.

Julien Viard, VP of Engineering en Infomaniak

Limitaciones de un enfoque Multirepo

El multirepo requiere más rigor para sincronizar la evolución de un microservicio con otros:

  • Es necesario actualizar sistemáticamente las dependencias del proyecto para que se beneficien de la mejora de la calidad del código de los subprogramas o las correcciones de errores, etc. consumiendo la librería correcta, el fragmento de código correcto, etc. Por ejemplo, es necesario asegurarse de que dos API mantengan una misma base si funcionan de manera similar consumiendo el mismo microservicio de autenticación.
  • La implementación de pruebas de integración es más compleja y requiere escenarios en los que varios microservicios puedan comunicarse entre sí. Por ejemplo, un cliente hace una sola acción para crear un sitio web, pero esto desencadena 3 acciones en el lado de Hosting: API SSL, imagen de preview, API Hosting.
  • Como el código está segmentado, es más difícil tener trazabilidad y feedback continuos de todo el código.
  • La granularidad dificulta la detección de problemas, ya que cada microservicio debe verificarse uno por uno. En cambio, es más fácil actuar, ya que la corrección a aportar está a menudo más delimitada.
  • Por último, para mantener la sinergia entre las tecnologías, las librerías y las prácticas de desarrollo se necesitan más conocimientos especializados.

Monorepo vs multirepo: ¿cuál es la mejor opción para tus equipos de desarrollo?

Esta elección requiere una reflexión interna sobre varios ejes:

  • ¿Cuál es el perfil de la empresa? Para una startup con un time to market (tiempo de comercialización) corto, no es fácil adoptar una arquitectura de microservicios que requiere mucho tiempo de implementación. A menudo es necesario lanzar un producto lo antes posible y, por lo tanto, elegir estratégicamente la solución que proporcione la mayor velocidad de desarrollo.
  • ¿Qué velocidad necesitas?
  • ¿Cuáles son tus capacidades técnicas actuales? Si la empresa tiene muchos especialistas con un alto nivel técnico, hará una elección diferente a la que tiene un equipo más general y versátil con una competencia tecnológica más global.

Aquí hay otras preguntas que pueden ayudarte a tomar la decisión correcta:

    • ¿Cómo quieres que evolucionen tu código y tus equipos de desarrollo a medio plazo?
    • ¿Cuáles son las fortalezas internas de tu organización?
    • ¿Cuáles son tus necesidades y recursos de contratación?
    • ¿Necesitamos un equipo dedicado?

Teniendo en cuenta la alineación de competencias, capacidad presupuestaria y la etapa en la que se encuentra tu empresa, ahora deberías tener una visión más clara para elegir la mejor arquitectura posible para tus desarrollos. No dudes en hablarlo con nosotros en X o LinkedIn mencionando este artículo.

También te gustará…