Una startup de 5 ingenieros que adopta microsservicios cambia un repositorio por cuatro, un deploy por una orquestación y un stack trace por cruzar logs de cuatro procesos. Pagas ese cambio en la semana dos, antes de que llegue cualquier beneficio de escala.
Qué entregan los microsservicios
Microsservicios es un estilo arquitectónico: la aplicación se vuelve servicios pequeños e independientes, cada uno en su proceso, hablando por API o por mensaje. Cada servicio cubre una capacidad de negocio y escala por su cuenta.
También asumes la factura operativa de esa separación: un pipeline de deploy por servicio, rastreo de requests entre procesos y cuatro sistemas que tienen que responder juntos. Sam Newman trata estos efectos en Building Microservices (O'Reilly, 2021), incluido el "distributed monolith" que aparece cuando los servicios dependen entre sí en tiempo de ejecución.
Netflix salió del monolito con cientos de ingenieros detrás
Netflix y Amazon popularizaron la arquitectura de servicios. Netflix migró de un monolito que frenaba su crecimiento y ya empleaba cientos de ingenieros para operar video a escala. Amazon armó equipos de plataforma cuyo trabajo era esconder la complejidad de servicios del resto de la empresa.
Martin Fowler y James Lewis describen el estilo en "Microservices" (2014) y aconsejan empezar por un monolito mientras el dominio sigue moviéndose. Fowler insiste en el orden en "MonolithFirst" (2015): parte el código antes de partir el proceso.
Tú tienes de 3 a 8 ingenieros tratando de probar que alguien paga por el producto. No existe equipo de plataforma que absorba la complejidad, y el dominio cambia después de cada conversación con un cliente.
El costo aparece en la semana dos
- El deploy se vuelve coordinación. Versionas APIs entre servicios, defines el orden de publicación y mantienes compatibilidad hacia atrás. El pull request de una pantalla se convierte en tres PRs de repositorios distintos.
- El debugging se vuelve investigación. El error que antes lanzaba un stack trace ahora pide logs de cuatro procesos cruzados por horario.
- El teste se vuelve infraestructura. Para probar que los servicios se hablan, alguien mantiene un entorno local armado o un staging que cobra por hora.
- El onboarding se vuelve contexto. Quien entra en la semana dos lee cuatro códigos antes de tocar producción.
Nicole Forsgren, Jez Humble y Gene Kim muestran en Accelerate (2018) que la velocidad de entrega sigue la frecuencia de deploy y el lead time. Un pipeline por servicio empuja los dos indicadores en el mal sentido.
Cuándo los microsservicios pagan el costo
La separación rinde en dos situaciones concretas:
- Equipos distintos necesitan publicar partes del sistema sin esperarse
- Una parte del sistema pide cien veces la carga de otra, como búsqueda frente al alta de cuentas
La separación también rinde cuando los límites de dominio del producto ya están definidos y estables. Una startup que todavía busca product-market fit queda lejos de ese punto.
El monolito modular parte el código dentro de un solo proceso
Un monolito modular mantiene un proceso solo y corta el código por dominio: cada módulo con su propia capa de datos y sus interfaces. Ganas fronteras de código sin ganar red, contrato de API ni releases encadenados. Eric Evans llamó a esas fronteras contextos delimitados en Domain-Driven Design (Prentice Hall, 2003).
Cuando el monolito llegue al techo de escala, extraes servicios de un código que ya está organizado por dominio. La extracción se vuelve trabajo de infraestructura.
El patrón que sostiene startups en crecimiento
Empieza por el monolito modular bien cortado. Crece hasta su techo, más alto de lo que la mayoría imagina. Saca un servicio cuando aparezca un problema concreto: dos equipos trabados en el mismo repositorio, un componente que solo pide diez veces la carga del resto, una parte del sistema que necesita otro stack.
Sacar servicios por preferencia arquitectónica cambia un problema futuro por uno presente, y el presente pesa más para quien tiene cinco ingenieros y doce meses de runway.
