De Monolito a Microservicios: Una Guia Practica

El trabajo tecnico de extraer un microservicio suele ser la parte facil. Lo dificil es que la mayoria de los equipos intentan resolver un problema organizacional - un equipo de ingenieria creciente que se pisa los cambios entre si - con una solucion puramente tecnica, y terminan con un monolito distribuido que tiene toda la complejidad operativa de los microservicios y ninguno de los beneficios de independencia.

El diseno dirigido por dominio te da el vocabulario para encontrar limites reales, pero el ejercicio practico es mas mundano: mapear que tablas se leen y escriben juntas, que capacidades de negocio cambian por las mismas razones, y donde el organigrama de tu equipo ya crea divisiones naturales. La Ley de Conway no es una observacion simpatica, es una restriccion: un limite de servicio que corta a traves del trabajo diario de un solo equipo te va a pelear todos los dias, mientras que uno que coincide con como ya esta organizado el equipo se sentira casi invisible una vez implementado.

El patron strangler fig es el mecanismo de extraccion correcto porque te permite validar el limite antes de comprometerte con el. Enruta una porcion del trafico al nuevo servicio, mantén la ruta de codigo anterior como respaldo, y solo elimina la implementacion del monolito una vez que el nuevo servicio ha demostrado su valor bajo trafico real de produccion. Esto tambien significa que nunca tienes un periodo de varias semanas donde el sistema esta en un estado medio migrado y doblemente fragil: para cualquier peticion dada, o esta completamente en la ruta antigua o completamente en la nueva.

La parte que siempre se subestima son las operaciones. Una sola transaccion de base de datos que garantizaba consistencia en el monolito se convierte en un problema de transaccion distribuida, o mas realistamente, en un problema de consistencia eventual que ahora tu codigo de aplicacion tiene que razonar explicitamente. El tracing distribuido deja de ser un nice-to-have en el momento en que una sola peticion de usuario toca cuatro servicios, porque sin el, un incidente de produccion se convierte en una busqueda del tesoro por cuatro conjuntos de logs en lugar de uno.

La prueba que uso antes de extraer cualquier servicio es simple: puedo nombrar el beneficio especifico y medible - desplegabilidad independiente, la capacidad de escalar una funcionalidad por separado, un equipo que ya no esta bloqueado por el ciclo de release de otro equipo? Si la respuesta es 'mejor arquitectura' en abstracto, el limite todavia no esta listo.

Puntos Clave

• Los microservicios usualmente resuelven primero un problema organizacional, y uno tecnico despues.
• La Ley de Conway es una restriccion: los limites de servicio deben coincidir con como ya esta organizado el equipo.
• El patron strangler fig te permite validar un limite bajo trafico real antes de comprometerte con el.
• El tracing distribuido se vuelve obligatorio en cuanto una sola peticion toca varios servicios.
• Cada extraccion necesita un beneficio concreto y medible, no solo pureza arquitectonica.