Organización y formas de trabajo

Como ocurre con todas las estrategias de arquitectura, las microinterfaces tienen implicaciones que van mucho más allá de la tecnología que una organización decida implementar. La decisión de crear aplicaciones microfrontales debe estar en consonancia con la empresa, el producto, la organización, las operaciones e incluso la cultura (por ejemplo, empoderando a los equipos y descentralizando la toma de decisiones). A cambio, este tipo de arquitectura de microinterfaz permite un desarrollo verdaderamente ágil e impulsado por el producto, ya que reduce considerablemente la sobrecarga de comunicación entre equipos que, de otro modo, serían independientes.

Desarrollo ágil

La idea del desarrollo ágil de software se ha vuelto tan universal en los últimos años que prácticamente todas las organizaciones afirman trabajar de forma ágil. Si bien una definición concluyente de ágil va más allá del alcance de esta estrategia, vale la pena revisar los elementos clave que son relevantes para el desarrollo de microinterfaces.

La base del paradigma ágil es el Manifiesto Ágil (2001), que postuló cuatro principios principales (por ejemplo, «Las personas y las interacciones en lugar de los procesos y las herramientas») y doce principios. Los marcos de procesos como Scrum y Scaled Agile Framework (SAFe) surgieron en torno al Manifiesto Ágil y se han incorporado a las prácticas cotidianas. Sin embargo, la filosofía que los sustenta se malinterpreta o se ignora en gran medida.

En el contexto de la arquitectura de microinterfaz, es importante adoptar los siguientes principios ágiles:

• «Entregue software que funcione con frecuencia, de un par de semanas a un par de meses, con preferencia por un plazo más corto».

  Este principio hace hincapié en la importancia de trabajar en incrementos y entregar el software a la producción con la mayor regularidad y frecuencia posible. Desde una perspectiva tecnológica, esto se refiere a la integración continua y la entrega continua (CI/CD). En CI/CD, las herramientas y los procesos de creación, prueba e implementación son partes integrales de cada proyecto de software. El principio también implica que la infraestructura de tiempo de ejecución y las responsabilidades operativas deben ser responsabilidad del equipo. Esa propiedad es especialmente importante en los sistemas distribuidos, donde los subsistemas independientes pueden tener requisitos de infraestructura y operaciones significativamente diferentes.

• «Cree proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer su trabajo».

  «Las mejores arquitecturas, requisitos y diseños surgen de equipos que se autoorganizan».

  Ambos principios hacen hincapié en los beneficios de la propiedad, la independencia y end-to-end la responsabilidad. Una arquitectura de microfrontend tendrá éxito cuando (y solo cuando) los equipos sean realmente dueños de sus microfrontend. La nd-to-end responsabilidad electrónica, desde la concepción hasta el diseño y la implementación, hasta la entrega y la operación, garantiza que el equipo pueda realmente asumir la responsabilidad. Esta independencia es necesaria, tanto técnica como organizativamente, para que el equipo tenga autonomía en la dirección estratégica. No recomendamos utilizar una plataforma de microinterfaz en una organización centralizada que utilice un modelo de desarrollo en cascada.

Composición y tamaño del equipo

Para que un equipo de software ejerza la propiedad, debe gobernarse a sí mismo, incluyendo cómo y qué entrega el equipo, dentro de los límites impuestos por la organización.

Para ser eficaces, los equipos deben poder entregar software de forma independiente y tener la autoridad para decidir la mejor manera de entregarlo. No se puede considerar autónomo a un equipo que recibe los requisitos de funciones de un gerente de producto externo o los diseños de interfaz de usuario de un diseñador externo, sin participar en la planificación de estos elementos. Las funciones pueden infringir los contratos o la funcionalidad existentes. Estas infracciones requerirán más debates y negociaciones, con el riesgo de retrasar la entrega e introducir conflictos innecesarios entre los equipos.

Al mismo tiempo, los equipos no deberían ser demasiado grandes. Si bien un equipo más grande tiene más recursos y puede adaptarse a las ausencias individuales, la complejidad de la comunicación aumenta exponencialmente con cada nuevo miembro. No es posible establecer un tamaño máximo de equipo válido universalmente. La cantidad de personas necesarias para un proyecto depende de factores como la madurez del equipo, la complejidad técnica, el ritmo de innovación y la infraestructura. Por ejemplo, Amazon sigue la regla de las dos pizzas: un equipo que es demasiado grande para alimentarse con dos pizzas debe dividirse en equipos más pequeños. Eso puede ser un desafío. La división debe producirse dentro de los límites naturales y debe dar a cada equipo autonomía y propiedad sobre su trabajo.

DevOps cultura

DevOps se refiere a una práctica de ingeniería de software en la que los pasos del ciclo de vida del desarrollo están estrechamente integrados desde una perspectiva organizativa y técnica. Contrariamente a la creencia popular, DevOps tiene mucho que ver con la cultura y la mentalidad, y muy poco con las funciones y las herramientas.

Tradicionalmente, una organización de software tenía equipos de especialistas, por ejemplo, para el diseño, la implementación, las pruebas, el despliegue y las operaciones. Cada vez que un equipo terminaba su trabajo, pasaba el proyecto al siguiente equipo. Sin embargo, la entrega del software a través de silos de equipos especializados provoca fricciones durante las entregas. Al mismo tiempo, cuando los especialistas se ven obligados a trabajar con un enfoque limitado, carecen de conocimientos en dominios vecinos y no tienen una visión sistémica del producto. Esos déficits pueden provocar una baja coherencia del producto de software.

Por ejemplo, cuando un arquitecto de software diseña una solución para ser implementada por alguien de un equipo diferente, puede pasar por alto aspectos inherentes a la implementación (como la falta de coincidencia de dependencias). Luego, los desarrolladores utilizan atajos (como un parche temporal) o back-and-forth se inicia una formalización entre el arquitecto y el equipo de desarrollo. Debido a la sobrecarga que supone gestionar estos procesos, el desarrollo ha dejado de ser ágil (en el sentido de flexible, adaptativo, incremental e informal).

Si bien el término DevOps se refiere principalmente a la cultura, implica las tecnologías y los procesos que hacen DevOps posible la práctica. DevOps está estrechamente relacionado con la CI/CD. Cuando un desarrollador termina de implementar un incremento de software, lo envía a un sistema de control de versiones como Git. Tradicionalmente, un sistema de compilación compilaba e integraba el software, y lo probaba y publicaba en un proceso más o menos unificado y centralizado. Con la CI/CD, la creación, la integración, las pruebas y el lanzamiento del software son inherentes y automatizadas. Lo ideal es que el proceso forme parte del propio proyecto de software a través de archivos de configuración que se adapten específicamente al proyecto en cuestión.

Se automatizan tantos pasos como sea posible. Por ejemplo, deberían reducirse las prácticas de pruebas manuales, ya que casi todos los tipos de pruebas se pueden automatizar. Cuando el proyecto se configura de esa manera, las actualizaciones de un producto de software se pueden entregar varias veces al día con gran confianza. Otra tecnología compatible DevOps es la infraestructura como código (IaC).

Tradicionalmente, la configuración y el mantenimiento de la infraestructura de TI requerían el trabajo manual de instalar y mantener el hardware (configurar los cables y los servidores en un centro de datos) y el software operativo. Esto era necesario, pero tenía numerosos inconvenientes. La configuración llevaba mucho tiempo y era propensa a errores. A menudo, el hardware estaba sobreaprovisionado o insuficientemente, lo que generaba un gasto excesivo o una degradación del rendimiento. Al utilizar el iAC, puede describir los requisitos de infraestructura de un sistema de TI mediante un archivo de configuración desde el que se pueden implementar y actualizar automáticamente los servicios en la nube.

¿Qué tiene que ver todo esto con las microinterfaces? DevOps, CI/CD e iAc son complementos ideales para una arquitectura de microfrontend. Los beneficios de las microinterfaces se basan en procesos de entrega rápidos y sin fricciones. Una DevOps cultura solo puede prosperar en entornos en los que los equipos son responsables de los proyectos de software. end-to-end

Organizar el desarrollo de microinterfaces entre varios equipos

Al ampliar el desarrollo de la microinterfaz entre varios equipos multifuncionales, surgen dos problemas: en primer lugar, los equipos comienzan a desarrollar su propia interpretación del paradigma, a elegir el marco y la biblioteca y a crear sus propias bibliotecas de herramientas y auxiliares. En segundo lugar, los equipos totalmente autónomos deben asumir la responsabilidad de las capacidades genéricas, como la gestión de infraestructuras de bajo nivel. Por lo tanto, tiene sentido introducir dos equipos adicionales en una organización con microinterfaz integrada por varios equipos: un equipo de habilitación y un equipo de plataforma. Estos conceptos se adoptan ampliamente en las organizaciones de TI modernas con sistemas distribuidos y están bien documentados en las topologías de equipos.

En el siguiente diagrama se muestra al equipo de habilitación que proporciona herramientas, bibliotecas, estándares y pruebas a tres equipos de microinterfaz. El equipo de la plataforma proporciona infraestructura, capacidades de tiempo de ejecución compartidas y servicios de dominio a esos mismos tres equipos de microfrontend.

El equipo de la plataforma apoya a los equipos de microinterfaz al liberarlos del trabajo pesado indiferenciado. Este soporte puede incluir servicios de infraestructura, como tiempos de ejecución de contenedores, canalizaciones de CI/CD, herramientas de colaboración y monitoreo. Sin embargo, la creación de un equipo de plataformas no debería llevar a una organización en la que el desarrollo esté separado de las operaciones. Es todo lo contrario: el equipo de la plataforma ofrece un producto de ingeniería y los equipos de microinterfaz son los propietarios y responsables de la ejecución de sus servicios en la plataforma.

El equipo de habilitación proporciona apoyo centrándose en la gobernanza y garantizando la coherencia entre los equipos de microinterfaz. (El equipo de la plataforma no debería participar en esto). El equipo de habilitación mantiene recursos compartidos, como una biblioteca de interfaz de usuario, y crea estándares como la elección del marco, los presupuestos de rendimiento y las convenciones de interoperabilidad. Al mismo tiempo, proporciona a los nuevos equipos o miembros del equipo formación sobre la aplicación de las normas y las herramientas definidas por la gobernanza.

Implementación

La clave de la autonomía de los equipos con microinterfaz es disponer de un proceso automatizado con un proceso de producción que sea independiente del de otros equipos microfrontend. Los equipos que siguen el principio de no compartir nada pueden implementar procesos independientes. Los equipos que comparten bibliotecas o dependen de un equipo de plataforma deben decidir cómo gestionar las dependencias en los procesos de implementación.

Por lo general, cada canalización hace lo siguiente:

• Crea activos de interfaz

• Despliega los activos en el alojamiento para su consumo

• Garantiza que los registros y las cachés se actualicen para que las nuevas versiones se puedan entregar a los clientes

Los pasos reales del proceso varían según la tecnología y el enfoque de composición de la página.

En el caso de la composición por parte del cliente, esto implica cargar los paquetes de aplicaciones en paquetes de alojamiento y luego liberarlos para su consumo mediante el almacenamiento en caché en una CDN. Las aplicaciones que utilizan el almacenamiento en caché del navegador con los trabajadores del servicio también deberían implementar formas de actualizar las cachés de los trabajadores del servicio.

En el caso de la composición del lado del servidor, esto normalmente implica implementar la nueva versión del componente del servidor y actualizar el registro de la microinterfaz para que la nueva versión sea reconocible. Puede utilizar patrones de despliegue azul/verde o canario para lanzar nuevas versiones de forma gradual.