Cadenas de herramientas de entrega e implementación: Todavía sujeto al axioma del eslabón más débil
Hoy en día es casi imposible darse vuelta sin que alguien mencione su cadena de herramientas que respalda DevOps. Todos tenemos uno (sí, incluso nosotros) y todos ellos están habilitados por la (otra) economía API. Según Wikipedia , una cadena de herramientas de DevOps es: “un conjunto o combinación de herramientas que ayudan en la entrega, el desarrollo y la gestión de aplicações durante todo el ciclo de vida del desarrollo de software, según lo coordina 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 generalmente pasa gran parte de su vida (al menos eso esperamos). La misma definición funciona también para eso, con la salvedad de que su enfoque (según mi perspectiva) está en el “aprovisionamiento, la configuración y la gestión de servicios de red y aplicaciones durante todo el ciclo de vida de la aplicación, tal como lo coordina una organización que utiliza prácticas de DevOps”. En el contexto de DevOps tradicional, este enfoque amplía la fase de “lanzamiento” del ciclo y cubre las “actividades relacionadas con el lanzamiento” que incluyen el aprovisionamiento y la implementación de software en producción. Esto necesariamente incluye (o debería incluir) los servicios de red y de aplicaciones necesarios para permitir la entrega segura de aplicação a los usuarios objetivo.
El problema es que ningún proveedor ni proyecto de código abierto contiene todas las herramientas necesarias para lograr el sueño utópico de la implementación continua (que, por cierto, es el lado de producción). De hecho, algunas de las mismas herramientas que se utilizan en el lado de desarrollo de aplicaciones también se utilizan en el lado de producción. Cada vez vemos más cruces entre los dos mundos, lo que es una buena señal para “Devops” en general, ya que muestra cierta normalización entre dos organizaciones tradicionales muy arraigadas que tienen poco en común excepto la aplicación.
Por lo tanto, puede utilizar Puppet o Chef en combinación con VMware y Cisco para automatizar una pila completa de servicios de red y aplicaciones para satisfacer las necesidades de seguridad, identidad y escalabilidad de una aplicación. Ha creado las plantillas y los scripts correspondientes necesarios para hacerlo y ha verificado que sean correctos, quizás usando Postman y sus capacidades de scripting para realizar pruebas contra la infraestructura virtual en el laboratorio. Ha decidido que Git es una buena opción como repositorio para artefactos de configuración porque el desarrollador de aplicaciones ya lo usa y puede brindar orientación y tal vez incluso realizar una o dos sesiones de capacitación. E incluso podría ir más allá y comenzar a desarrollar una aplicación (o crear una implementación de OpenStack ) para orquestar el proceso y brindar autoservicio de servicios individuales. Básicamente estás definiendo la cadena de herramientas de implementación.
Y aquí es donde el axioma del eslabón más débil comienza a mostrar su fea cabeza. Estás familiarizado con la premisa: una cadena es tan fuerte como su eslabón más débil. Aquí se enfatiza “fuerte” porque podemos reemplazarlo con otras características como “confiable”, “seguro” o “escalable” y el axioma sigue siendo verdadero. Esto es importante porque a medida que se comienza a definir la cadena de herramientas que respaldará la implementación continua , cada “eslabón” de esa cadena puede convertirse en un punto de falla, donde se compromete la seguridad, la escala o la disponibilidad.
Así como la planificación, la verificación y la supervisión son vínculos críticos en la cadena de herramientas de DevOps, también deben serlo en la cadena de herramientas de NetOps. Esto es especialmente importante para la monitorización, donde las aplicaciones y la infraestructura (red y servicios de aplicaciones) se cruzan con mayor frecuencia en los entornos de producción. Es a través del monitoreo (visibilidad) que se puede tener una visión integral de todo, desde las transacciones comerciales hasta las solicitudes y respuestas individuales, en caso de una falla.
La configuración también une necesariamente las cadenas de herramientas, ya que la configuración de los servicios de red y de aplicaciones puede ser (y a menudo lo es) peculiar de una aplicação determinada.
Si bien los mecanismos de empaquetado y lanzamiento pueden aprovechar herramientas similares, son preocupaciones separadas que a menudo muestran una gran disparidad en términos de necesidades. Debido a que los servicios de red y aplicaciones pueden implementarse en una infraestructura compartida, las herramientas que suponen un enfoque de sistema único pueden no ser adecuadas para NetOps. Por el contrario, el uso de plantillas es cada vez más común para implementar rápidamente servicios estandarizados en producción, pero rara vez son aplicables en DevOps, donde las aplicações muestran un alto grado de singularidad.
De todos modos, ambas cadenas de herramientas comparten un hilo conductor común: la debilidad de un eslabón que infecta toda la cadena. Incluso si confía principalmente en implementaciones manuales que aprovechan los scripts, todavía existe una cadena de herramientas que representa el proceso general de entrega e implementación. Las personas pueden ser, y son, eslabones de las cadenas de herramientas que entregan e implementan software hoy en día. Y sucede que cuando falta un eslabón crítico –porque Bob está de baja por la última gripe– el proceso se interrumpe. La cadena de herramientas no puede entregarse (o implementarse).
Es importante que a medida que avanza en su transformación digital interna reconozca la importancia de las cadenas de herramientas DevOps y NetOps y no pase por alto ninguno de los vínculos que las componen. Si no prestamos atención a solo uno de los eslabones a medida que avanzamos hacia el objetivo de la implementación continua, debilitaremos toda la cadena. A medida que las empresas dependen cada vez más de estas cadenas interconectadas, un eslabón débil rompe más que sólo un proceso: rompe también el negocio.