Si tienes hijos (e incluso si no los tienes, aquí no juzgamos a nadie), probablemente te haya tocado ver La LEGO película. Más de una vez.
En mi opinión, probablemente debería ser de visionado obligatorio para cualquier empresa que esté considerando adoptar DevOps.
En serio.
Esto se debe a que una de las (muchas) lecciones aprendidas es que incluso los Maestros Constructores, expertos en su ámbito particular, necesitan colaborar con otros para salvar el mundo y llevar una aplicación al estado de despliegue deseado. Es decir, a un estado en el que no se quede atascada en producción por culpa de ese aterrador Kragle tecnológico que son los procesos manuales.
Por separado, los maestros constructores son capaces de imaginar no solo lo que quieren construir, sino también todas las piezas que necesitan para hacerlo. Y en la película lo demuestran a menudo, y de forma admirable, creando en un abrir y cerrar de ojos construcciones completas capaces de golpear, volar, competir y disparar a diestro y siniestro para salvar la situación. Pero, cuando llegó el momento de abordar el panorama «general» —es decir, no solo crear construcciones individuales, sino también orquestar (¿veis lo que he hecho ahí?) una serie de acontecimientos para frustrar el plan del Malvado—, no fueron capaces. Necesitaban al tipo al que le gustaba consultar las instrucciones y llevar una lista de comprobación con los procedimientos necesarios para que todos avanzaran en la misma dirección.
En nuestro caso, esa dirección es producción.
A medida que el despliegue continuo se convierte en una posibilidad real y en el objetivo último de DevOps, superando la barrera entre el desarrollo y el «resto de TI», surge una necesidad muy real de coordinación entre los cuatro ámbitos operativos (seguridad, almacenamiento, computación y redes) para garantizar que los principales responsables de cada conjunto de servicios y sistemas no trabajen de forma aislada.
Incluso los desarrolladores que adoptan los microservicios, con su principio de «código local e independiente de otros servicios», saben que esta mentalidad y este enfoque solo funcionan si existen unas interfaces (API) claramente definidas y documentadas con las que puedan comunicarse otros servicios. Estas interfaces no se desarrollan (o no deberían desarrollarse) de forma aislada, sin comprender cómo van a utilizarlas otros servicios.
Lo mismo ocurre en el lado de producción; los cuatro ámbitos operativos deben comunicarse en algún momento para que el despliegue continuo pueda llevarse a cabo. Existe un plan maestro, un conjunto de instrucciones que deben seguirse, independientemente de los detalles de cómo se construya cada servicio o conjunto de servicios. En algún momento, deben coordinarse dentro de un proceso global que impulse el despliegue de un extremo al otro de la cadena de producción.
Los maestros constructores de cada dominio no pueden trabajar de forma totalmente independiente. Deben coordinarse, colaborar y plantearse cómo encaja su pieza del rompecabezas en el gran plan para salvar el mundo (de las aplicaciones) sobre el que se sustenta actualmente la empresa.
Una de las formas de empezar es representar gráficamente los conjuntos de impacto. Recordé esto después de leer un artículo reciente sobre el acoplamiento de código, La regla del 80 % del acoplamiento de programas, desde la perspectiva de la seguridad. El artículo se centra mucho en el código y en crear lo que, en esencia, son grafos de dependencias dirigidos específicamente a profesionales del desarrollo. Sin embargo, si se eleva el nivel de abstracción y se consideran las funciones, los procedimientos y los métodos como sistemas en producción, se empieza a ver la utilidad que esto podría tener. Comprender el grado de dependencia que tiene el despliegue de una aplicación respecto a determinados servicios (o incluso, para empezar, a nivel de dominio) puede aportar información valiosa para determinar cuánta coordinación será necesaria entre los distintos grupos para llevarlo a cabo y poder trazar un plan que permita alcanzar ese objetivo.
Uno de los mejores ejemplos es que prácticamente todo depende de que se implementen los servicios de red básicos primero. Esto se aplica no solo a la aplicación y a sus componentes dependientes, sino también a los servicios de seguridad y de nivel superior (de aplicaciones) que permiten ofrecerla. El balanceo de carga, la seguridad de las aplicaciones web e incluso el cortafuegos dependen de los atributos de red para funcionar. Comprender esas dependencias (el factor de acoplamiento) entre los sistemas y servicios gestionados por distintos grupos (silos) dentro del departamento de TI puede contribuir en gran medida a impulsar la necesidad de comunicarse y colaborar para lograr siquiera algo parecido a una implementación continua.
Incluso los maestros constructores tienen que entender cómo encaja su creación en el conjunto. Aplicar técnicas y herramientas de desarrollo al mundo de las operaciones de TI, cada vez más automatizado y basado en código, les ayudará a crear mejor las interfaces necesarias para integrar su pieza del rompecabezas en el gran proyecto de construcción que supone el despliegue continuo.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.