Arquitectura y escenarios Decoupled
Hemos hablado mucho sobre terminología Decoupled, arquitectura desacoplada, en los últimos años y parece que recientemente se está extendiendo en muchas infraestructuras y organizaciones, gracias a conceptos como Decouple CMS, Headless, Composable, Microservicios, entre otros. Es por ello que hoy quiero compartir contigo la base de la arquitectura desacoplada, decoupled en inglés, para comprender de base cuáles són los objetivos fundamentados de estas nuevas arquitecturas, frameworks y conceptos.
¿Qué es el desacoplamiento?
Se habla mucho sobre el desacoplamiento de arquitecturas, principalmente debido a los problemas técnicos que las grandes arquitecturas monolíticas pueden estar generando a la hora de actualizarlas. Y, por otro lado, por un mayor enfoque en las transformaciones digitales y la agilidad, los proyectos deben entregarse más rápido que antes, pero aún más deben interconectarse con sistemas de terceros.
Existe confusión sobre lo que abarca el desacoplamiento, pero la definición es muy sencilla: el desacoplamiento es tomar una funcionalidad o un conjunto de funcionalidades de una aplicación existente y hacerla completamente independiente para que pueda actuar y desarrollarse por sí misma.
El desacoplamiento es la evolución en el diseño de sistemas
¿Por qué el desacoplamiento es tan popular ahora? Tiene mucho que ver con cómo se diseñaron los sistemas y con qué propósito. Antiguamente, los sistemas se diseñaban como grandes silos monolíticos donde todas las funcionalidades, servicios y datos formaban parte del mismo sistema. Estos mainframes eran robustos y sólidos como una roca, ya que los cimientos del sistema se optimizaron para ese propósito específico para operar las 24 horas del día, los 7 días de la semana y recuperarse automáticamente en caso de fallas.
La segunda generación de diseño de software es donde la atención se centró en la eficiencia y la reutilización. Las aplicaciones se desarrollaron en capas separando presentación, funcionalidades, integraciones y datos. Cada capa tiene su propia autonomía en su diseño y construcción general.
La ventaja de este tipo de soluciones es que las funcionalidades y los datos pueden diseñarse y desarrollarse por separado teniendo en cuenta la reutilización. Pero la desventaja es que si uno cambiara un componente pequeño, aún necesita probar las dependencias en sus capas superior e inferior. Por ejemplo, a uno le gustaría actualizar un componente de integración, este componente específico aún depende de los datos en la capa de datos y podría afectar el funcionamiento de la lógica en la capa anterior. Entonces, para cualquier pequeño cambio, la arquitectura aún no es ágil, ya que debe probarse e implementarse como una unidad aún más grande.
Principalmente con el auge de las nuevas plataformas de Internet, se demostró que la agilidad aún puede ser parte de los grandes sistemas. El enfoque es identificar los componentes que necesitan agilidad o autonomía y aislar ese componente específico. Este nuevo componente debe diseñarse para que tenga sus propios datos y lógica y, de esa manera, sea independiente de su aplicación madre. Con eso, el Core sigue funcionando y la nueva funcionalidad más pequeña se puede cambiar sin depender de la plataforma del sistema más grande.
¿Cómo desacoplar?
Para desacoplar funcionalidades de un sistema existente, existen múltiples patrones que se pueden usar y la mejor manera de explicar el desacoplamiento es con varios ejemplos. Tomamos en este caso una aplicación que tiene un problema con 2 de un total de 6 funcionalidades. El problema puede deberse a varias razones:
- baja agilidad o flexibilidad (el sistema grande no se puede cambiar rápidamente en producción ya que las versiones del sistema son grandes y engorrosas),
- mala robustez (fallo del componente),
- bajo rendimiento (respuesta lenta),
- baja escalabilidad (no es capaz de manejar más usuarios o transacciones),
- etc.
Hay cuatro patrones principales para desacoplar como muestra el diagrama anterior:
1. Duplicar la aplicación
En este caso, el sistema original se copia y duplica por completo, pero solo para las funcionalidades problemáticas específicas. Por lo tanto, se puede cambiar rápidamente sin depender de su aplicación principal. Las funcionalidades están separadas y no se requiere una nueva compilación de desarrollo.
Sin embargo, como ahora tenemos 2 aplicaciones, esta solución puede ser más costosa debido a la infraestructura adicional requerida. Además, debes considerar y revisar la replicación y sincronización de datos y la integración entre la nueva aplicación copiada y su sistema original que podría ser más desafiante en complejidad y esfuerzo.
Este escenario se recomienda cuando el coste no es un problema y la lógica de las funcionalidades específicas es muy difícil de separar.
2. Aislar mediante Microservicios
Otra forma de desacoplar es aislar los servicios a través de microservicios. Se podrían separar las funcionalidades en servicios autónomos y proporcionar independencia y agilidad a través de este patrón con una solución mucho más rentable que la duplicación de aplicaciones debido a su pequeña huella de estos servicios.
Sin embargo, este escenario necesita desarrollo adicional para construir los servicios. También debes tener una revisión cuidadosa de la replicación, sincronización e integración de datos, ya que las nuevas funcionalidades tienen sus propios datos y pueden conectarse con los datos de tu aplicación "core". Entonces, si un cliente, por ejemplo, cambia su dirección en un microservicio recién creado, ¿cómo podemos asegurarnos de que la nueva dirección se actualice en el sistema original?
Este patrón se recomienda si solo se involucran algunas funcionalidades que no son demasiado complejas.
3. Desarrollar una nueva aplicación
Este escenario permite crear una pequeña aplicación nueva para aislar los servicios que funcionan mal. Esto aún podría lograrse mediante el uso de microservicios, pero dentro de un entorno de aplicación para que los datos estén centralizados y no almacenados dentro de cada microservicio. Una vez que un servicio necesita actualizar los datos, escribirá en la base de datos de la aplicación recién creada. Esto garantiza que las funcionalidades específicas estén separadas de su sistema original y proporciona una arquitectura más coherente y consistente.
Aún así, este entorno necesita un desarrollo adicional e implica una revisión cuidadosa de la replicación, sincronización e integración de datos, pero como los datos están centralizados, es más fácil ya que necesita sincronizar solo entre la base de datos nueva y la original si es necesario.
Este patrón es la mejor recomendación cuando las aplicaciones necesitan desacoplar un gran conjunto de funcionalidades que son complejas y/o dependientes entre sí.
4. Desacoplamiento del tráfico
Los tres patrones anteriores son buenas alternativas para resolver problemas. En todos los casos se supone que el tráfico para la funcionalidad específica se dirige al sistema nuevo o al original.
Sin embargo, un patrón secundario podría ser el de aplicar el desacoplamiento del tráfico. En este escenario, uno tendría una funcionalidad duplicada (con cualquiera de los tres patrones mencionados anteriormente), pero en lugar de dirigir el tráfico de funcionalidad a un sistema específico, dirigirías un volumen específico a un sistema y el volumen restante al otro sistema.
Esto podría ser, por ejemplo, que una empresa sepa que el 90% del tráfico está buscando el precio del vuelo entre Londres y Nueva York, y el tráfico restante para consultar otros precios de vuelos. Entonces, el 90% del tráfico podría dirigirse al sistema recién creado y construirse de manera muy robusta y escalable, mientras que el volumen restante lo maneja el sistema original. En este escenario, podemos optimizar y ajustar el nuevo sistema para el rendimiento y el sistema original se puede aligerar debido a un tráfico menos pesado.
Las desventajas son que las transacciones pueden ocurrir tanto en el sistema nuevo como en el antiguo, por lo que es necesario crear un traspaso de datos. Y sigue siendo más costoso que la solución original debido a la infraestructura adicional requerida. Como en los otros casos, necesita una revisión cuidadosa de la replicación, sincronización e integración de datos.
El mejor uso para este patrón es cuando se deben aliviar los volúmenes de tráfico intenso que afectan el rendimiento del sistema original.
Conclusión
Por lo tanto, el desacoplamiento se puede utilizar para varios casos de uso, como duplicar la aplicación, aislar mediante microservicios, desarrollar una aplicación o desacoplar el tráfico, cada patrón tiene sus pros y contras pero específicamente un objetivo, dependerá de tu caso de uso utilizar un patrón u otro. Recuerda que el objetivo principal de la arquitectura decoupled es mejorar el rendimiento, la robustez y la escalabilidad.