English

Más servicios que ingenieros es una señal de alerta

¿Más de un servicio desplegable por ingeniero? Normalmente es una señal de alerta.

Los microservicios son la solución a un problema organizacional: muchos equipos que necesitan desplegar de forma independiente sin pisarse. Si tienes dos ingenieros y nueve servicios, importaste esa solución sin tener el problema. Pagas el costo de la distribución todos los días y no cobras ninguno de los beneficios.

Qué te compran realmente los microservicios

El beneficio real de dividir en servicios es la desplegabilidad independiente y la propiedad por equipo. El equipo A despliega su servicio en su calendario; el equipo B nunca lo bloquea; cada servicio escala y falla de forma aislada. Esos beneficios solo se materializan cuando tienes suficiente gente para ser dueña de los servicios como unidades separadas, y suficiente escala para que aislarlos importe.

Para un equipo pequeño, nada de eso aplica. No hay coordinación entre equipos que eliminar porque solo hay un equipo. Así que la división no te compra nada y te cobra el precio completo.

El impuesto de los sistemas distribuidos

Cada frontera de red que introduces convierte una llamada de función en proceso en un problema de sistemas distribuidos:

• Falla parcial. Una llamada local retorna o lanza una excepción. Una llamada de red puede colgarse, agotar el tiempo o tener éxito a medias. Ahora necesitas timeouts, reintentos, idempotencia y circuit breakers.
• Se acabaron las transacciones. Una transacción de base de datos que cruza una frontera se convierte en una saga con acciones compensatorias y consistencia eventual.
• Superficie operativa. Cada servicio necesita su propio pipeline, despliegue, dashboards, alertas, guardia y contrato versionado con sus vecinos.
• Depuración. Un stack trace se convierte en una traza distribuida a través de cinco servicios y tres sistemas de logs.

Una startup de dos personas paga todo eso y, como no hay un problema de propiedad independiente que resolver, no cobra nada de la ventaja.

Cuenta artefactos contra headcount

Usa una heurística contundente: cuenta tus artefactos desplegables de forma independiente y compáralos con el tamaño del equipo.

servicios desplegables  >  ingenieros   ->  investigar

No es una ley estricta, pero es una señal fuerte. Si los servicios superan a los ingenieros, casi seguro estás cargando costo operativo sin nada organizacional que lo justifique. El valor por defecto debería ser un monolito o un monolito modular: un solo desplegable, con fronteras de módulo limpias adentro. Conservas la disciplina de diseño y te saltas la red. Extrae un módulo a su propio servicio después, cuando un equipo específico necesite ser su dueño, o un componente específico necesite escalar o aislarse de verdad.

Movidas avanzadas

• Impón fronteras de módulo dentro del monolito (estructura de paquetes, reglas de lint, checks de imports) para que una división futura sea mecánica y no una reescritura.
• Extrae por evidencia, no por anticipación. Divide cuando un conflicto real de despliegue o un techo de escala lo fuerce: para entonces la costura será obvia.
• Mantén un solo pipeline de despliegue mientras puedas; cada pipeline nuevo es costo operativo recurrente.
• Regla de Sam Newman: no empieces con microservicios; empieza con un monolito que puedas descomponer, porque entenderás mucho mejor el dominio después de construirlo.

Recursos

• MonolithFirst — Martin Fowler
• Building Microservices, 2.ª ed. — Sam Newman
• Microservice Trade-Offs — Martin Fowler
• Modular Monolith — charla de Simon Brown