Las arquitecturas de software componibles han cambiado fundamentalmente la forma en que desarrollamos y mantenemos el software.

ashan fernando, 4 de marzo de 2024. Medium

La progresión de aplicaciones monolíticas a arquitectura componible marca un salto significativo en la creación de aplicaciones de software altamente escalables y mantenibles. Esta evolución atravesó diferentes hitos en su camino.

La era de las aplicaciones monolíticas

Históricamente, los sistemas de software eran predominantemente monolíticos. En estos sistemas, varios componentes, incluida la interfaz de usuario, la lógica empresarial y las capas de acceso a datos, están estrechamente integrados en una única base de código. Si bien este enfoque fue sencillo y productivo inicialmente, inevitablemente generó desafíos a medida que las aplicaciones crecieron en complejidad.

Incluso una modificación menor de la aplicación podría requerir reconstruir, probar y volver a implementar toda la aplicación, lo que generaría ineficiencia. Además, la eficiencia de los desarrolladores disminuye ya que muchos desarrolladores tienen que colaborar y manejar una carga cognitiva más amplia para identificar las áreas de cambio y su impacto.

El monolito modular

Antes de la adopción generalizada de microservicios y microfrontends, el estilo arquitectónico monolito modular surgió como un término medio entre el monolito tradicional y los microservicios totalmente distribuidos.

Este enfoque tiene como objetivo conservar la simplicidad operativa del monolito al tiempo que introduce un nivel de modularidad y separación de preocupaciones típicamente asociadas con los microservicios. Traza límites claros en torno a los módulos, lo que hace que el desarrollo y las pruebas sean más granulares, lo que reduce la carga cognitiva para el desarrollo y, por lo tanto, mejora la productividad general.

Sin embargo, los desafíos fundamentales de una gran base de código aún existen, lo que afecta la colaboración de los desarrolladores y el uso eficiente de los recursos para ejecutar la aplicación.

Cambio hacia microservicios y microfrontends

La llegada de los microservicios marcó un cambio de paradigma para abordar muchos desafíos de las arquitecturas monolíticas a escala.La arquitectura de microservicios permitió el desarrollo, las pruebas y la implementación independientes al dividir las aplicaciones en servicios más pequeños y poco acoplados, cada uno responsable de una función específica y comunicándose a través de interfaces bien definidas.

Sobre la base de los principios de los microservicios, surgió el concepto de microfrontends para abordar desafíos similares en el panorama del frontend. Los microfrontends extienden el paradigma de los microservicios al frontend, dividiendo las bases de código monolíticas del frontend en partes más pequeñas y manejables.

Sin embargo, existe una diferencia fundamental entre Microservicios y Microfrontends. Los microservicios son sistemas distribuidos donde cada servicio tiene un ciclo de vida de extremo a extremo y total autonomía en desarrollo y operaciones. Por lo tanto, se recomienda que cada Microservicio se ejecute en su propio proceso (aislamiento de tiempo de ejecución) y bases de datos (aislamiento de datos) y tenga su propia base de código (aislamiento de código), minimizando las dependencias entre los equipos de desarrollo, lo que resulta en una menor reutilización y colaboración.

Por otro lado, las micro interfaces necesitan un nivel significativo de reutilización de componentes para mantener la coherencia de la interfaz de usuario. Requiere integración en tiempo de ejecución o en tiempo de compilación (preferida) antes de ejecutarse en el navegador.

Los microservicios y las microfrontends no son adecuados para todos. A una startup o a un pequeño equipo de desarrollo puede resultarle difícil y contraproducente adaptar estos estilos arquitectónicos, ya que conllevan gastos generales a la hora de configurar proyectos y gestionar operaciones. Por tanto, el coste de adaptar estas arquitecturas tiene sentido más allá de una determinada escala.

Presentamos la arquitectura puramente componible

La componibilidad implica la creación de aplicaciones de software a partir de componentes independientes y reutilizables, cada uno de los cuales encapsula sus dependencias y funcionalidades distintas. Luego, estos componentes (bloques de construcción) se pueden combinar para crear aplicaciones complejas. Es una diferencia fundamental con la forma en que solíamos desarrollar aplicaciones de software.

Dado que los componentes son bloques de construcción más pequeños y reutilizables, el contexto de cambio se convierte en el alcance de los componentes que pueden modificarse y probarse de forma independiente. La principal brecha en la implementación de arquitectura componible en el pasado es no contar con herramientas sólidas para respaldarla. Y dado que algunos cambios pueden afectar a varios componentes, se requieren herramientas sólidas que ayuden a modificar los componentes en masa y probar la cadena de dependencia.

El siguiente diagrama muestra cómo bit muestra el gráfico de dependencia de los componentes modificados y sus dependientes.

Y la belleza de este enfoque es que, dado que es tan fundamental, puedes usarlo con otros estilos arquitectónicos para abordar algunas de sus debilidades. A continuación se muestran algunos ejemplos.

• Puede utilizar componentes para crear sus microservicios para poder comenzar a colaborar entre equipos y compartir componentes.
• Utilice la aplicación como componente de shell para crear sus Micro frontends, utilizando un alcance remoto para cada equipo.
• Cree un Env para cada Microservicio para que la tecnología utilizada en cada Microservicio sea independiente entre sí.

Y, dado que cada componente tiene su documentación, interfaces claras, pruebas y vistas previas y las comparte en bit.cloud , la colaboración aumenta a escala entre bases de código y equipos.

Y existen muchos otros beneficios de implementar una arquitectura componible;

• Flexibilidad mejorada : la arquitectura se vuelve flexible al adoptar diferentes estilos y patrones.
• Escalabilidad del equipo de desarrollo : los componentes individuales se pueden escalar según sea necesario, lo que permite una utilización más eficiente de los recursos.
• Mantenibilidad : la naturaleza modular de las arquitecturas componibles simplifica el mantenimiento y las actualizaciones, ya que los cambios se localizan en componentes específicos.
• Innovación y velocidad : los componentes reutilizables aceleran los ciclos de desarrollo y fomentan la innovación al permitir que los equipos aprovechen las funcionalidades existentes para nuevas aplicaciones y colaboren mejor.
• Mejor gestión de dependencias: considere un escenario en el que se utiliza una biblioteca de componentes de interfaz de usuario en varios proyectos dentro de una organización. Bit puede administrar las dependencias de estos componentes, asegurando que las actualizaciones no interrumpan la funcionalidad en ningún proyecto que dependa de la biblioteca.

Resumen

La evolución de aplicaciones monolíticas a arquitecturas componibles está redefiniendo los estándares para el desarrollo de software. Con el apoyo de herramientas avanzadas como Bit, el futuro del desarrollo de software será más flexible, eficiente y alineado con las necesidades dinámicas de las empresas.

A medida que avancemos, las arquitecturas componibles sin duda seguirán dando forma al futuro del desarrollo de software, marcando un cambio significativo hacia sistemas de software más adaptables y resilientes.