Al meterse por primera vez en el cloud computing, muchos negocios asumen que simplemente replicando su ya existente infraestructura en la nube están cumpliendo con la estrategia. Pero, en realidad, se encuentran lejos de hallar las ventajas operativas y económicas del cloud. Según nuestro punto de vista, en la migración al cloud público existen cuatro etapas hacia la creación de una infraestructura TI realmente sostenible en la nube pública. ¿En qué etapa se encuentra tu empresa?
Descargar en formato infografía →
- Replicando las TI en la nube
- Reconstruir y automatizar
- Contenerización
- Computación realmente serverless
- Momento de evaluar tu progreso
Antes que nada, pongámonos en contexto. ¿Cómo están llevando las empresas la migración al cloud? Dependiendo de a quién creas. Gartner ha desarrollado una metodología de representación de la madurez y adopción de nuevas tecnologías (lo que ofrecen y lo que se puede esperar de ellas a largo plazo). Lo llama Hype Cicles y nos permite dibujar la realidad actual de la adopción de la nube.
El bombo y platillo alrededor del cloud, o bien está alcanzando lo que Gartner llama “el pico de las expectativas hinchadas” (en la que los primeros casos de éxito capturan la atención de muchos medios y sectores) o bien ya está cayendo rápidamente hacia “el mínimo de la desilusión” (en el que las primeras implementaciones fracasan a la hora de alcanzar las expectativas y las empresas empiezan a reevaluar su aproximación).
Para complicar más el asunto, Gartner añade servicios cloud avanzados (como serverless PaaS) en la curva ascendente de su ciclo del bombo publicitario. Tanto si es correcto como si no, las empresas se desviven para poder decir que sus estrategias TI “cloud first” están en orden.
Gartner predice que a lo largo del año que viene “el 90% de las organizaciones carecerá de una estrategia de integración de aplicaciones postmoderna y capacidad de ejecución, resultando en un desorden de integración, mayor complejidad y mayor coste”. La experiencia parece confirmar la conclusión de Gartner, principalmente porque existe una importante confusión acerca de qué significa realmente “cloud first” en términos de estrategia.
Etapa uno: Replicando las TI en la nube
Como hemos mencionado anteriormente, el primer paso en la migración a cloud público se suele centrar en replicar la infraestructura on-site en una plataforma en la nube. Como es comprensible, muchos piensan que ahí acaba el proceso. No solo son “propietarios” orgullosos de una plataforma que les es altamente familiar y que conocen por dentro y por fuera, sino que también resuelven uno de sus problemas más acuciantes: las restricciones de capacidad.
Los negocios pueden pasarse años en la etapa uno, simplemente escalando a medida que las demandas de procesamiento y almacenamiento incrementan. Y como todo resulta tan familiar, el modelo DevOps les permite seguir con normalidad, manteniendo el mismo nivel de productividad y eficiencia del que siempre han disfrutado. Pero si un negocio se queda en esta temprana fase de su estrategia cloud first, se encontrarán con que los primeros éxitos no prosperarán.
Etapa dos: Reconstruir y automatizar
También conocida como la fase del “¿Qué ha pasado con los ahorros en costes que nos prometieron?”, la etapa dos solo se inicia cuando el director financiero empieza a hacer preguntas de difícil respuesta. Aunque la organización puede haber reducido el gasto en hardware, los costes del cloud siguen escalando y nadie sabe del todo por qué.
El problema es que la ilimitada capacidad de la nube puede causar problemas imprevistos para desarrolladores e ingenieros de sistemas sin experiencia en cloud. Los desarrolladores pueden usar tantos servicios cloud como quieran, pero serán facturados bajo un modelo de pago por uso. Por lo que muchas empresas se encuentran con sus equipos asignando recursos ineficazmente o innecesariamente.
No es casual que esta etapa coincida con el llamado “mínimo de la desilusión” de Gartner: las empresas se encuentran con problemas tras la etapa uno, forzando una reevaluación de la estrategia y despliegue cloud. Como dijo David Stanley, Head of Platform Delivery de Trainline, sobre las experiencias cloud de su empresa, “el mayor cambio cultural a realizar una vez hechos todos los cambios DevOps es centrarse en los costes”.
Sometido al escarmiento del director financiero, el departamento de TI empieza a rediseñar sistemas para alinearlos con los roles con los que se calculan los costes de la nube pública. Por ejemplo, creando usuarios y grupos el negocio puede controlar quién tiene permisos para solicitar recursos del cloud público. Inmediatamente, los sistemas se vuelven más eficientes en términos de operaciones y costes.
A medida que se adquiere más experiencia con las tecnologías cloud, los desarrolladores también aumentan el nivel de automatización de sus sistemas alojados. Como ejemplo, volviendo a los principios del procesamiento por lotes de antaño, las máquinas virtuales se levantarán durante las horas de menor actividad para reducir los costes de operación.
La funcionalidad de autoescalado de AWS, por ejemplo, permite a los desarrolladores limitar el escalado de recursos en base a una planificación, asegurando que hay recursos disponibles de acuerdo con las demandas predichas y liberándolos fuera de aquellas horas para alinear el gasto con el uso.
Con los sistemas rediseñados para el cloud y la automatización utilizada para optimizar operaciones, las facturas volverán a estar bajo control y el director financiero será mucho más feliz. Puede que se deba incrementar el gasto, pero este proceso de racionalización asegura la contención de costes y que estos estén 100% justificados.
Aunque los costes estén bajo control, la infraestructura alojada continúa relativamente intensiva en recursos en cuanto a la gestión. Al final de la etapa dos, las aplicaciones aún residen en máquinas virtuales instaladas en un hipervisor, que a su vez se encuentra por encima de la capa del cloud.
Muchos de estos sistemas virtualizados serán de instalar y olvidar, pero esto es para minimizar el trabajo que implica configurarlos en el punto de despliegue. También está el hecho de que algunas veces se requerirán cambios de configuraciones a gran escala y el equipo de TI necesitará dedicar esfuerzos en asegurar que los sistemas continúan operando como se espera.
Con aplicaciones, binarios y librerías, el sistema operativo virtualizado y un hipervisor instalados encima del sistema operativo del host, hay múltiples niveles que requieren ser administrados. Aquí es donde la etapa tres tiene lugar, con el objetivo de simplificar la arquitectura de la aplicación y reducir costes de gestión y uso de recursos cloud.
Utilizando un motor de contenedores como Kubernetes o Docker instalados correctamente por encima del SO virtualizado, los desarrolladores pueden rediseñar aplicaciones sin necesidad de un hipervisor o máquina virtual. El código es compilado y operado en un “contenedor”, que contiene nada más que las dependencias requeridas para la aplicación. Esto ofrece varias ventajas:
- La aplicación contenerizada es mucho más ligera, ayudando a reducir las demandas de recursos del servidor y costes de operación.
- La aplicación se vuelve más portable, permitiendo ser redesplegada en otros servicios cloud con el mínimo esfuerzo.
- Los desarrolladores se pueden centrar totalmente en crear la aplicación o servicio, sin tener que preocuparse del sistema operativo o factores secundarios que complican el proceso.
- Con menos capas que gestionar, los administradores e ingenieros son libres para centrarse en otros proyectos más estratégicos.
Como bonus, una mayor reducción en la demanda de recursos del servidor también ayuda a reducir más los costes, lo que significa aún menos engorros del director financiero.
Etapa cuatro: Computación realmente serverless
Hacia el final de la etapa tres, los recursos computacionales han sido drásticamente optimizados, reduciendo el peso de la aplicación y los costes de operación, e incrementando la portabilidad del código. De nuevo, nos tienta el pensar que el proceso de migración a la nube se ha completado, pero aún hay mejoras que hacer.
En este punto, las aplicaciones son construidas en contenedores autónomos, pero la plataforma Docker en la que están construidas aun consume recursos del servidor dentro del data center del proveedor cloud. En muchos casos, los desarrolladores operan máquinas virtuales completas dentro de sus contenedores. Esto no es necesariamente malo, pero las aplicaciones pueden optimizarse más y, a cambio, se reducen los costes y esfuerzo de desarrollo.
Más preocupante es el hecho que, conservando un SO dentro del contenedor, el entorno mantiene los mismos costes de administración y seguridad. Los esfuerzos iniciales pueden aportar una mayor densidad de máquinas virtuales, pero incluir el SO en el contenedor hace más bien poco por reducir la complejidad del mantenimiento y los costes de operación.
La última etapa de la migración cloud first consiste en desarrollar y desplegar aplicaciones “serverless”. Como el nombre indica, estas aplicaciones están diseñadas para rebajar la dependencia hacia Kubernetes, Docker y servidores cloud tanto como sea posible. En lugar de recurrir a aplicaciones y máquinas virtuales totalmente compiladas, las aplicaciones serverless están construidas utilizando librerías y binarios enlazados con APIs proveídas por servicios de cloud pública.
Simplificando, las aplicaciones serverless cogen los bloques de construcción suministrados por varios servicios online y los “pegan” juntos. Esencialmente, las aplicaciones en la etapa cuatro se benefician de la “función como servicio” para disminuir costes.
Estas aplicaciones siguen siendo infinitamente escalables, recurriendo a recursos de terceras partes cuando se requiere, pero con una huella local mínima. Enlazar servicios de este modo incrementa la velocidad de desarrollo y reduce el nivel de mantenimiento necesario para afrontar las actualizaciones de los servicios que se utilizan.
Y como tus nuevas aplicaciones dependen de servicios a nivel SaaS ofrecidos por terceras partes, no hay necesidad de ajustar la configuración de componentes como httpd o MongoDB, que son gestionados por los proveedores. Siempre habrá un coste operacional para aplicaciones basadas en la nube, pero externalizando la infraestructura y las responsabilidades de SO a proveedores de servicios, el coste interno de operación se verá aún más reducido.
Momento de evaluar tu progreso
Una vez esbozada tu migración al cloud first, es mucho más fácil evaluar qué ha alcanzado tu empresa. Muchos late adopters se encontrarán aún en la etapa uno, por lo que tienen por delante un buen trecho por recorrer. Muchas organizaciones habrán alcanzado la etapa dos, pero solo si han investigado cómo utilizar mejor la infraestructura cloud para mejorar sus propias operaciones.
El cloud computing es un cambio drástico en las TI empresariales y muchos aún están aprendiendo cómo beneficiarse de él al máximo. La falta de competencias se ve agravado por el rápido ritmo de desarrollo de AWS, Azure y Google Cloud Platform, por lo que poco sorprende que a las empresas les cueste alcanzar sus objetivos cloud first, especialmente cuando las estrategias realmente cloud first apenas son comprendidas.
Te puede interesar