Monolito

¿Qué es un monolito?

Un monolito es una aplicación construida y desplegada como una sola unidad. La interfaz de usuario, la lógica de negocio y el acceso a datos viven todos en un único código, compilan juntos y se despliegan juntos. Cuando despliegas, despliegas el conjunto entero. Durante la mayor parte de la historia del software esto era sencillamente cómo se construían las aplicaciones, y para muchísimos proyectos sigue siendo la opción correcta.

El punto de comparación habitual son los microservicios, donde una aplicación se divide en muchos servicios pequeños que corren y despliegan de forma independiente. El monolito lo mantiene todo en un sitio, lo que lo hace más fácil de desarrollar al principio, más simple de probar de extremo a extremo y más rápido de razonar porque no hay saltos de red entre partes. El coste es que se vuelve más pesado con el tiempo. Un cambio pequeño implica volver a desplegar la aplicación entera, y el trabajo de un equipo puede chocar con el de otro en el mismo código. Una startup que saca su primer producto casi siempre se beneficia de un monolito, y luego revisa la cuestión cuando la escala y el tamaño del equipo empiezan a hacer crujir esa única unidad.

El planteamiento honesto es que "monolito" no es un insulto y "microservicios" no es un trofeo. Los microservicios resuelven problemas reales de escala y organización pero añaden una complejidad operativa que los equipos pequeños pagan sin sacar el beneficio. Muchas empresas que se lanzaron a dividirlo todo han vuelto a meter trabajo dentro de un monolito bien organizado. La arquitectura debería ajustarse al tamaño del problema, no al tamaño de la ambición.

Los monolitos en Dallonses

Arrancamos la mayoría de productos como un monolito, y lo decimos sin rodeos incluso cuando un cliente llega pidiendo microservicios. Un monolito limpio y modular sale antes, cuesta menos de operar y es mucho más fácil de cambiar mientras el producto aún busca su forma. Hemos asumido más de un proyecto donde una división prematura dejó a un equipo pequeño ahogado en infraestructura, y el arreglo fue consolidar, no fragmentar más.

Cuando la escala o la estructura del equipo lo piden de verdad, dividimos con deliberación, sacando las piezas que necesitan escalar o desplegar por su cuenta en lugar de reescribirlo todo de golpe. Las aplicaciones web a medida que construimos están arquitecturadas para que esa frontera pueda trazarse más tarde sin un derribo. Tomamos la decisión sobre la evidencia, con el cliente, y estamos cómodos recomendando la respuesta aburrida cuando es la correcta.

¿Dudas si empezar con un monolito o dividirlo? Dimensionemos primero el problema.

Hablemos de arquitectura