Cuándo migrar de un monolito a microservicios (y cuándo no)

La mayoría de las startups que adoptan microservicios demasiado pronto se arrepienten. La mayoría de las empresas que se aferran a los monolitos durante demasiado tiempo se arrepienten. La pregunta no es cuál es mejor. Es cuando cambiar.

Este artículo cubre las ventajas y desventajas reales entre las arquitecturas monolíticas y de microservicios, las señales que le indican que es hora de migrar, las señales que le indican que no lo es y el enfoque paso a paso que evita los errores más comunes (y más costosos).

Qué es un monolito y por qué funciona

Un monolito es una única unidad desplegable. Una base de código, una base de datos, una canalización de compilación, una implementación. Tu módulo de autenticación, tu sistema de facturación, tu servicio de notificación, tu capa API; todos viven en el mismo repositorio y se implementan juntos.

Esto suena limitante, pero para la mayoría de los equipos es todo lo contrario. Un monolito te davelocidad. Puedes refactorizar a través de los límites del módulo en una única solicitud de extracción. Ejecuta un conjunto de pruebas. Despliegas un artefacto. La depuración se realiza leyendo un conjunto de registros. No hay latencia de red entre servicios porque no hay llamadas de red; son todas llamadas a funciones en proceso.

Toda empresa de tecnología exitosa comenzó como un monolito. Shopify ejecuta una aplicación Rails monolítica que genera miles de millones de dólares en transacciones. Stack Overflow atiende a 100 millones de visitantes mensuales desde un monolito. Estas no son empresas que no pudieron descubrir los microservicios. Son empresas que entendieron que el monolito era la herramienta adecuada para su problema.

Si tiene menos de 20 ingenieros trabajando en la misma base de código, es casi seguro que un monolito sea la opción correcta. Punto final.

Qué son los microservicios y cuánto te cuestan

Una arquitectura de microservicios divide su aplicación en servicios independientes. Cada servicio posee su propia base de datos, se implementa de forma independiente y se comunica con otros servicios a través de API (normalmente REST o gRPC) o colas de mensajes.

La promesa: los equipos pueden implementar de forma independiente, escalar componentes individuales y utilizar diferentes tecnologías cuando tengan sentido. El servicio de facturación puede ampliarse para manejar el procesamiento de facturas de fin de mes sin necesidad de ampliar toda la aplicación. El servicio de búsqueda puede utilizar Elasticsearch mientras el resto de la aplicación se ejecuta en PostgreSQL.

El costo: ahora estás ejecutando un sistema distribuido. Los sistemas distribuidos son más difíciles de construir, probar y depurar. Esto es a lo que te estás registrando:

• Fallos de red entre servicios.En un monolito, una llamada a función funciona o genera una excepción. En los microservicios, una solicitud puede expirar, devolver una respuesta parcial o fallar silenciosamente. Necesita lógica de reintento, disyuntores y estrategias de respaldo para cada llamada entre servicios.
• Transacciones distribuidas.Cuando una sola operación abarca dos servicios (cobrar al cliente y luego actualizar el inventario), se necesitan sagas o patrones de coherencia eventuales. Estos son complejos de construir y difíciles de depurar.
• Observabilidad superior.Una sola solicitud puede afectar a 6 servicios. Sin seguimiento distribuido (Jaeger, Zipkin o Datadog APM), depurar una solicitud fallida significa buscar en 6 flujos de registro separados con la esperanza de correlacionar marcas de tiempo.
• Complejidad de la implementación.Necesita orquestación de contenedores (Kubernetes o ECS), descubrimiento de servicios, puertas de enlace API y canalizaciones de CI/CD para cada servicio. Un oleoducto se convierte en 15.
• Desafíos de coherencia de datos.Cada servicio es dueño de su base de datos. Unir datos entre servicios significa llamadas API, no uniones SQL. La presentación de informes se convierte en un proyecto de ingeniería, no en una consulta.

Ninguno de estos problemas es irresoluble. Pero cada uno añade horas de ingeniería, costos de infraestructura y complejidad operativa que un monolito no conlleva.

El monolito está bien hasta que deja de estarlo.

Cuatro señales específicas le indican que su monolito se ha quedado pequeño:

1. Implementar conflictos de frecuencia

El equipo A necesita enviar una solución de facturación hoy. La característica a medio terminar del Equipo B está en el mismo proceso de implementación y rompe la etapa de preparación. El equipo A espera. El equipo B se apresura a arreglar su código. Ambos se envían más tarde de lo previsto. Cuando esto sucede una vez al mes, es una molestia menor. Cuando sucede dos veces por semana, se pierden días de tiempo de ingeniería debido a gastos generales de coordinación.

2. Equipos pisándose unos a otros

Fusionar conflictos en módulos compartidos. Dos equipos cambian el mismo esquema de base de datos en el mismo sprint. Revisiones de código que requieren contexto de tres áreas de características diferentes. Estas son señales de que su código base ha crecido más allá de lo que un solo equipo puede poseer. Cuando los ingenieros dedican más tiempo a coordinar que a codificar, el monolito lo está frenando.

3. El error de un módulo acaba con todo

Una pérdida de memoria en el código de procesamiento de imágenes bloquea toda la aplicación, incluido el pago. Una consulta lenta a la base de datos en el módulo de informes degrada los tiempos de respuesta de la API para todos los usuarios. En un monolito, los módulos comparten recursos. Una falla en un componente se transmite en cascada a todos los demás componentes. Si su ruta de ingresos más crítica (pago, pagos, API principal) está siendo interrumpida por fallas en módulos menos críticos, esa es una señal clara.

4. Ampliar una función significa ampliar toda la aplicación

Su módulo de transcodificación de video necesita 8 veces la CPU de su capa API. Pero se implementan como una sola unidad, por lo que estás ejecutando 8x CPU para toda tu aplicación para satisfacer las necesidades de un componente. Su factura de infraestructura es entre 5 y 10 veces mayor de lo necesario porque no puede escalar los componentes de forma independiente.

Si experimenta dos o más de estas señales de manera constante, es hora de comenzar a pensar en la extracción. No es una reescritura completa. Extracción.

Señales de que NO estás preparado para los microservicios

Antes de empezar a planificar una migración, comprueba estas cinco condiciones. Si alguno de ellos se aplica, quédese con su monolito.

• Tienes menos de 5 ingenieras.Los microservicios resuelven problemas de coordinación de equipos. Un equipo de 3 no tiene problemas de coordinación; Tiene un canal Slack y una pizarra. Los gastos generales de ejecutar una infraestructura distribuida consumirán entre el 30 y el 40 % de la capacidad de su pequeño equipo.
• Presta servicios a menos de 10.000 usuarios.Con poco tráfico, un único servidor maneja todo cómodamente. Los microservicios añaden latencia (saltos de red entre servicios) y complejidad sin proporcionar beneficios de escalamiento significativos en este volumen.
• No tienes experiencia en DevOps en el equipo.Los microservicios requieren orquestación de contenedores, configuración de malla de servicios, registros distribuidos y canales de implementación automatizados. Sin alguien que haya operado estos sistemas en producción, pasará meses construyendo infraestructura en lugar de funciones.
• No tiene ningún control ni observabilidad implementado.Si no puede rastrear una solicitud a través de su monolito hoy, definitivamente no podrá rastrearla en 10 servicios mañana. Configure el registro estructurado, el seguimiento de errores (Sentry) y el monitoreo del rendimiento de las aplicaciones (Datadog, New Relic) antes de dividir algo.
• No ha definido límites claros de los módulos en su monolito.Si su código es una red enredada donde el módulo de facturación lee directamente la tabla de sesiones del usuario y el sistema de notificación escribe en la base de datos de pedidos, extraer un servicio será una pesadilla. Limpia los límites primero.

El camino migratorio: el patrón del higo estrangulador

El mayor error que cometen los equipos es intentar reescribir Big Bang. Pasan entre 6 y 12 meses reconstruyendo todo el sistema como microservicios mientras el monolito sigue funcionando en producción. Cuando la reescritura está "terminada", el monolito tiene entre 6 y 12 meses de nuevas características que la reescritura no tiene. La reescritura nunca se pone al día. El proyecto se cancela. El equipo está desmoralizado.

El patrón del higo estrangulador evita esto por completo. Este enfoque, que lleva el nombre de la higuera estranguladora que crece alrededor de un árbol huésped y lo reemplaza gradualmente, funciona en tres pasos:

• Paso 1:Identifique un componente para extraer. Enrute su tráfico a través de una puerta de enlace API o un proxy.
• Paso 2:Construya el nuevo servicio junto al monolito. Ambos funcionan en producción simultáneamente. El proxy enruta el tráfico al nuevo servicio para el componente extraído y al monolito para todo lo demás.
• Paso 3:Una vez que el nuevo servicio maneje el 100% de su tráfico de manera confiable, elimine el código anterior del monolito. Repita con el siguiente componente.

Este enfoque conlleva un riesgo bajo porque nunca se reemplaza todo el sistema a la vez. Si el nuevo servicio tiene problemas, el proxy enruta el tráfico de regreso al monolito. Los usuarios nunca se dan cuenta.

Qué extraer primero

Tienes dos buenas opciones para tu primera extracción:

Opción A: El componente que cambia con más frecuencia.Mira tu registro de git. ¿Qué directorio tiene más confirmaciones en los últimos 6 meses? Ese es el componente que causa la mayoría de los conflictos de implementación. Extraerlo brinda a sus equipos independencia de implementación inmediata.

Opción B: el componente que necesita escalamiento independiente.Si su módulo de procesamiento de video consume 10 veces los recursos de su capa API, extraerlo le permite escalar (y pagar) cada componente de forma independiente. Los ahorros de costos por sí solos pueden justificar el esfuerzo de migración.

No empieces con el componente más complejo. No comience con el componente que tenga más dependencias de otros módulos. Elija algo con límites claros, una superficie API clara y un equipo que esté listo para manejarlo de principio a fin. Su primera extracción es tanto un ejercicio de aprendizaje como una mejora arquitectónica.

Errores comunes que acaban con las migraciones de microservicios

Extraer demasiados servicios demasiado rápido

Los equipos se emocionan después de su primera extracción exitosa e intentan dividir todo a la vez. De repente, están ejecutando 12 servicios con 12 canales de implementación, 12 conjuntos de registros y 12 puntos potenciales de falla. La carga operativa abruma al equipo. Extraiga un servicio, ejecútelo en producción durante 4 a 6 semanas, aprenda de los desafíos operativos y luego extraiga el siguiente.

El monolito distribuido

Este es el modo de falla más común. Divide su aplicación en 8 servicios, pero todos comparten la misma base de datos. Todos se implementan juntos porque los cambios en un servicio requieren cambios de esquema que afectan a los demás. Tiene toda la complejidad operativa de los microservicios sin ninguno de los beneficios. Cada servicio debe poseer sus datos por completo. Si dos servicios necesitan los mismos datos, se comunican a través de API o eventos, no de tablas compartidas.

Sin malla de servicios ni observabilidad

Ejecutar microservicios sin rastreo distribuido es como conducir de noche con las luces apagadas. No sabrá que un servicio se está degradando hasta que los usuarios se quejen. No sabrá qué servicio causó una falla sin buscar manualmente en múltiples flujos de registro. Antes de extraer su primer servicio, configure el seguimiento distribuido, el registro centralizado y los puntos finales de verificación de estado. Esta no es una infraestructura opcional. Es un requisito previo.

Comparación de costos: monolito versus microservicios

La diferencia de costos de infraestructura entre estas arquitecturas es significativa y los equipos la subestiman constantemente.

Estos rangos reflejan empresas emergentes en etapa intermedia y empresas en etapa de crecimiento. Las implementaciones a escala empresarial pueden ejecutarse a mayor nivel en ambos extremos.

El coste de la infraestructura es la parte visible. El costo oculto es el tiempo de ingeniería. Un equipo que ejecuta microservicios gasta entre el 20% y el 30% de su capacidad en tareas operativas: actualizar las configuraciones de Kubernetes, depurar la comunicación entre servicios, administrar las migraciones de bases de datos en múltiples servicios y mantener los canales de CI/CD. Ese es tiempo de ingeniería que no se destina a funciones que interesan a sus usuarios.

El término medio del "monolito modular"

Hay una tercera opción que la mayoría de los artículos de arquitectura omiten: el monolito modular. Mantiene una única unidad desplegable pero impone límites estrictos a los módulos dentro de ella.

Cada módulo posee sus propias tablas de base de datos (o esquema). Los módulos se comunican a través de API internas bien definidas, sin acceder a las tablas de bases de datos de los demás ni llamar a funciones privadas. El código está organizado de modo que extraer un módulo en un servicio independiente requiere cambiar la capa de transporte (de llamadas a funciones en proceso a HTTP/gRPC) sin reescribir la lógica empresarial.

El monolito modular le brinda la mayoría de los beneficios organizacionales de los microservicios (propiedad clara, desarrollo independiente dentro de los módulos, límites impuestos) sin el costo operativo. Despliegas un artefacto. Ejecuta un servidor de base de datos. Busca una secuencia de registros.

La arquitectura de Shopify es el ejemplo más conocido. Ejecutan una aplicación Rails monolítica con límites de módulo estrictamente aplicados. Cuando un módulo necesita convertirse en un servicio (debido a requisitos de escalamiento o necesidades de independencia del equipo), la extracción es sencilla porque los límites ya están claros.

Para equipos de entre 5 y 30 ingenieros, el monolito modular suele ser la respuesta correcta. Obtiene la estructura y disciplina del pensamiento de microservicios sin pagar el impuesto operativo y de infraestructura.

Lo que recomienda Savi

Hemos creado monolitos, monolitos modulares y arquitecturas de microservicios para clientes de fintech, comercio electrónico y SaaS. Aquí está el libro de jugadas que seguimos:

• Empiece monolítico.Cada nuevo producto comienza como un monolito. La prioridad son las funciones de envío, la validación del mercado y la iteración rápida. La pureza arquitectónica no importa si nadie utiliza su producto.
• Haga cumplir los límites del módulo desde el primer día.Incluso en un monolito, cada módulo debe poseer sus datos y exponer una interfaz clara. Esto no cuesta casi nada por adelantado y ahorra meses de refactorización posterior.
• Configure la observabilidad con anticipación.Registro estructurado, seguimiento de errores y supervisión básica del rendimiento. Lo necesita tanto si permanece monolítico como si migra. Son apuestas de mesa.
• Extraiga los servicios sólo cuando aparezca un dolor específico.Conflictos de implementación que bloquean las versiones. Contención de recursos entre módulos. Los gastos generales de coordinación del equipo consumen la capacidad de ingeniería. Éstas son señales reales, no preocupaciones teóricas.
• Utilice el patrón de higo estrangulador para la extracción.Un servicio a la vez. Ejecútelo junto al monolito. Valida que funcione. Luego pasa al siguiente. Nunca hagas una reescritura de Big Bang.
• Considere el monolito modular como su arquitectura a largo plazo.Para muchos productos, es lo mejor de ambos mundos. Sólo se pasa a verdaderos microservicios cuando la restricción de implementación única del monolito modular se convierte en el cuello de botella.

La mejor arquitectura es la que permite a su equipo ofrecer las características que sus clientes desean. Para la mayoría de las empresas, en la mayoría de las etapas, se trata de un monolito bien estructurado. Para algunas empresas, en ciertos puntos de inflexión, se trata de una extracción dirigida de servicios específicos. Para muy pocas empresas, se trata de una arquitectura de microservicios completa.

No elija su arquitectura en función de lo que usa Netflix o Uber. Elíjalo según el tamaño de su equipo, sus patrones de tráfico, su frecuencia de implementación y los cuellos de botella específicos que enfrenta hoy. No los cuellos de botella que podrían encontrarse en dos años.

Preguntas frecuentes