Como código: la pila de TI continua
Siempre hay términos asociados con cualquier tendencia tecnológica que rápidamente se llenan de tanta publicidad que pueden resultar prácticamente inútiles. Cloud era uno, en el principio. En cierto sentido, todavía lo es. DevOps tardó varios años en implementarse (si es que se logró). Actualmente, el aprendizaje automático y la inteligencia artificial se encuentran surfeando descalzos en la ola de la moda y no muestran señales de desaparecer en el corto plazo.
Muy de cerca, detrás de todos ellos, se encuentra "como código".
De repente todo es "como código". El mercado no se cansa del "código como código", aunque la mayor parte no puede diferenciar entre C, C++ y C#. "Como código" se ha convertido en la respuesta a la vida, al universo y a todo. No hay ningún problema que "el código" no pueda resolver, y todo el mundo lo está haciendo.
Es importante que, cuando se utilizan términos sin límites ni definiciones claras, hagamos una pausa y nos aseguremos de tener claras *nuestras* definiciones. Sería bueno que hubiera un comité de normas con una definición estilo RFC al que hacer referencia, pero no lo hay. Lo más cercano que tenemos es el NIST, y vimos lo bien que pudieron resolver el enigma de la nube.
El "código como código" implica mucho más que simplemente infraestructura como código (IAC). Aiman Najjar @ Pythian escribió una excelente descripción general del panorama actual de infraestructura como código . Si bien no estoy de acuerdo en que los contenedores deban ser su propia capa (es solo infraestructura desde la perspectiva de la red y los servicios de aplicação ) y que Jenkins no pertenece allí, en general su blog fue una excelente manera de comprender la relación de las capas "como código" y mapear las herramientas adecuadas para el trabajo adecuado. Además, la mayoría de los debates sobre infraestructura como código se centran en la entrega continua, es decir, el proceso que crea, prueba, integra y lanza una aplicación a producción. Este no es el mismo proceso que la implementación continua, que se centra en tomar la aplicação lanzada e implementarla en un entorno de producción junto con los servicios de aplicação y red necesarios.
NOTA: En App Utopy, los canales de entrega e implementación convergen. Pero la mayoría de nosotros (todavía) vivimos en la realidad de las aplicaciones, donde la producción y el desarrollo son entornos separados con diferentes conjuntos de requisitos y restricciones. De ahí la necesidad de reconocer esta separación cuando aplicamos la automatización al pipeline.
Hay tres capas distintas que se elevan para cubrir las excentricidades innatas a la TI y al proceso de implementación. La más importante de ellas es la complejidad inherente al medio ambiente. Esa línea recta que dibujamos en los diagramas de red desde el cliente hasta la aplicación no engaña a nadie. Simplemente están sucediendo muchas más cosas bajo el capó de las que tenemos tiempo (y paciencia) para diagramar.
La diversidad del propio pipeline (que comprende hardware especialmente diseñado así como software virtual y basado en contenedores implementado en COTS) también proporciona el impulso para segmentar y cortar "como código" en capas separadas. Si bien es cierto que el hardware más moderno se puede administrar a través de un enfoque de código, puede resultar casi imposible incluir hardware heredado (compartido) en el proceso. Separar las capas, entonces, para reflejar más de cerca el proceso de implementación en sí puede proporcionar una manera de incluir soluciones basadas en hardware tanto tradicionales como modernas junto con servicios basados en software en el proceso.
El objetivo es construir una pila de TI continua capaz de soportar arquitecturas y cronogramas de implementación por aplicación en un entorno de múltiples nubes. Y como la implementación es solo el comienzo del ciclo de vida activo de una aplicación, es necesario que haya una cuarta capa que se centre en las operaciones posteriores a la implementación. Esto se suma a las tres capas principales que cubren el aprovisionamiento y la incorporación de infraestructura, la configuración y gestión de servicios, y el proceso de implementación.
La lista de herramientas no debe considerarse exhaustiva. Hay muchas otras herramientas y conjuntos de herramientas. Por ejemplo, sabemos a partir de múltiples encuestas e investigaciones que la mayor parte de NetOps prefiere scripts de Python personalizados para la tarea de automatizar servicios de red y aplicação . Y también sabemos que los sistemas y pilas de automatización de red como Cisco ACI, VMware NSX, OpenStack y Red Hat OpenShift son medios populares para implementar muchas funciones en la pila de operaciones continuas. Simplemente no hay suficiente espacio en el elemento visual para incluir todas las herramientas, por lo que se ha incluido una muestra basada en la popularidad de las herramientas con DevOps. Esto se debe a que la estandarización en todo el proceso de entrega e implementación será un componente esencial del éxito y es difícil argumentar en contra del aprovechamiento de las habilidades y la experiencia existentes en su organización con las herramientas que se usan más comúnmente para implementar procesos de entrega "como código". Es importante destacar que no he enumerado ninguna herramienta para "operaciones como código" porque muchas de ellas son personalizadas (scripts personalizados) o específicas de la tecnología de un proveedor, al menos por ahora.
NOTA Las operaciones como código son el equivalente en TI de la gestión de procesos de negocio (BPM). Con BPM se automatizan los procesos de negocio. Algunos BPM se centran únicamente en flujos de trabajo muy específicos, mientras que otros pueden cubrir toda la extensión de la interacción con el cliente, desde la compra hasta el pago y la entrega. Las operaciones como código son una práctica incipiente en TI hoy en día, pero deberán madurar hasta convertirse en gestión de procesos operativos si las empresas quieren aprovechar la optimización de los procesos operativos de la misma forma en que han aprendido a aprovechar BPM.
Pila de operaciones continuas
Infraestructura como código (IaC)
Ya sea en la nube o en el centro de datos, todavía hay una red que necesita configurarse. Incluso los servicios de orden superior (aquellos que operan en las capas 4 a 7, también conocidos como servicios de aplicação ) requieren cierto conocimiento de la topología de la red para funcionar. Es posible que sea necesario activar parte de esto (es decir, obtener licencia) si estás implementando un pipeline completamente nuevo. La infraestructura como código es necesaria para permitir un enfoque de autoservicio para la implementación, ya que sin la infraestructura (software y servicios) en su lugar, no hay nada que configurar o implementar una aplicación.
Responsabilidades: incorporación de infraestructura , licencias, aprovisionamiento
Configuración como código (CaC)
Este es un tema separado de la configuración, que habla específicamente de la necesidad de configurar políticas y comportamientos específicos para el servicio en cuestión. La configuración puede repetirse con cada actualización importante de la aplicação . También podría repetirse este problema con cada actualización menor. En el caso de servicios relacionados con la seguridad, puede ser necesario aplicar un parche, actualizar o mejorar un servicio determinado en situaciones de emergencia. La configuración como código es fundamental para respaldar los cronogramas y los canales de implementación por aplicación, y para reforzar el aislamiento de las rutas de datos de la aplicação , lo cual es importante para garantizar la estabilidad del canal de producción en su totalidad.
Responsabilidades: configuración del servicio , actualización y parcheo.
Canalización como código (PaC)
Luego está el proceso general que define toda la aplicação y sus servicios de principio a fin. Es todo el proceso y está codificado en un proceso ejecutable que impulsa automáticamente la implementación. La canalización como código es el vínculo entre IaC y CaC que los une para describir lo que llamamos una canalización de implementación. Es en el pipeline donde se encontrarán las mayores ganancias en velocidad y eficiencia, ya que permite eliminar tiempos de espera entre los pasos necesarios en el proceso.
Responsabilidades: automatización del proceso de implementación
Operaciones como Código (OaC)
Esta capa es la capa operativa continua. Es donde se producen la monitorización, las alertas, el escalado automático y el descubrimiento. En esta capa nos ocupamos de codificar los procesos operativos en un sistema capaz de ejecutarlos por sí solo. El escalamiento automático es uno de los procesos operativos más codificados e involucra múltiples sistemas. Pero la recopilación de telemetría para el análisis es otro proceso operativo que necesita atención, al igual que las posibles acciones tomadas en función de esa telemetría que permiten ajustes (automáticos) para optimizar la ruta de datos o el rendimiento de la aplicação . Estos procesos operativos tienen su propia configuración y entran en juego una vez finalizado el proceso de implementación.
Responsabilidades: automatización del flujo de trabajo operativo
Considerar la implementación continua a través de la lente de la pila de operaciones continuas puede proporcionar un enfoque estratégico para automatizar la cadena de producción. Al separar las capas y responsabilidades, es más fácil abordar la difícil tarea de automatizar las tareas de TI de un modo que posibilite el enfoque de autoservicio deseado por muchas organizaciones y cada vez más demandado por las empresas. También permite un camino hacia operaciones continuas a través de operaciones como código, lo que supone una evolución necesaria en el uso de la automatización dentro de TI.
Ahora bien, puede que esta no sea la "única forma verdadera" de ver los esfuerzos de automatización asociados con el proceso de implementación. Pero es una forma, y permite que el mercado diga claramente lo que hace o lo que no hace.
Significa que puedes estar seguro de a qué me refiero cuando hablo de infraestructura como código o configuración como código , especialmente con respecto a los productos F5.