Diseñar y escalar un backend: ¿microservicios o monolito?
La arquitectura de tu backend decide cuánto de tu día se convierte en una pelea. A medida que la aplicación crece, empiezan a verse las grietas de tus primeras decisiones. Llegas a un punto donde tienes que elegir rumbo. ¿Te quedas con el monolito, o lo rompes todo en microservicios?
No existe la bala de plata. Los dos enfoques tienen su sitio. La decisión correcta depende más de cómo está organizado tu equipo y de la fase en que está tu negocio que del mérito técnico puro. Este artículo repasa las dos opciones principales y además un punto intermedio que en la práctica funciona muy bien.
La idea detrás de los microservicios es sencilla. En lugar de construir una aplicación gigante, construyes un conjunto de servicios pequeños e independientes. Cada uno hace bien una sola cosa.
Piénsalo como un equipo descentralizado. Cada servicio gestiona su propia base de datos y puede publicarse cuando esté listo, sin pedir permiso a los demás. El equipo de facturación puede usar Go mientras el de autenticación prefiere Rust, y ninguno tiene que ceder. Esa libertad hace que la gente sea rápida. En teoría, al menos.
En la práctica, esto le encaja bien a las organizaciones grandes, donde coordinar un solo lanzamiento entre 500 desarrolladores es una pesadilla.
El monolito es el enfoque tradicional. Un solo repositorio, una sola aplicación, una sola publicación. Todo vive junto, desde la interfaz de usuario hasta la lógica de negocio y el acceso a datos.
La palabra "monolito" se ha vuelto casi una mala palabra en algunos círculos. Aun así tiene ventajas reales. Es simple. Nunca necesitas un mapa para encontrar dónde está definida una función. La publicación es un solo script. Para equipos pequeños o medianos, esa simplicidad es una superpotencia. Te permite avanzar rápido sin hundirte en la complejidad de la infraestructura.
Un anti-patrón habitual en empresas pequeñas y medianas es acabar con más microservicios que ingenieros. He visto organizaciones con 100 ingenieros intentando mantener más de 300 servicios. El resultado es el caos.
Cuando cruzas esa línea, muchos servicios se quedan sin dueño, o los dueños heredan servicios sobre los que no tienen contexto por culpa de las reorganizaciones. También pasas más tiempo actualizando dependencias en todos los repositorios para cerrar vulnerabilidades. Los microservicios bien hechos necesitan un equipo de plataforma dedicado y una inversión seria en herramientas. La mayoría de las startups no pueden permitirse esa infraestructura, así que su arquitectura "ágil" se convierte en una pesadilla de mantenimiento.
Elige una arquitectura porque resuelve un problema que de verdad tienes. Las modas no deberían entrar en la decisión.
Elige microservicios si:
Elige el monolito si:
Aquí va un secreto. No tienes por qué saltar directo a los microservicios. Probablemente no deberías.
El monolito modular es un punto intermedio sólido. Construyes una sola unidad desplegable, pero por dentro impones límites estrictos entre módulos. El código de Module A no puede importar código de Module B directamente. Tiene que pasar por una interfaz pública definida. Consigues la organización de código de los microservicios sin el coste de infraestructura.
A medida que la aplicación crece, vas separando las partes que necesitan ser independientes.
El debate entre microservicios y monolito suele perderse el punto. La pregunta no es qué arquitectura es mejor en teoría. Es con qué conjunto de compensaciones puedes vivir ahora mismo.
Empieza con un monolito bien estructurado. Divídelo solo cuando aparezca el dolor. Tu yo del futuro y tu equipo de DevOps te lo agradecerán.
© Melvin Laplanche - All rights reserved.