transición de monolito a microfrontends y viceversa / Sudo Null IT News
Mi nombre es Oleg, trabajo en TI desde hace 20 años, principalmente en proyectos empresariales. Ahora trabajo en Alfa-Bank en el proyecto Alfa-Online y quiero compartir mi visión de la gestión de la complejidad en grandes proyectos.
Mi experiencia trabajando con docenas de soluciones complejas ha demostrado que el pensamiento sistémico no sólo es importante, sino que es vital para la gestión exitosa de proyectos complejos. El uso de un enfoque sistemático le permite no sólo ver el “panorama general” en su totalidad, sino también anticipar problemas potenciales, lo cual es un factor decisivo para una gestión eficaz de proyectos.
El propósito de este artículo es demostrar el uso de un enfoque de sistemas para resolver los problemas que enfrentan los arquitectos y equipos de diseño modernos. Analizaremos la importancia de pensar estratégicamente, evaluar las consecuencias de las decisiones con varios pasos de anticipación y la importancia de evitar conclusiones apresuradas que puedan conducir a problemas a largo plazo.
Los problemas de los blancos
Con el tiempo, nuestra aplicación monolítica comenzó a tomar cada vez más tiempo para implementarse y se volvió cada vez más compleja. Decidimos dividirlo en microfrontends, dado que ya teníamos una infraestructura de microservicios para el backend. Sin embargo, surgieron más de 15 bibliotecas comunes de las que dependían la mayoría de las aplicaciones. Evidentemente, con las dependencias externas, de las que cada módulo tiene su propio conjunto de versiones, tampoco todo es sencillo. Actualizar la paleta de colores, por ejemplo, en todo el sitio de una sola vez resultó ser increíblemente difícil.
Propiedades emergentes
Los módulos, procesos y personas interconectados forman un sistema: un conjunto de elementos que actúan juntos como un todo único, realizando una función específica que no está disponible para sus elementos constituyentes o conjunto de elementos.
La estructura, las relaciones y la composición dan lugar a funciones y propiedades adicionales que las partes individuales no tienen. Esta propiedad se llama emergente.
Por ejemplo, las propiedades emergentes de un sistema de software son atributos de calidad arquitectónica.
El arquitecto de software tiene un papel clave en la gestión de estas propiedades para garantizar la confiabilidad, el rendimiento y la mantenibilidad del sistema.
Por ejemplo, una de las propiedades emergentes de los sistemas de software que observo cuando reviso la arquitectura es ortogonalidad – esto es cuando los cambios en una parte del sistema no deberían conducir a cambios en otra parte. Esto simplifica el mantenimiento porque no es necesario tener todo el sistema en la cabeza y evita efectos impredecibles.
Métodos para asegurar la ortogonalidad: usar interfaces, patrones de diseño (por ejemplo, inyección de dependencia), modularidad y acoplamiento flexible, deshacerse de archivos barril en bibliotecas y archivos que a menudo generan conflictos durante la fusión.
Una característica importante de un sistema: si elimina, agrega o reemplaza un elemento en el sistema, la propiedad emergente cambia. De lo contrario, no se trata de un sistema, sino de un conjunto de elementos.
También es característico de los sistemas. Bucle de retroalimentación – aceleración o inhibición de cambios en el tiempo). Hay cuatro tipos de retroalimentación:
Aumentativo: aumenta los cambios en el sistema (como un castillo de naipes o una fila de fichas de dominó).
Equilibrado: estabiliza el sistema (válvula de liberación de vapor).
Refuerzo proactivo: preparación para cambios que refuerzan los cambios del sistema.
Equilibrio proactivo: prepararse para el cambio, estabilizar el sistema.
Comprender la presencia de retroalimentación prolongada en el tiempo ayuda a realizar cambios en el sistema y adaptarse a nuevas condiciones.
En nuestro caso, cualquier cambio en la funcionalidad del módulo microfrontend puede afectar a las bibliotecas compartidas, y esto afecta a muchas otras aplicaciones. Esto conduce a mayores ciclos de retroalimentación y a la intersección de cambios técnicos y comerciales. Los cambios simples, como agregar .dockerignore a todas las aplicaciones, pueden tardar de tres meses debido a la necesidad de distribuir tareas entre los equipos de producto.
La complejidad del sistema también está determinada por el tipo de conexiones, el número de estados de los elementos y la retroalimentación.
Hay dos tipos de complejidad de enlace:
Complejidad cuantitativa — conexiones simples con las que es fácil trabajar combinando elementos del sistema en grupos.
Complejidad dinámica — los elementos pueden estar en diferentes estados y configuraciones de relaciones. Por ejemplo, la interacción de dos objetos en gravedad cero es mucho más predecible que la de tres (una referencia al problema de los tres cuerpos, generalmente irresoluble).
Cuanto más complejas e intrincadas sean las conexiones, más esfuerzo se requerirá para mantener el sistema en funcionamiento y desarrollarlo.
Encontrar una solución
En el siglo transcurrido desde la fundación del enfoque de sistemas como disciplina distinta, se han inventado muchos métodos para describir sistemas y procesos para abordar la complejidad dinámica. Por ejemplo, PDCA y IDEF0.
Modelo PDCA Ayuda a estructurar procesos a través de la planificación, ejecución, revisión y ajuste. Esto le permite coordinar el trabajo de diferentes personas y departamentos, mejorando la colaboración y la eficiencia. Mostrar las estructuras organizativas cómo su trabajo afecta el trabajo de los demás y ver la dinámica del sistema en su conjunto. En realidad, en el marco del mismo se introdujo el concepto de retroalimentación, que comentamos anteriormente.
IDEF0 es un lenguaje de modelado de procesos desarrollado por la Fuerza Aérea de EE. UU. Le permite descomponer fácilmente sistemas y procesos en sus componentes:
Proceso: elemento principal del diagrama.
Acceso: recursos necesarios para el proceso.
Salida: resultado del proceso.
Mecanismos: Equipos y personas involucradas en el proceso.
Gestión: elementos de control de procesos (cómo está controlado).
Otro ejemplo del uso de IDEF0 es la ruta del código a través de revisiones y controles de calidad.
Si observa este diagrama durante mucho tiempo, notará que:
Se produce un bucle: muy a menudo podemos volver a la primera etapa.
Tenemos alrededor de 5 sistemas solo para verificación de código estático, sin contar las comprobaciones dinámicas. Estos son automáticos, pero también hay una revisión manual por parte de un desarrollador, diseñador y, a veces, incluso un analista.
No hay estándares en el diagrama, es decir, la empresa los tiene, pero no están en el diagrama; no está del todo claro en qué punto deberían influir.
La notación IDEF0 se puede modificar para demostrar algunos detalles importantes del proceso. Por ejemplo, después de hacer una autopsia de varias tareas que se estimaba que tomarían 2 semanas, pero los RP estuvieron dando vueltas durante 9 meses, tracé un esquema aproximado como este para iniciar una revisión y un cambio en el proceso de producción que resultó en un año de Time to Market en lugar de un mes.
También adjunto un análisis del historial de relaciones públicas del año, en el que se ve claramente que el 90% de ellas son técnicas y llegan en una semana, pero las características comerciales esperaron la fusión durante un mes, en promedio, porque hubo muchos ciclos. volviendo a la primera etapa de revisión. En un caso, el código pasó por estos círculos del infierno hasta el probador y regresó 8 veces.
El resultado fue la revisión y desarrollo de un nuevo proceso productivo Alfa-Online.
Como puede ver, incluso un dibujo aproximado puede revelar problemas sistémicos y ayudar a comunicarlos.
En el proceso de considerar una de las opciones de solución: cambiar a un monorepositorio (un monorepositorio permitiría realizar confirmaciones atómicas tanto para la biblioteca como para las aplicaciones a la vez, lo que simplificaría la gestión de cambios), teniendo en cuenta ejemplos de otros proyectos, muchos Se cubrió papel y se escribieron muchas letras para aclarar las manchas “blancas”. Resultó que esta decisión habría causado nuevos problemas.
Problemas con Bitbucket. Encontramos una serie de problemas al usar Bitbucket: falta de CODEOWNERS, versión antigua en hardware débil, inconvenientes para ver las diferencias, problemas con las pruebas y la revisión del código, así como una selección aleatoria de revisores y baja calidad del código. En un monorepositorio estos problemas se multiplicarían por 50.
Problemas con la portabilidad del código. Mover el código a un monorepositorio requirió revisar y cambiar procesos en docenas de equipos, refinando la infraestructura y la plataforma. A pesar de que los procesos no están adecuadamente descritos.
La retroalimentación esperada de tal cambio sería catastrófica, por lo que comenzamos a preparar el entorno para este cambio (cambios proactivos).
Para resolver estos problemas, aplicamos un enfoque de sistemas que ayuda a predecir el futuro y tener en cuenta causas y efectos prolongados en el tiempo. Nos llevó meses convencer a los protagonistas, pero fue un tiempo bien invertido.
La influencia de las creencias en los cambios en los sistemas.
Cualquier sistema refleja el pensamiento de sus creadores. Cuando proponemos cambios, debemos explicar a la gente por qué vale la pena reconsiderar sus enfoques.
Sin embargo, creencias limitantes como “estoy bien” pueden dificultar enormemente el cambio. Los signos de estas creencias incluyen sacar conclusiones precipitadas, culpar a otros, generalizar a partir de incidentes aislados y abusar de palabras autorizadas como “correcto”, “debería” y “debería”.
Estas creencias indican una falta de pensamiento crítico y sistemático. Por el contrario, las creencias de apoyo promueven el desarrollo: el deseo de nuevos modelos mentales, la falta de miedo a la incertidumbre y la atención a las contradicciones y las relaciones de causa y efecto.
Nunca he sido junior o mid. Habiendo comenzado como especialista en TI, rápidamente me convertí en un senior, sin un mentor que me mostrara cómo hacerlo bien. Esto me obligó a examinar mis suposiciones, considerar varios factores y buscar relaciones de causa y efecto. Este enfoque me liberó del miedo a la incertidumbre: estoy acostumbrado a trabajar en condiciones de caos e incertidumbre, y un 10% de claridad es suficiente para desarrollar una comprensión del sistema, estudiar, buscar conexiones y avanzar paso a paso. .
Eventualmente
Hemos mejorado Bitbucket.
Justificó la necesidad de recursos adicionales.
Configuramos métricas para comprender el estado del sistema.
Tomamos en cuenta las características específicas de los proyectos y desarrollamos un enfoque de conocimiento especial para trabajar con un monorepositorio de microfrontends.
Implementé proyectos Yarn 4 y CODEOWNERS.
El ciclo de liberación se ha endurecido.
Revisamos y mejoramos el proceso de producción.
Y mejoramos la incorporación de nuevos empleados.
Pero todavía queda mucho trabajo. Hay una salida a este estado:
En esto:
conclusiones
Evite las relaciones dinámicas. Cuantos menos estados de objeto y posibles interfaces implemente, mejor.
Aflojar lazos y cambiar las creencias de las personas para lograr cambios en un sistema complejo. Para cambiar el sistema, es necesario aflojar las ataduras. Descubra primero qué afectará, afloje las conexiones, tal vez escriba interfaces más genéricas y luego realice cambios.
Buscar incansablemente mejores modelos mentales. Verificación de la realidad. Si hay alguna creencia, hay que comprobarla.
Utilice la notación adecuada. IDEF0 no es la única notación, pero es mi favorita. Algunas partes del sistema se describen mejor usando BPMN, pero para el modelado funcional, las notaciones IDEF, en mi humilde opinión, son las mejores.
Intercalar cambios con periodos de estabilidad. Al realizar cambios en un sistema cambiante, sólo se aumenta la complejidad dinámica.
Tome una posición meta para ver el panorama general y la dinámica a lo largo del tiempo. Periódicamente es necesario salir del sistema y mirarlo desde fuera para comprender cómo funciona y tomar decisiones objetivas.
Algunas conclusiones más
A continuación se presentan algunas conclusiones de mi experiencia personal, respaldadas por la terminología del enfoque de sistemas.
Los estándares superiores no funcionan – también conocido como “optimización de caja negra”. Imagina que tienes algún tipo de proceso con elementos entrantes y salientes, flechas de control y materiales. Si no recomponemos este proceso, sino que simplemente cambiamos los elementos entrantes y salientes, pero no estudiamos los procesos internos, esto puede ayudar o no. Primero necesitas entender la esencia del proceso.
Las cinco disfunciones de un equipo de Patrick Lencioni sostiene que los estándares deben crearse a través del conflicto. Si se produce algún conflicto, para solucionarlo registramos los acuerdos alcanzados. Un estándar se vuelve tal sólo cuando todos comienzan a exigírselo a todos; de lo contrario, el sistema no funcionará.
Aumentar los recursos de gestión no funciona. Un sistema es una estructura flexible que se puede cambiar. La gestión es importante, de lo contrario el sistema rápidamente se convertirá en un caos. La dirección es garante de la presencia de retroalimentación proactiva y estabilizadora. Un aumento en los recursos de gestión puede parecer una presión sobre el sistema, y tarde o temprano caerá en un estancamiento o cambiará radicalmente si está listo para el cambio.
Resolver problemas de escalamiento ficticio. En uno de los proyectos, se implementó todo para resolver problemas de escala: Kubernetes, Docker, equilibrio de carga, pero se utilizó MongoDB como base de datos relacional. Esto provocaba un desbordamiento de la memoria y fallos en la producción una vez al día. El foco estaba en el lugar equivocado.
La propiedad colectiva no funciona. En economía existe el uso excesivo de la propiedad colectiva. Si una aldea tiene un huerto, tarde o temprano dejará de dar frutos debido al uso excesivo.
En nuestro caso, cada microfrontend tiene su propio equipo, que incluye el propietario del producto, el analista de sistemas, el tester, los desarrolladores y el diseñador. Pero las bibliotecas y los widgets compartidos son de propiedad colectiva. Y regularmente en el chat (general) preguntan qué está pasando con los widgets, porque los widgets tienen dependencias comunes, y si los actualizas, algunos widgets se rompen.
Un problema sistémico no se puede resolver localmente. Para resolver un problema sistémico, se necesita un enfoque sistémico.
Después de varios años de implementar tecnologías BDUI, los equipos de desarrollo se enfrentaron al hecho de que al implementar la funcionalidad, los equipos buscaban soluciones a los problemas con la sangría y, posteriormente, esto causó un problema sistémico: no sabemos cuál será el efecto de cambiar la sangría de será un componente. Nos vemos obligados a realizar una regresión completa en tres plataformas para descubrir qué podría interrumpir el cambio en un componente universal (¿has notado errores de diseño en nuestra aplicación móvil?).
Bono: ejercicio de pensamiento sistémico
Tomemos cualquier elemento y pensemos en su propósito, posibles cambios y el impacto de esos cambios en la funcionalidad y usabilidad. Consideremos, por ejemplo, una taza y un teléfono móvil.
Taza
El objetivo principal de una taza es almacenar y consumir bebidas.
La taza debe ser cómoda para sostener y beber, y también resistente a altas temperaturas si se usa para bebidas calientes.
Los cambios en el diseño de la taza, como aumentar o disminuir el volumen, pueden afectar la usabilidad. Por ejemplo, una taza grande puede resultar cómoda para quienes gustan de beber mucho té o café a la vez, pero puede resultar más pesada y menos cómoda para manos pequeñas.
Los materiales con los que está hecha la taza también son importantes: la cerámica y el vidrio retienen bien el calor pero pueden ser frágiles, mientras que las tazas de metal son duraderas pero pueden calentarse demasiado.
Lo especial de esta taza es que es un regalo de entrada a una empresa genial. Al exhibir esta taza se puede sentir el orgullo de pertenecer a esta empresa, lo que añade valor emocional y singularidad al artículo.
Hacer una taza implica seleccionar materiales (cerámica, vidrio, metal), darle forma, hornear (para cerámica) y aplicar un recubrimiento o diseño. Durante su uso, la taza debe ser cómoda para beber, resistente a daños y fácil de limpiar.
Teléfono móvil
El objetivo principal de un teléfono móvil es proporcionar capacidades de comunicación, incluidas llamadas de voz, mensajes de texto y acceso a Internet.
Aumentar el tamaño de la pantalla mejora la usabilidad para ver medios, leer y trabajar con aplicaciones, pero puede reducir la portabilidad y el uso con una sola mano.
Quitar el conector para auriculares hace que el dispositivo sea más delgado y mejora la resistencia al agua, pero causa inconvenientes a los usuarios de auriculares con cable, ya que requieren el uso de dongles o auriculares inalámbricos.
Agregar carga inalámbrica hace que la carga sea más conveniente, pero aumenta el costo del dispositivo y requiere una estación de carga compatible.
Mejorar la cámara mejora la calidad de las fotos y videos, lo cual es importante para los usuarios de redes sociales y medios, pero aumenta el costo y el consumo de energía del dispositivo.
Aumentar la capacidad de la batería extiende su vida útil, mejorando la usabilidad, pero puede aumentar el peso y el grosor del dispositivo.
La fabricación de teléfonos móviles implica el uso de baterías de metal, vidrio, plástico y iones de litio, así como procesos de ensamblaje de componentes, soldadura de chips y pruebas de rendimiento y calidad. En uso, el teléfono está diseñado para llamadas de voz, mensajes de texto y acceso a Internet, así como para fotografía, grabación de vídeo, uso de aplicaciones, navegación y pagos.
