Tecnología de DevOps: infraestructura de nube

Muchas organizaciones están adoptando la computación en la nube. Sin embargo, la computación en la nube no solo se trata de comprar la infraestructura desde un proveedor de servicios en la nube. El Instituto Nacional de Estándares y Tecnología (NIST) de EE.UU. define cinco características esenciales de la computación en la nube:

  • Autoservicio a pedido: Los consumidores pueden aprovisionar recursos de procesamiento según sea necesario, sin la interacción humana del proveedor.
  • Acceso amplio a la red: Se puede acceder a las funciones a través de diversas plataformas, como teléfonos celulares, tablets, laptops y estaciones de trabajo.
  • Agrupación de recursos: Los recursos del proveedor se agrupan en un modelo de varios usuarios, con recursos físicos y virtuales asignados de forma dinámica a pedido. El cliente puede especificar la ubicación en un nivel de abstracción mayor, como país, estado o centro de datos.
  • Elasticidad con rapidez: Las funciones se pueden aprovisionar de manera elástica y se lanzan para escalar con rapidez hacia afuera o hacia adentro a pedido, lo que hace que parezcan ilimitadas y que se las pueda usar en cualquier cantidad y en cualquier momento.
  • Servicio medido: Los sistemas en la nube controlan, informan y optimizan de manera automática el uso de recursos según el tipo de servicio, como almacenamiento, procesamiento, ancho de banda y cuentas de usuario activas.

En el Informe del estado de DevOps de 2019 de la Investigación y evaluación de DevOps (DORA), se descubrió que solo el 29% de las personas que afirmaron que habían adoptado las tecnologías de la nube coincidieron en que cumplían con las cinco características que se definieron antes. En 2018, y 2019, la investigación de DORA descubrió que las organizaciones con un rendimiento superior tenían 23 veces más probabilidades de cumplir con las cinco características esenciales de la nube en comparación con las que tienen un bajo rendimiento. Esto puede explicar por qué los equipos y ejecutivos que afirman tener las tecnologías de computación en la nube también expresan frustración cuando no obtienen los resultados esperados.

Debido a que muchas organizaciones aún usan sus procesos y prácticas de centros de datos tradicionales para administrar su infraestructura de nube, no pueden lograr los beneficios esperados, que según la investigación de DORA incluyen los siguientes:

  • Rendimiento de entrega de software mejorado: Capacidad de procesamiento más rápida y niveles de estabilidad más altos
  • Mejor disponibilidad del servicio
  • Visibilidad de costos mejorada: En 2019, descubrimos que los encuestados que cumplieron todas las características esenciales de la nube tienen 2.6 veces más probabilidades de estimar con precisión los costos de operar el software. También tienen el doble de probabilidades de poder identificar con facilidad las aplicaciones más costosas a nivel operativo.

Por ejemplo, muchas organizaciones con infraestructura de nube no permiten que los desarrolladores puedan usar la modalidad de autoservicio para sus entornos a pedido. En cambio, se les pide que abran tickets o envíen correos electrónicos y deben esperar días hasta que los entornos se aprovisionen o hasta que se realicen los cambios de configuración. En este caso, por más que la organización puede pagar por un servicio de nube, no tiene una nube según la definición del NIST.

Cuando se migra a la nube, las organizaciones deben invertir en rediseñar los procesos y las prácticas que implementaban cuando usaban los centros de datos tradicionales. Además, deben adoptar prácticas y patrones nativos de la nube para lograr la agilidad, la estabilidad, la disponibilidad y la transparencia de costos de la computación en la nube. Si la tecnología subyacente está en la nube, pero los resultados de los profesionales permanecen sin cambios (se necesitan días o semanas para obtener entornos de pruebas, aprovisionar infraestructura nueva o realizar cambios en la configuración), las organizaciones no obtendrán los resultados que desean.

Cómo implementar la infraestructura de nube

Adoptar prácticas y procesos nativos de la nube para implementar las cinco características del NIST implica cambios importantes en varias funciones de TI, como desarrolladores, equipos de operaciones, seguridad de la información, adquisición y finanzas. Los cambios requieren una estrecha colaboración entre estas funciones para identificar y resolver objetivos contradictorios.

Por ejemplo, muchos desarrolladores esperan un control total sobre la infraestructura de producción cuando usan plataformas en la nube. Los profesionales de seguridad de la información no están de acuerdo con esta práctica y tienen un buen motivo, puesto que, sin una administración de cambios disciplinada, la infraestructura de nube puede convertirse en una obra de arte frágil difícil de administrar, vulnerable a las amenazas externas y que no cumple con los requisitos reglamentarios.

Sin embargo, los desarrolladores pueden estar capacitados para aprovisionar los recursos que necesitan mientras cumplen con estos requisitos. Muchas organizaciones adoptaron el paradigma de infraestructura como código (GitOps es un ejemplo). La configuración de la infraestructura se verifica en el control de versión, y los desarrolladores pueden aprovisionar entornos, realizar cambios en la configuración y ejecutar implementaciones a través de un mecanismo automatizado. El mecanismo toma el código del control de versión y realiza operaciones a través de la API de la nube a pedido sin la intervención humana. A través del control de versiones y la automatización, todas las acciones y sus resultados se registran para proporcionar un seguimiento completo y la auditabilidad de cada cambio en cada entorno.

La infraestructura como código te permite administrar los cambios de forma efectiva y aplicar los controles de seguridad de la información. Por ejemplo, puedes implementar la división de tareas si exiges que todos los cambios en la configuración especificados en el control de versión estén aprobados por un miembro de un grupo específico de personas (como se hace en Google). Sin embargo, la migración a la infraestructura como código requiere un esfuerzo significativo de ingeniería y cambios de proceso, lo que incluye los cambios en las políticas para implementar los controles de seguridad de la información.

Considera otro ejemplo. Si bien los proveedores de servicios en la nube por lo general facturan por la infraestructura solo mientras está en uso (lo que cumple con la quinta característica de NIST, servicios medidos), este cambio de infraestructura de costo fijo a costo variable puede tener implicancias significativas en la adquisición y las finanzas. En cuanto a esto, el Informe de estado de DevOps de 2019 indica lo siguiente:

“Algunos en el departamento de finanzas podrían declarar que la nube no generó un ahorro de costos a corto plazo, pero sabemos que brinda una mayor transparencia en la información. ¿Cómo puede ser? Si bien la nube proporciona información transparente sobre los costos a los propietarios del sistema, los usuarios no pagan por estos costos, a menos que exista un modelo de devolución del cargo o un mecanismo similar. Esto puede generar costos muy variables que no estén verificados, lo que hace que los costos de la nube sean impredecibles. En estas situaciones, los equipos que pagan por la infraestructura pueden preferir centros de datos porque son predecibles, aunque su visibilidad impide que los usuarios del sistema creen sistemas más eficientes. Sugerimos a las organizaciones que nivelen mejor los incentivos con el fin de que los propietarios de sistemas tengan visibilidad para crear sistemas más eficientes y los incentivos para hacerlo, por medio de la devolución del cargo o mecanismos similares".

Además de considerar cómo se administra la infraestructura a nivel de configuración y finanzas, las aplicaciones a menudo deben volver a diseñarse para obtener los beneficios de aumento de estabilidad, confiabilidad y agilidad que la nube puede proporcionar. El nuevo diseño de los sistemas para un paradigma nativo de la nube se analiza en el informe de Google Cloud Cambia tu estructura a una nativa de la nube: un enfoque evolutivo para aumentar la productividad de los desarrolladores a gran escala.

La consideración más importante a tener en cuenta es si la implementación de la nube realmente ayudó a que tu organización logre versiones confiables y rápidas, además de niveles más altos de disponibilidad, velocidad y confiabilidad.

Errores comunes en la implementación de la infraestructura de nube

Los mayores obstáculos para cumplir con las cinco características definidas por NIST son los siguientes:

  • Nivelación y colaboración insuficientes entre las funciones de la organización que deben funcionar en conjunto para poder implementarse
  • Inversión insuficiente para el cambio de técnicas, de procesos y de la organización

Muchas organizaciones comienzan con un enfoque de lift-and-shift para migrar aplicaciones a la nube. Esto requiere un cambio mínimo en las aplicaciones y en procesos establecidos para administrar la infraestructura de nube y se puede realizar bastante rápido. Sin embargo, los beneficios que proporciona también son mínimos. Es importante planificar a fin de poder migrar más allá de lift-and-shift a un paradigma nativo de la nube para un software nuevo y los sistemas estratégicos existentes que continuarán evolucionando.

Migrar a la nube es un recorrido de varios años. Al igual que todos los cambios disruptivos, es importante comenzar con poco y experimentar con rapidez para descubrir qué funciona y qué no. Luego, se debe ser persistente y disciplinado sobre el escalamiento horizontal de los aprendizajes y los patrones y las prácticas eficaces a través de la organización.

En este recorrido, se presentan muchos obstáculos que se deberán superar, entre los que se incluyen los siguientes:

  • Rediseñar procesos, arquitectura y administración para cumplir con los requisitos reglamentarios nativos de la nube
  • Diseñar una arquitectura de infraestructura de varios usuarios que permita a los equipos usar la modalidad de autoservicio para realizar implementaciones y cambios de configuración mientras se garantiza una separación lógica entre los entornos, se habilita la devolución del cargo y se evita el uso excesivo de la nube y una infraestructura huérfana
  • Compilar una función de desarrollo de productos para tu plataforma de infraestructura de nube
  • Ayudar en la transición de adquisición a la infraestructura como un servicio medido en lugar de una inversión de capital
  • Ayudar a los desarrolladores a comprender cómo compilar aplicaciones nativas de la nube
  • Permitir que las operaciones migren a las prácticas modernas de ingeniería de confiabilidad de sitios (SRE), incluida la implementación de la infraestructura como código como reemplazo para la administración de configuración manual basada en tickets
  • Planificar y ejecutar la integración entre sistemas nativos de la nube y sistemas que no están basados en la nube, incluidos las unidades centrales y el software empaquetado o COTS

Para superar estos obstáculos, se requiere un programa de cambios sustanciales que incluya la inversión continua y la colaboración entre personas de todos los niveles de la organización.

Cómo medir la infraestructura de nube

Para decidir qué se debe medir, comienza por considerar los beneficios que esperas obtener de la implementación de la infraestructura de nube. Luego, comienza a medir el grado en el que se alcanzan esos beneficios.

Por ejemplo, si tu objetivo es mejorar la visibilidad de los costos, puedes realizar un seguimiento de tus logros para asegurarte de que los costos de infraestructura se facturen de forma correcta a la línea de negocio, el equipo, el producto o el entorno relevantes.

También puedes medir directamente si realizaste o no un buen trabajo con la implementación de las características esenciales de NIST. Para esto, debes preguntar a tus equipos cuánto están de acuerdo con las declaraciones de estas características que se enumeran al comienzo de este documento. Los equipos que están de acuerdo y los que están muy de acuerdo están dando buenos resultados; los equipos neutrales o que están en desacuerdo necesitan ayuda y asistencia para superar los obstáculos a fin de alcanzar estos resultados. Luego, considera cuántos equipos que afirman que usan la nube realmente pueden cumplir con los criterios de NIST.

Algunos aspectos de las características esenciales también se pueden medir directamente mediante la instrumentación de tus procesos. Por ejemplo, si tienes un proceso para administrar cambios en la infraestructura, podrías medir el tiempo total que se toma para realizar un cambio. También puedes ver cómo las tecnologías nativas de la nube prevalecen en tu organización; por ejemplo, la proporción de clústeres o máquinas administradas mediante Kubernetes o grupos de ajuste de escala automático en lugar del aprovisionamiento manual o el tiempo de actividad de los hosts. En los centros de datos, los tiempos de actividad largos suelen indicar una alta confiabilidad. En el paradigma nativo de la nube, los cambios de configuración suelen realizarse cuando se inician hosts virtuales nuevos con la nueva configuración, en lugar de realizar cambios en los hosts existentes. Esta práctica se conoce como infraestructura efímera, en la que un tiempo de actividad prolongado es un indicador de una máquina sin parches.

¿Qué sigue?