Hoy en día, es casi imposible no oír a alguien hablar de su cadena de herramientas compatible con DevOps. Todo el mundo tiene una (sí, nosotros también) y todas ellas son posibles gracias a la (otra) economía de las API. Según Wikipedia, una cadena de herramientas de DevOps es «un conjunto o una combinación de herramientas que facilitan la entrega, el desarrollo y la gestión de aplicaciones durante todo el ciclo de vida del desarrollo de software, coordinadas por una organización que utiliza prácticas de DevOps ».
Ahora bien, esto se centra principalmente en la aplicación, pero también está la parte de producción, donde el software suele pasar buena parte de su vida (o eso cabe esperar, al menos). La misma definición también es válida en este caso, con la salvedad de que su enfoque (desde mi punto de vista) se centra en el «aprovisionamiento, la configuración y la gestión de los servicios de red y de aplicaciones durante todo el ciclo de vida de la aplicación, coordinados por una organización que utiliza prácticas de DevOps». En el contexto del DevOps tradicional, este enfoque amplía la fase de «lanzamiento» del ciclo y abarca las «actividades relacionadas con el lanzamiento», entre las que se incluyen el aprovisionamiento y el despliegue del software en producción. Esto incluye necesariamente (o debería incluir) los servicios de red y de aplicaciones necesarios para permitir una entrega segura y protegida de las aplicaciones a los usuarios destinatarios.
La cuestión es que ningún proveedor ni proyecto de código abierto ofrece por sí solo todas las herramientas necesarias para hacer realidad el sueño utópico del despliegue continuo (que, por cierto, corresponde al ámbito de producción). De hecho, algunas de las herramientas utilizadas en el desarrollo de aplicaciones también se emplean en producción. Cada vez observamos más puntos de encuentro entre ambos mundos, lo cual es una buena señal para «DevOps» en general, ya que demuestra cierta convergencia entre dos áreas tradicionalmente muy arraigadas y con poco en común aparte de la aplicación.
Así, podrías utilizar Puppet o Chef junto con VMware y Cisco para automatizar una pila completa de servicios de red y de aplicaciones que satisfaga las necesidades de seguridad, identidad y escalabilidad de una aplicación. Habrás creado las plantillas y los scripts necesarios para ello y comprobado que sean correctos, quizá utilizando Postman y sus funciones de scripting para realizar pruebas con una infraestructura virtual en el laboratorio. Habrás decidido que git es una buena opción como repositorio de artefactos de configuración porque el equipo de desarrollo de aplicaciones ya lo utiliza y puede ofrecer orientación e incluso impartir una o dos sesiones de formación. Y puede que incluso vayas más allá y empieces a desarrollar una aplicación (o a poner en marcha una implementación de OpenStack ) para orquestar el proceso y permitir el autoservicio de servicios individuales. En esencia, estarás definiendo la cadena de herramientas de despliegue.
Y es ahí donde el axioma del eslabón más débil empieza a mostrar su lado más desagradable. Ya conoces la premisa: una cadena es tan fuerte como su eslabón más débil. Aquí se hace hincapié en «fuerte» porque podemos sustituirlo por otras características, como «fiable», «segura» o «escalable», y el axioma sigue siendo igual de válido. Esto es importante porque, a medida que empiezas a definir la cadena de herramientas que sustentará el despliegue continuo, cada «eslabón» de esa cadena puede convertirse en un punto de fallo que comprometa la seguridad, la escalabilidad o la disponibilidad.
Al igual que la planificación, la verificación y la monitorización son eslabones fundamentales de la cadena de herramientas de DevOps, también deben serlo en la de NetOps. Esto es especialmente importante en el caso de la monitorización, ya que es en los entornos de producción donde más confluyen las aplicaciones y la infraestructura (los servicios de red y de aplicaciones). En caso de fallo, la monitorización (visibilidad) permite obtener una visión integral de todo, desde las transacciones empresariales hasta las solicitudes y respuestas individuales.
La configuración también conecta necesariamente las cadenas de herramientas, ya que la configuración de los servicios de red y de las aplicaciones puede ser específica de una aplicación determinada (y a menudo lo es).
Aunque los mecanismos de empaquetado y publicación pueden utilizar herramientas similares, son aspectos independientes que a menudo presentan necesidades muy dispares. Dado que los servicios de red y de aplicaciones pueden desplegarse en una infraestructura compartida, las herramientas que presuponen un enfoque basado en un único sistema pueden no ser adecuadas para NetOps. Por el contrario, el uso de plantillas es cada vez más habitual para desplegar rápidamente servicios estandarizados en producción, pero rara vez resulta aplicable en DevOps, donde las aplicaciones presentan un alto grado de singularidad.
En cualquier caso, ambas cadenas de herramientas tienen algo en común: la debilidad de un eslabón afecta a toda la cadena. Aunque se recurra a despliegues principalmente manuales que aprovechen scripts, sigue existiendo una cadena de herramientas que representa el proceso global de entrega y despliegue. Las personas pueden ser, y de hecho son, eslabones de las cadenas de herramientas que actualmente entregan y despliegan software. Y cuando falta un eslabón crítico —porque Bob está de baja por la última gripe—, el proceso se viene abajo. La cadena de herramientas no logra realizar la entrega (o el despliegue).
A medida que avance en su transformación digital interna, es importante que reconozca la importancia de las cadenas de herramientas de DevOps y NetOps y que no pase por alto ninguno de los eslabones que las componen. No prestar atención a uno solo de esos eslabones mientras avanzamos hacia el objetivo del despliegue continuo debilitará toda la cadena. A medida que las empresas dependen cada vez más de estas cadenas interconectadas, un eslabón débil no solo interrumpe un proceso, sino también el negocio.
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.