Tres formas de que DevOps dé soporte a la arquitectura continua

Las largas fases de diseño de la arquitectura del software y de los sistemas solían ser un paso necesario y, a veces, un requisito previo de la empresa antes de que los equipos de ingeniería comenzaran a desarrollar aplicaciones y sistemas. Los arquitectos revisaban los requisitos de alto nivel, consideraban los estándares de la empresa y diagramaban una arquitectura sobre las plataformas, los patrones de diseño y los componentes a utilizar en el proceso de desarrollo del software.

Algunas organizaciones llevan la planificación de la arquitectura un paso más allá si se requieren nuevas tecnologías o componentes de software. Han establecido juntas de revisión de la arquitectura para proporcionar transparencia en la toma de decisiones, destacar el riesgo de la arquitectura, alinear los presupuestos y examinar otras consideraciones que afectan a las prácticas de desarrollo sostenible. Otros cuestionan la eficacia de los comités de revisión de la arquitectura porque dificultan la autonomía, interrumpen el flujo de desarrollo y pueden dar lugar a un exceso de documentación.

Los equipos de desarrollo ágil buscan autonomía y poder para responder al cambio en lugar de seguir un plan prescriptivo; éste es uno de los valores clave del Manifiesto para el Desarrollo Ágil de Software. Sin embargo, los líderes tecnológicos buscan plataformas reutilizables, estándares de desarrollo y modelos operativos sostenibles para la eficiencia, la calidad y la fiabilidad, reduciendo al mismo tiempo la deuda técnica.

El equilibrio puede lograrse mediante los principios de la arquitectura continua. El Manifiesto de la Arquitectura Continua apoya el "paso de un antiguo enfoque en cascada, en el que la arquitectura se realizaba principalmente antes de la implementación de las características, a una pasarela continua". Los principios incluyen la arquitectura de "productos a largo plazo, no sólo soluciones de proyectos", y "la validación de la arquitectura mediante la implementación". Sus principios son adecuados para los equipos que desarrollan arquitecturas en la nube, aprovechando las mejores prácticas de desarrollo, y utilizando pruebas de concepto y picos ágiles para validar sus soluciones.

Pierre Pureur, arquitecto de software de Continuous Architecture, explica que "el enfoque de la Arquitectura Continua ofrece un camino probado para crear y mantener arquitecturas de software sostenibles en la era de la agilidad, el desarrollo y la nube. Destaca la importancia de las actividades esenciales, incluyendo el enfoque en los requisitos de atributos de calidad, la conducción de las decisiones arquitectónicas, el conocimiento de su deuda técnica, y la implementación de los bucles de retroalimentación".

Automatizar la creación de entornos de desarrollo y pruebas

Un primer lugar para empezar con la arquitectura continua puede ser en las prácticas fundamentales de devops, como la automatización de la infraestructura como código (IaC) para crear entornos de desarrollo y prueba. La automatización ayuda a fijar las configuraciones y patrones estándar que buscan los arquitectos y proporciona la agilidad que necesitan los equipos de desarrollo.

Amir Rozenberg, vicepresidente de gestión de productos de Quali, está de acuerdo y afirma que "las organizaciones que entregan aplicaciones dependen y deben tener fácil acceso a entornos fiables, fácilmente disponibles y conformes para alimentar sus conductos de entrega continua de software".

Rozenberg sugiere que los arquitectos se asocien con los equipos de devops para crear planos de infraestructura en la nube. Afirma que "los equipos de desarrollo deben modelar los planos de los entornos para proporcionar la infraestructura de nube adecuada a sus componentes empresariales, como los equipos de desarrollo, los gestores de productos, los probadores y las preventas, de una manera autoservicio que elimine los prolongados tiempos de espera".

Tim Lucas, fundador y coCEO de Buildkite, está de acuerdo. "Una arquitectura continua, tanto técnica como cultural, requiere el compromiso del equipo de desarrollo y del negocio", afirma. Un principio clave que sugiere es "crear un papel dedicado que se centre y sea responsable de la experiencia del desarrollador". Se puede abordar la experiencia del desarrollador facilitando a los equipos de desarrollo el autoservicio de los entornos y conductos de despliegue necesarios para desarrollar y probar su código.

Tener en cuenta las necesidades del cliente y del usuario al definir las arquitecturas de producción

Mientras que los equipos de desarrollo buscan la productividad a través de la automatización, los líderes empresariales, incluidos los gestores de productos, los científicos de datos y los responsables de cumplimiento, también buscan la agilidad de la arquitectura en los entornos de producción. Esto a menudo significa ampliar y reducir los entornos de producción debido a la demanda de los usuarios. A veces significa poner en marcha varios entornos en función de los requisitos de cumplimiento.

Lucas añade un principio de diseño clave para los entornos de producción y sugiere "invertir en la reducción de fallos porque para que algo sea continuo, las interrupciones deben reducirse".

Para los científicos de datos, la integración y los despliegues suelen tener requisitos diferentes a los habituales para los equipos de desarrollo de software. Michael Berthold, cofundador y director general de KNIME, ha explicado que "el proceso de producción de la ciencia de datos construido durante la integración es diferente de lo que creó el equipo de ciencia de datos, y la monitorización en producción puede dar lugar a la actualización y el redespliegue automáticos".

La monitorización del uso y de la infraestructura puede desencadenar la ampliación y la reducción de los entornos, pero la monitorización de modelos también puede desencadenar un cambio de configuración o un nuevo despliegue. Berthold dice que para la ciencia de los datos y los pipelines de aprendizaje automático, "el ciclo de despliegue puede ser desencadenado automáticamente por el proceso de monitorización que comprueba el proceso de ciencia de los datos en producción, y solo un cambio grave obliga a reiniciar todo el proceso".

La arquitectura debe centrarse en las posibilidades futuras

Los líderes empresariales suelen centrarse en las oportunidades a corto plazo, y los equipos de devops hacen sus mejores intentos para desarrollar componentes de software modulares y ampliables. Algunas de las mejores prácticas para apoyar una arquitectura continua incluyen:

• Desarrollar con arquitecturas nativas de la nube y sin servidor
• Estandarizar de canalizaciones de implementación
• Apoyar las prácticas de pruebas continuas
• Construir microservicios y soporte del ciclo de vida de la API
• Aprovechar las soluciones de bajo código donde las plataformas simplifican y ayudan a evitar las soluciones personalizadas

Vince Padua, vicepresidente ejecutivo y director de innovación y tecnología de Axway, se centra en las arquitecturas abiertas y afirma que "la integración y la colaboración B2B acelerará su transformación digital construida sobre las espaldas de las API y la nube. Debido a que los enfoques cloud-native y API-first han madurado hacia una arquitectura abierta, el tiempo y el coste de la innovación a través de las asociaciones y la colaboración han disminuido significativamente".

Muchas empresas están invirtiendo ahora en software personalizado para las experiencias de los clientes, las integraciones y los flujos de trabajo digitalizados, y deben tener en cuenta las mejores prácticas para garantizar el futuro de sus inversiones. Padua sugiere: "A medida que la superficie de la empresa se centra en las API, se desbloquea más innovación al desagregar y reagrupar las ofertas y las cadenas de suministro en todos los sectores y verticales. Hay inversiones significativas y oportunidades de crecimiento en las ofertas B2B para viajes, logística, almacenamiento, fabricación, préstamos, seguros y comercio minorista".

Practicar la arquitectura continua requiere equilibrar lo que el negocio necesita hoy y lo que los equipos de devops requieren para ser productivos, a la vez que tener una visión de cómo la organización puede soportar futuros cambios, extensiones y nuevos requisitos. Parte de la comprensión es que el equipo que trabaja en la implementación actual, probablemente cambiará con el tiempo, por lo que los arquitectos buscan soluciones de bloques de construcción que sean fáciles de aprender, que permitan a los nuevos miembros del equipo hacer cambios en el código sin miedo y que tengan suficiente cobertura de pruebas para validar los cambios. La arquitectura continua reconoce la necesidad de desarrollar con patrones reutilizables, pero también entiende que la creación de un plano perfecto no es realista, dada la rapidez con la que cambian las necesidades del negocio y evolucionan las tecnologías.