Cuándo basta un monolito, cuándo separar. Ley de Conway, topologías de equipo — y por qué la respuesta no es «microservicios».
Categoría · DevOps e Infra
Dos arquitecturas, una ponderación.
Un monolito mantiene toda la aplicación en una base de código y un despliegue. Los microservicios la descomponen en muchos servicios independientes, que se desarrollan, entregan y escalan por separado.
Ambas opciones son legítimas. La separación cuesta complejidad (red, consistencia de datos, operación), y ese precio debe justificarse con un beneficio real.
Cuándo se separa.
La ley de Conway dice que los sistemas reflejan la estructura de comunicación de su organización. Los microservicios tienen sentido cuando varios equipos independientes deben entregar de forma autónoma, sin bloquearse mutuamente.
Hasta entonces, en nuestro caso construimos casi siempre un monolito bien estructurado: más rápido de desarrollar, más fácil de operar, más sencillo de entender. Separar se puede hacer después, de forma dirigida, a lo largo de la costura que realmente duele.
Por qué la respuesta no es "microservicios".
Los microservicios como decisión por defecto conducen a monolitos distribuidos: todas las desventajas de la distribución, ninguna de sus ventajas. Es el error caro más frecuente en este terreno.
La pregunta correcta no es "¿monolito o microservicios?", sino "¿dónde pasa la frontera en la que entregar de forma autónoma genera un valor real?". Solo esa frontera justifica el corte.
