No cree microservicios, busque acoplamientos flexibles

Sep 01, 2023

Por: Chris Bertinato el 29 de agosto de 2023

Dado que la demanda de un rendimiento confiable de las aplicaciones siempre está creciendo, no sorprende que muchas empresas construyan sus sistemas pensando en una futura expansión. Muchos expertos de la industria han señalado que los microservicios son la mejor manera de preparar un sistema para el futuro, pero podría ser mejor utilizar el término "servicios del tamaño adecuado", ya que no existe una estrategia única que funcione para todas las empresas en todo momento. . En lugar de pensar en cuál de las últimas tendencias adoptar como estrategia, los equipos deberían reconocer y centrarse en el factor subyacente del acoplamiento. Los sistemas son más flexibles y dinámicos si existe un acoplamiento débil entre los componentes que tienen mayor probabilidad de cambiar.

El acoplamiento, en el contexto de los sistemas, se refiere a cómo se conectan los componentes de un sistema. Las interfaces son necesarias para un acoplamiento flojo. Para los sistemas eléctricos, esas interfaces se implementan como conectores físicos con clavijas y enchufes y protocolos descritos en términos de niveles de voltaje. La analogía de los sistemas de software con un conector eléctrico es una interfaz de programación de aplicaciones (API), que podría implementarse como un conjunto de funciones o recursos basados ​​en HTTP, entre otros. Pero una interfaz por sí sola no es suficiente para un acoplamiento flexible. Esa interfaz también debe ser algo estable, es decir, que un usuario pueda contar con que esa interfaz estará allí, con sus entradas permaneciendo iguales durante mucho tiempo o, al menos, cambiando de manera predecible.

Cuando los componentes de un sistema están débilmente acoplados, esos componentes se pueden cambiar internamente sin alterar significativamente el resto del sistema. Consideremos un ejemplo cotidiano: la bombilla. Los casquillos de las bombillas tienen un tamaño estándar con roscas estándar y un voltaje estándar. La propia bombilla ha evolucionado pasando por varios tipos de materiales, desde el filamento hasta los LED, todo ello sin necesidad de cambiar lámparas ni accesorios de iluminación. Ahora considere un ejemplo simple en sistemas de software: un servidor HTTP y un almacén de datos, como un caché, una cola o una base de datos. En la mayoría de los casos, sería beneficioso colocar una interfaz entre el servidor y el almacén de datos que facilitaría el cambio de la implementación del almacén de datos. Una vez que estos dos componentes están débilmente acoplados, las cosas que probablemente cambien pueden hacerlo sin requerir cambios significativos en las otras cosas.

Si los componentes de su sistema están demasiado entrelazados, incluso el cambio más pequeño podría causar estragos en otra parte del sistema. Podrías comparar esta estructura con un grupo de plantas que crecieron cerca. Debido a que todos los tallos están entrelazados, tratar de cambiar una planta por otra nueva será un desafío, ya que un movimiento en falso podría fácilmente arrancar de raíz muchas otras plantas.

Por el contrario, en un sistema débilmente acoplado, se pueden realizar cambios con la confianza de que cuando un componente experimenta un problema, el resto del sistema seguirá siendo resistente. Esta confianza da como resultado una mayor flexibilidad para realizar cambios, permite un menor tiempo de comercialización de nuevas características y productos y potencialmente ofrece una ventaja competitiva.

Un beneficio corolario del acoplamiento flexible es la capacidad de evolución: cuando las interfaces están ubicadas en los lugares con mayor probabilidad de cambiar, será más fácil que el sistema evolucione. Las interfaces deben ser estables y opacas, de modo que cualquier cosa que suceda detrás de ellas sea generalmente desconocida e irrelevante para el usuario de esa interfaz. Entonces, mientras las interfaces permanezcan estables, los sistemas detrás de ellas son libres de cambiar y, por lo tanto, evolucionar.

Si bien es cierto que las estrategias de microservicios admiten un acoplamiento flexible, no son la única manera. Las estrategias arquitectónicas más simples pueden brindar a los proyectos más pequeños o más nuevos los beneficios del acoplamiento flexible de una manera más sostenible, generando menos gastos generales que la construcción de una infraestructura centrada en microservicios.

Las elecciones arquitectónicas tienen tanto que ver con el componente humano de la construcción y operación de sistemas de software como con preocupaciones técnicas como la escalabilidad y el rendimiento. Y el componente humano es donde los microservicios pueden quedarse cortos.

Al diseñar un sistema, se debe distinguir entre complejidad intencional (donde un problema complejo exige legítimamente una solución compleja) y complejidad no intencional (donde una solución demasiado compleja crea desafíos innecesarios). Es cierto que empresas como Netflix se han beneficiado enormemente de las arquitecturas basadas en microservicios con una complejidad intencionada. Pero una startup prometedora no es Netflix, y tratar de seguir los pasos del titán del streaming puede introducir un gran grado de complejidad involuntaria.

El enfoque de microservicios es una forma de gestionar la complejidad de un sistema una vez que se ha vuelto demasiado grande para manejarlo de forma segura. Aun así, existe un equilibrio entre complejidad y gastos generales. Hay gastos generales sustanciales asociados con la gestión de una serie de servicios. Si se adopta prematuramente, un enfoque de microservicios puede hacer que los miembros del personal dediquen todo su tiempo a respaldar las herramientas que respaldan los servicios y descuiden el producto real.

Hay al menos dos opciones que vale la pena considerar para cualquier equipo que desee mantenerse ágil fomentando el acoplamiento flexible y progresar evitando los gastos generales de mantener una infraestructura basada en microservicios.

La primera opción es abrazar la arquitectura monolítica. Si bien los monolitos a menudo son difamados por ser inflexibles y obsoletos, uno planificado adecuadamente puede soportar un acoplamiento flojo y requerir mucho menos soporte general. La clave es construir una interfaz basada en código que pueda tomar las entradas de un componente y transmitirlas a otro. Incluso si se modifica un componente del monolito, dicha interfaz minimiza el impacto en cualquier otro componente y el sistema puede evolucionar más fácilmente donde existen interfaces.

La segunda opción es emplear una plataforma sin servidor proporcionada por un importante proveedor de nube. Este enfoque se acerca mucho más a los microservicios en espíritu, pero los costos generales los asume el proveedor de la nube. Como resultado, la arquitectura sin servidor puede ofrecer los beneficios de un acoplamiento flexible con una complejidad involuntaria mínima. Puede resultar que la tecnología sin servidor no sea para usted debido a otras limitaciones, pero siempre que construya sus interfaces cuidadosamente enfocándose en las interacciones que tienen más probabilidades de cambiar en el futuro, no está de más probar la tecnología sin servidor primero.

Incluso si decide seguir una de estas dos estrategias de acoplamiento flexible, puede que no esté claro cuál elegir. Aquí hay algunos factores que pueden ayudarlo a determinar si optar por arquitecturas basadas en la nube monolíticas o sin servidor:

El objetivo no es desacoplar todas partes ni que todo esté débilmente acoplado. Más bien, se trata de hacer que el sistema pueda evolucionar eligiendo estratégicamente dónde y en qué medida los componentes están débilmente acoplados. Este es un juego de conjeturas y compensaciones fundamentadas. No existe la mejor manera, sólo la menos peor.

Cuando los analistas y líderes de la industria hablan de “microservicios” como si fueran la respuesta universal para los sistemas de software, esto solo se aplica a los equipos que construyen los sistemas más maduros que tienen la capacidad de soportar los gastos generales asociados. El término “servicios del tamaño adecuado” transmite mejor que, incluso dentro de una empresa, cada equipo tiene diferentes limitaciones y, por lo tanto, diferentes formas de lograr un acoplamiento flexible. Esto puede implicar el uso de microservicios, monolitos, plataformas sin servidor o una combinación de estos; pero, en cualquier caso, los equipos que adoptan un acoplamiento flexible están mejor equipados para responder a los desafíos, obtener una ventaja competitiva y adaptarse a un panorama tecnológico en constante cambio.

Filed Under: API, Blogs, Práctica DevOps, Caja de herramientas DevOps Tagged With: desarrollo de aplicaciones, arquitectura, aplicaciones nativas de la nube, microservicios