Después de revisar los artículos pasados, Arquitectura y escenarios Decoupled y Desacoplamiento con BiModal IT, uno podría discutir por qué no desacoplar toda mi infraestructura y convertir todas las aplicaciones en servicios más pequeños desacoplados. He tenido esa discusión con muchos CIOs y CTOs y la respuesta está en hacer un balance cuidadoso para optimizar y gestionar la complejidad de tu ecosistema empresarial.
Beneficios de Decoupled
Los beneficios del desacoplamiento es que, al ser un componentes completamente autónomos, tiene su propio ciclo de vida. Puedes desarrollar, probar e implementar el componente desacoplado sin depender de una aplicación más grande, lo que es muy beneficioso para:
1. Agilidad
Como el microservicio se puede desarrollar e implementar por separado, tiene su propia velocidad y agilidad. Puedes desarrollarlo o cambiarlo rápidamente e implementarlo en producción.
2. Aislamiento de funcionalidades
Las partes problemáticas de la aplicación se pueden aislar, reparar y mantener, mientras que la aplicación más grande puede continuar sin ningún cambio.
3. Escalabilidad y rendimiento
Se pueden agregar más recursos de infraestructura al microservicio específico para que pueda actuar con un mejor rendimiento, sin agregar servidores a toda la aplicación.
4. Disponibilidad
El microservicio específico se puede implementar con mayor disponibilidad que los otros componentes, por ejemplo, 24 horas x 7 días, mientras que la parte restante de la aplicación tiene una disponibilidad menor para ahorrar recursos. Como puede funcionar de forma autónoma, puede diseñarse para tener su propio ecosistema.
5. Metodología ágil y equipo
Microservicios es ideal para trabajar con un equipo ágil, ya que actúa por sí solo y puede desarrollarse “independientemente” de otros componentes.
Inconvenientes de Decoupled
Sin embargo, existen inconvenientes, además de que el uso de microservicios ayudará a que la arquitectura sea más ágil, también se vuelve más compleja debido a:
1. Complejidad arquitectónica
Cada microservicio es un componente autónomo por sí mismo y, por lo tanto, la relación de la arquitectura debe diseñarse bien para garantizar que encaje bien con los demás componentes. A medida que el sistema se vuelve más distribuido con microservicios, introduce un nivel adicional de complejidad debido a un manejo de errores más complejo, latencia y dependencia de la calidad de la red, control de versiones, entre otras cosas.
2. Ciclo de vida de los microservicios
Como cada microservicio tendrá su propio ciclo de vida, las versiones deben mantenerse bien y se requiere una estructura de gobierno de arquitectura sólida para garantizar que las diferentes versiones de los microservicios continúen funcionando correctamente juntas como un todo.
3. DevSecOps
Como cada servicio tiene su propia autonomía en el desarrollo y la implementación, necesita una implementación de DevSecOps de alta calidad que admita la implementación, el monitoreo, las operaciones y el mantenimiento de cada uno de estos servicios.
4. Complejidad de datos
A medida que los datos se distribuyen en múltiples microservicios, los datos deben interconectarse a través de relaciones, y es necesario fortalecer la arquitectura y la gobernanza de datos en general.
5. Interoperabilidad
Los microservicios son creados por diferentes equipos y dependen de las interacciones entre ellos. Por lo tanto, implica que debe haber un compromiso muy estrecho entre los equipos para garantizar que las especificaciones se diseñen y construyan correctamente, no solo durante el diseño, sino también cuando se realicen cambios más adelante para evitar problemas de interoperabilidad.
Unos pocos componentes desacoplados recién agregados se pueden supervisar con facilidad, pero para una mayor cantidad de componentes desacoplados, la complejidad crece exponencialmente por su arquitectura general, integración de datos y mantenibilidad.
Conclusión
Por lo tanto, es evidente que la estrategia de desacoplamiento debe decidirse cuidadosamente para aplicarse sólo donde sea necesario. Un buen arquitecto de sistema debe encontrar el equilibrio adecuado sobre cómo y cuántos microservicios usar. La recomendación es usar un mínimo de microservicios y aplicar solo donde sea necesario.
Para aplicaciones menos complejas, los diseños sin desacoplamiento siempre son mejores tanto a largo como a corto plazo. Y para aplicaciones complejas, el desacoplamiento puede dar sus frutos con el tiempo, pero se necesita mucho tiempo para compensar la inversión adicional en integración y gobernanza requerida para hacerlo.
La clave es diseñar una arquitectura desacoplada bien definida en lugar de desacoplar todos los componentes para evitar problemas de alta complejidad y mantenimiento en el futuro.
