Uno de los factores que en su momento impulsó a los microservicios como arquitectura fue la ventaja del decoupling (desacoplamiento) que ofrece entre servicios. Bien implementado, minimiza los efectos en cascada que un problema en un sistema podría generar en otros.
Sin embargo, en muchos casos tendremos que lidiar con el coupling (acoplamiento) entre sistemas o módulos, especialmente si estamos construyendo sobre sistemas existentes e integraciones, algo cada vez más frecuente. Entender cuáles son las dimensiones de este acoplamiento nos ayudará a navegar este desafío.
Las dimensiones del coupling
Parte de la razón por la que decidí tocar este tema ahora fue escuchar al brillante Vlad Khononov en un episodio de Tech Lead Journal hablar sobre su nuevo libro y el abordaje que le hace al tema. ¡Muy recomendable!
En su exposición, hace un repaso de conceptos que todos conocemos, pero les da una definición que permite articular ideas bastante interesantes para tener presentes. Una de ellas es hablar de tres dimensiones del coupling:
Fortaleza de la integración
Al conectar sistemas, es inevitable que se necesite conocer algunas características del otro. Cuanto más detallada sea la información que uno de los sistemas debe conocer sobre el otro para integrarse, mayor será la fortaleza de esa integración.
Distancia
En este contexto, hablamos de distancia de manera no formal, intentando medir qué tan grande es el esfuerzo cognitivo para lidiar con ambos sistemas simultáneamente y qué tanta coordinación se requiere. Menor distancia implica menos esfuerzo cognitivo y menos coordinación para realizar un cambio en ambos sistemas.
Dos microservicios suelen estar más distantes: resuelven problemas separados, quizás con tecnologías diferentes y con equipos distintos. En cambio, dos módulos dentro de un monorepo tienden a ser más cercanos: usan la misma tecnología, mantienen una relación más estrecha con el negocio y suelen ser gestionados por el mismo equipo.
Volatilidad
¿Qué tan propenso es a cambiar uno de los componentes? ¿Qué tanto se verá afectada la integración?
Navegando el desafío
Una de las consecuencias más interesantes de este concepto es que permite incorporar un análisis más preciso al evaluar alternativas cuando trabajamos con sistemas existentes.
¿Es mala una integración a nivel de base de datos con otro sistema? Aunque la respuesta habitual es que sí, también es cierto que hay grados de “qué tan mala” es esa integración. ¿Es un sistema legacy que no ha cambiado en los últimos cuatro años? Quizás el costo no es tan alto y nos permite ser eficientes en la implementación de una solución.
Otras definiciones que te invito a escuchar directamente de Vlad, son sobre que es complejo y qué es complicado. Una mirada intuitiva sobre el tema que creo nos ayuda a lograr consensos de cómo tomar decisiones en un escenario que no sea una hoja en blanco.
Juan Saavedra 