Migración de Microservicios: Ejemplo de una empresa

Un ejemplo de migración a microservicios de una empresa rara vez es la historia de una valiente reescritura del Big Bang. En la práctica, la modernización generalmente comienza donde la presión es más alta: los lanzamientos tardan semanas, pequeños errores pueden paralizar funciones enteras o el crecimiento de un producto digital ya no puede manejarse de manera rentable con la arquitectura existente. Lo crucial no es construir la mayor cantidad de servicios posible. Lo más importante es llevar cambios funcionales a producción más rápido y con un riesgo operativo calculable.

Esto es especialmente relevante para las empresas medianas. Un monolito que ha crecido no es automáticamente un problema. Se convierte en un problema cuando genera dependencias entre equipos, la escalabilidad se vuelve innecesariamente costosa o cada ajuste provoca un esfuerzo desproporcionado en pruebas y aprobación. En ese caso, puede ser sensato realizar una migración gradual a microservicios, siempre que se consideren conjuntamente la arquitectura, la operación de la plataforma y la organización.

Microservicios y migración: Ejemplo de una empresa típica

Imaginemos un comerciante B2B mediano con su propia plataforma de comercio electrónico. La empresa gestiona cuentas de clientes, lógicas de precios, pedidos, inventarios, facturas e interfaces con el ERP en una aplicación central. El sistema ha crecido a lo largo de los años, es valioso desde el punto de vista funcional y, en general, estable. Sin embargo, un nuevo portal de clientes necesita ofrecer surtidos individuales, disponibilidad en tiempo real y procesos de oferta más rápidos.

Las dificultades no surgen en funciones individuales, sino en las dependencias: un cambio en el servicio de precios afecta a todo el lanzamiento. Los picos de carga en el catálogo de productos consumen los mismos recursos que el proceso de pago. El ERP a veces responde lentamente y, en el peor de los casos, bloquea los procesos de pedido. Al mismo tiempo, solo unos pocos desarrolladores pueden cambiar de manera confiable las partes críticas de la aplicación.

La reacción incorrecta sería reemplazar completamente el monolito y trasladar todas las áreas funcionales a contenedores de forma paralela. Un proyecto de este tipo consume capital, prolonga el tiempo hasta el primer beneficio comercial y a menudo genera dos sistemas inestables en lugar de uno modernizado. El mejor enfoque es comenzar el cambio en un punto que sea funcionalmente claro y comercialmente relevante.

En este ejemplo, las consultas de disponibilidad e inventario son adecuadas. Se utilizan en gran medida, deben responder con rapidez y tienen una tarea claramente delimitada. Un servicio independiente puede tomar los inventarios del ERP, procesarlos y ponerlos a disposición tanto para la tienda como para el portal de clientes. El monolito seguirá siendo el sistema principal para pedidos y facturación en un principio. La nueva función se consumirá a través de una API, mientras se alivia gradualmente el sistema existente.

El camino desde la aplicación existente hasta el primer servicio

Al principio no hay una decisión tecnológica, sino un inventario sólido. Los equipos deben saber qué procesos funcionales están en el monolito, qué flujos de datos existen y dónde se generan verdaderos cuellos de botella. Las dependencias invisibles son especialmente importantes: tablas de bases de datos compartidas, trabajos por lotes, procesos operativos manuales e interfaces cuyo comportamiento de error no ha sido documentado por nadie.

Luego, se selecciona un primer servicio de manera que cumpla con tres condiciones: resuelve un problema comercial concreto, su responsabilidad funcional es comprensible y su desvinculación no pone en peligro el funcionamiento central. Esto puede ser la sincronización del inventario, pero también notificaciones, generación de documentos o una función de búsqueda. Un servicio para "clientes", en cambio, suele ser demasiado amplio, ya que los datos de los clientes pueden tener significados diferentes en ventas, facturación y soporte.

Para el servicio de inventario se establecen responsabilidades claras. Proporciona cantidades disponibles y marcas de tiempo, pero no crea pedidos ni emite facturas. El servicio recibe sus datos a través de eventos o interfaces controladas del ERP. Si el ERP falla a corto plazo, aún puede entregar el último inventario conocido: visible como un valor potencialmente desactualizado. Esta decisión es funcional y técnica a la vez: para ciertos productos, una visualización retrasada es aceptable, pero para productos escasos puede que no lo sea.

La base de datos permanece con el respectivo servicio. Esta es una de las partes más exigentes de una migración a microservicios. Una base de datos compartida parece práctica a corto plazo, pero lleva a que los servicios sigan vinculados implícitamente. Mantener datos propios no significa duplicar datos sin definir reglas. Significa diseñar de manera consciente la soberanía de los datos, la actualización y los casos de error.

La operación de la plataforma decide sobre el beneficio

Un solo servicio desacoplado ofrece poco valor si su operación genera más esfuerzo manual que el monolito. Por lo tanto, la plataforma objetivo debe formar parte del alcance de la migración desde el primer servicio productivo. La contenedorización por sí sola no es suficiente. Los equipos necesitan entornos reproducibles, implementaciones automatizadas, configuraciones trazables y una base de seguridad que no necesite ser revisada de nuevo con cada lanzamiento.

En la práctica, esto incluye una tubería CI/CD con pruebas automatizadas, auditorías de seguridad y artefactos trazables. Infrastructure as Code garantiza que los entornos de desarrollo, prueba y producción no se desvíen. Kubernetes puede ser útil para la escalabilidad y la operación estandarizada, pero no es un programa obligatorio para cada empresa. Con pocos servicios y una carga manejable, un enfoque administrado más ágil puede ser más rentable. La plataforma debe ajustarse a la complejidad del producto y al modelo operativo disponible.

Igualmente pronto, el nuevo Servicio Observability es necesario. Las métricas muestran, por ejemplo, tiempos de respuesta, tasas de error y la demora en la sincronización del ERP. Los registros centrales ayudan a rastrear una llamada fallida a través de varios componentes. Los trazados se vuelven relevantes cuando una solicitud de usuario pasa por varios servicios. Sin esta transparencia, la migración simplemente desplaza los errores a un entorno más difícil de diagnosticar.

Para el comerciante B2B, una métrica productiva podría ser: el servicio de inventario debe atender el 99.9 por ciento de sus solicitudes dentro de un tiempo de respuesta definido. Además, se monitorea la antigüedad de los datos de inventario. De esta manera, el equipo de operaciones no solo detecta una falla técnica, sino también una demora crítica desde el punto de vista funcional en el suministro de datos.

Lo que cambia después del primer paso productivo

Una vez que el servicio de inventario es estable en funcionamiento, la empresa se beneficia de inmediato. El portal de clientes puede mostrar disponibilidades sin cargar al monolito en cada solicitud. La función se puede escalar de manera independiente. Los ajustes en cachés, formatos de visualización o intervalos de sincronización pueden ser implementados en un ciclo de lanzamiento más pequeño.

Al mismo tiempo, surgen nuevas responsabilidades. Los equipos deben gestionar las versiones de las APIs de manera ordenada, clarificar responsabilidades por fallas y documentar el conocimiento operativo. Un error en una arquitectura distribuida no siempre se manifiesta como una falla clara. Puede aparecer como un mensaje retrasado, un pedido procesado dos veces o un estado de datos contradictorio. Por lo tanto, los procesos funcionales requieren mecanismos para repeticiones, procesamiento idempotente y compensación controlada.

Solo cuando el primer servicio funciona técnica y organizativamente, se avanza a la siguiente área. En el ejemplo, podrían seguir los datos del producto o la búsqueda, ya que estas funciones también generan alta carga y pueden desarrollarse de manera independiente. La gestión de pedidos puede permanecer más tiempo en el monolito porque agrupa muchas reglas comerciales críticas. Esto no es un signo de una migración incompleta, sino una priorización consciente basada en riesgo y beneficio.

Cuándo los microservicios son la respuesta equivocada

Los microservicios no son un sello de calidad. Si una aplicación es manejable, un equipo la domina bien y los lanzamientos se realizan de manera confiable, un monolito estructurado de manera modular puede ser la mejor solución. Es más fácil de probar, más fácil de operar y requiere menos infraestructura distribuida.

Incluso en una migración bajo alta presión temporal, se debe tener precaución. Si una empresa primero necesita resolver problemas de estabilidad, responsabilidades poco claras o falta de automatización en los lanzamientos, debería priorizar estas bases. Un monolito con un pipeline CI/CD bien definido, monitoreo y límites de módulo claros puede permitir lanzamientos significativamente más rápidos. Los microservicios refuerzan buenas prácticas de ingeniería, pero no las reemplazan.

La cuestión de los costos también debe ser discutida. Más servicios significan más tuberías, más componentes en ejecución, más monitoreo y más superficie de seguridad. Por lo tanto, una arquitectura sostenible considera desde el principio el FinOps: los recursos se dimensionan adecuadamente, los costos se asignan de manera transparente y las reglas de escalado se revisan periódicamente en función del uso real.

Una migración exitosa no se mide por la cantidad de contenedores, sino por el hecho de que los cambios funcionalmente importantes se vuelven nuevamente planificables. Quien comienza con un dominio claramente delimitado, automatiza consistentemente la operación productiva y mide cada desvinculación adicional en función del beneficio comercial, moderniza sin comprometer la estabilidad del negocio en curso.