La nube promete mucho. Gran parte de lo que ofrecen las grandes empresas de plataformas cloud es tan real, alcanzable, flexible y tan potente y expansivo como siempre ha prometido la razón de ser de la computación en la nube y su propuesta tecnológica.

Pero no todo lo que nos dicen los evangelistas, futuristas y defensores de la nube se cumple siempre de la manera perfecta. Más allá de los inconvenientes, matices e incompatibilidades más básicos de la implementación de cualquier proyecto en la nube, existen algunas lagunas más amplias en cuanto a lo que se puede lograr en la práctica en muchos casos. 

¿Son estas lagunas de implementación las tres mayores mentiras de la informática en nube? La compañía estadounidense CloudBolt Software señaló dónde existen algunas de estas carencias. Esta empresa es un proveedor de servicios de gestión cloud para empresas que trata de ofrecer a sus clientes sistemas de orquestación de la nube viables y eficientes que funcionan con autoservicio, seguridad y automatización. El último informe realizado por esta empresa sobre el sector, The Truth About DevOps in the Hybrid Cloud Journey (La verdad sobre las operaciones de desarrollo en la nube híbrida), pone de relieve las deficiencias del modelo, como preludio, eso sí a su oferta de soluciones.

CloudBolt destacó lo que podrían ser algunos de los problemas más importantes que se experimentan de base. En particular, esta foto de los líderes de DevOps en la nube en empresas de tamaño considerable (al menos 1.000 empleados) sugirió que hay una falta de autoservicio, una grieta en los procesos de pruebas y una debilidad no deseada en la tensión que necesitamos para que la verdadera computación continua de CI/CD ocurra sobre una base 24×7.

Falta autoservicio

El autoservicio en términos de nube describe un despliegue en el que las operaciones diarias se ejecutan sin la necesidad indebida de recurrir a los servicios del proveedor de servicios en la nube (CSP). Esto significa que la nube de autoservicio se ejecuta con un esfuerzo mínimo en relación con tareas como el procesamiento y el rendimiento diarios, y luego con la elaboración de informes, la actualización y el mantenimiento de parches, las tareas de autoescalado y, en última instancia, el aprovisionamiento de instancias nuevas o modificadas de la nube.

Desde CloudBolt afirmaron que la falta de autoservicio (que, por supuesto, sus profesionales, indican, pueden ayudar a solucionar) es difícil porque los procesos manuales y la incoherencia plagan los procesos de aplicaciones y datos en la nube.

Aunque el objetivo de CI/CD es desplegar aplicaciones de forma rápida y continua, la encuesta sugirió que tan solo el 15% de los clientes de la nube hacen despliegues una vez al día. Uno de los principales problemas es la fontanería de la nube; la configuración de los componentes de la infraestructura de canalización de la nube requiere una gran cantidad de codificación manual y trabajo pesado por parte de los ingenieros de software. La promesa de la automatización de la nube (el “nos encargamos de todo”) puede tener algunas lagunas.

Grietas continuas

Las fisuras se encuentran en los procesos de pruebas. Existe una falta de fiabilidad percibida (y a menudo real) en las infraestructuras de CI/CD. El informe de CloudBolt afirmó que, para que el CI/CD funcione de forma eficiente, los desarrolladores deben ser capaces de desplegar pipelines de infraestructura y probar de forma fiable sus aplicaciones a medida que se desarrollan.

A pesar de que el 85% de los encuestados por CloudBolt afirmó que prueban continuamente su infraestructura, solo el 11% la considera fiable. 

Debilidad

Respecto al último factor mencionado por la compañía, la debilidad, está claro que la continuidad continua de CI/CD tiene que ser estrecha y no débil. La empresa afirmó que existe una necesidad real y presente de volver a poner el “continuo” en CI/CD.

Para avanzar en la visión de lo que CI/CD siempre debía ofrecer y hacerlo viable, CloudBolt sugirió que entre un tercio y tres cuartas partes de las organizaciones empresariales quieren un acceso más rápido a la infraestructura para sus pipelines (70%), pero también quieren la capacidad de detectar continuamente los problemas de infraestructura de los pipelines (por ejemplo, cambios inesperados en la computación, el almacenamiento, las configuraciones, las contraseñas, etc.) antes de que ocurran (62%), mejorando así la fiabilidad.

“El informe revela que, aunque los procesos y herramientas clave de DevOps, como la integración continua/entrega continua (CI/CD) y la infraestructura como código (IaC) han dado pasos significativos en la adopción generalizada, todavía existen oportunidades de mejora notables“, según Jeff Kukowski, director ejecutivo de CloudBolt Software.

Kukowski señaló que hay “lagunas notables” en la velocidad de aprovisionamiento de la infraestructura, las pruebas y la fiabilidad general que obstaculiza el avance en CI/CD en entornos modernos nativos de la nube. La Infraestructura como Código (IaC) debería utilizarse para permitir a los equipos no técnicos aprovechar sus beneficios y disfrutar de una mejor gobernanza y visibilidad. Estas son formas clave de crear una ventaja competitiva para los usuarios”, añadió.

“Sé la nube”

El director de tecnología de CloudBolt, Rick Kilcoyne, ha escrito su propia opinión sobre este tema en la entrada de un blog titulada Si no es autoservicio, no es una nube. Con una divertida referencia a la escena de Caddyshack, una película de 1980 en la que Chevy Chase insta a un joven a “ser la pelota”, la intención de Kilcoyne es sugerir que los equipos de TI modernos deberían “ser la nube”, es decir, que todo debería ser natural y funcionar sin complicaciones.

Kilcoyne hizo referencia a la definición de informática en la nube del Instituto Nacional de Normas y Tecnología (NIST) y afirmó que cualquier buena instancia de cloud debe tener estas cinco características esenciales: amplio acceso a la red, rápida elasticidad, servicio medido, agrupación de recursos y autoservicio bajo demanda.

“Para el último de ellos, el autoservicio bajo demanda, la prueba de la nube es sencilla. Si los usuarios pueden solicitar sistemas o aplicaciones y obtenerlos de inmediato (sin involucrar directamente al departamento de TI) es que logran un autoservicio bajo demanda. Si tienen que enviar un ticket y esperar a que un intermediario revise y satisfaga su solicitud, no es una nube”, según Kilkoyne.

No más CI-no

Aunque hemos señalado las pruebas del pipeline de la infraestructura, los fallos del bucle continuo y la forma exacta de desplegar la infraestructura como código como puntos clave, el elemento de autoservicio es probablemente el que resulta más tangible.

La idea del CIO desagradable que dice que no a los nuevos despliegues de TI (a estos perfiles se los denomina CI-no) porque la función de gestión de TI no puede aprobar el cambio con la suficiente rapidez no es un modelo que encaje en el mundo poscovid de la nube nativa. Con los aceleradores de autoservicio y automatización que funcionan dentro de sistemas seguros ya aprobados, los equipos pueden sacar más provecho de cloud sin crear un shadow IT o tecnología en la sombra.

En definitiva, si se hace bien, la nube se convierte en un buen negocio.

–IDG.es