Lo que podemos aprender sobre la escalabilidad a partir de la virtualización

A medida que la virtualización comenzó a afianzarse, se propusieron diversas métricas para medir el éxito. Los índices de consolidación, la proporción de administradores por máquina virtual , el tiempo de aprovisionamiento y el porcentaje de servidores virtualizados estaban entre los más utilizados para medir y calificar el éxito de los proyectos de virtualización.

Hoy observamos cómo DevOps comienza su ascenso y se proponen métricas similares para medir su éxito. El tiempo de comercialización, el tiempo medio de recuperación, el tiempo de entrega del cambio y la frecuencia de implementación son algunas de las medidas más comunes que se mencionan cuando nos centramos en la "M" en la definición CAMS (Cultura, Automatización, Medición, Intercambio) de DevOps.

Estos son buenos y necesarios, pero hay un beneficio (un caso de uso, por así decirlo) de DevOps que rara vez se analiza y que es igualmente crítico: la escala operativa.

Es el mismo problema que SDN intenta resolver “en la red” a través de la operacionalización, permitiendo que la escala de los equipos a través de la tecnología coincida con la tasa de crecimiento deseada y experimentada por el negocio gracias al rápido crecimiento de las aplicações móviles y web. Se trata de un clásico problema “30/30/3” que resulta del crecimiento de los datos que incrementa los costos de TI (transporte, procesamiento y almacenamiento) con solo un aumento mínimo en los ingresos. Para resolver este problema es necesario centrarse en el único aspecto de la ecuación sobre el que tenemos control: los mayores costos de TI. Así que si quieres llamarlo SDN, adelante. Si quieres llamarlo DevOps para la red, adelante. Si quieres llamarlo SDDC, ¿por qué no? Llámalo nube también, si eso te gusta. Todas ellas tienen una premisa común: la escala operativa rápida es fundamental para el crecimiento.

No se trata sólo de recursos de hardware y software; también se trata de cómo aprovisionamos y gestionamos esos recursos. Es una necesidad de reducir la cantidad de esfuerzo requerido para administrar el conjunto de recursos (hardware y software) necesarios para implementar y entregar una aplicação .

Ahí es donde la “A” de “Automatización” juega bien a la hora de reducir los costos de TI necesarios para cambiar la ecuación de crecimiento y permitir que la escala respalde un mayor crecimiento empresarial. 

Pero no es sólo una visión superficial de la automatización lo que necesitamos. Si bien la automatización (utilizando scripts y orquestación para impulsar el aprovisionamiento y la gestión y los procesos operativos necesarios para implementar servicios y aplicaciones) es importante, no olvidemos el papel fundamental que desempeña la “infraestructura como código”.

Podemos lograrlo en parte echando un vistazo a la máquina del tiempo para ver el éxito de la virtualización en la escalabilidad de la gestión de los recursos informáticos (en gran medida) gracias al tratamiento de esa infraestructura “como código”.

Lo sé, lo sé, en realidad no era código en el sentido de que no era un script ni un archivo de configuración ni nada que pareciera “código”. Pero se trató “como código” en el sentido de que utilizamos repositorios centralizados de “imágenes doradas” desde las cuales aprovisionar y configurar servidores rápidamente. Servidores web, servidores de aplicaciones, servidores de datos. Se idealizaron distintos tipos de servidores a partir de una “imagen” predefinida que permitía a los operadores escalar.

Y cuando digo escala, me refiero a ESCALA. Si bien se manejan muchos números, no era inusual en 2011 encontrar organizaciones con una relación administrador: servidor virtual de 1:350. Algunos afirmaban más de 1:500 a 1:1000, mientras que otros, simplemente desconcertados por el tamaño de su organización, sólo podían afirmar 1:100 o 1:150. Un informe de 2012 que analizó datos de varios informes de referencia de TI señaló que la relación administrador: servidor era de 1: 50-75 para servidores físicos y 1:185-450 para servidores virtuales.

En términos de escala, eso es asombroso. Esto permite el crecimiento sin los costos de TI generalmente más altos que vienen con el proceso.

Ahora, consideremos que la relación ingeniero-dispositivo media en empresas de todos los tamaños es de aproximadamente 1:36. Eso en sí mismo es interesante, ¿no crees? La proporción no parece cambiar a medida que el negocio crece. Lo cual es algo malo y simplemente contribuye al problema 30/30/3.

Pero si pudiéramos cambiar eso de alguna manera, aunque sólo fuera duplicar los dispositivos por ingeniero, reduciríamos los costos de crecimiento y permitiríamos una mejor escala de toda la red.  Para lograrlo, debemos emular el éxito de la virtualización. No necesariamente utilizando virtualización, sino utilizando los conceptos que le permitieron soportar proporciones increíbles de administradores por servidores: infraestructura como código y automatización.

La razón por la que no podemos simplemente crear imágenes doradas de conmutadores y balanceadores de carga y los más de 20 servicios de aplicaciones L4-7 que sabemos que las organizaciones están empleando para entregar y proteger sus aplicações es porque cada configuración es única, está centrada en la aplicación y eso significa que, si bien es posible utilizar software (virtual) e implementar una imagen base dorada para cualquiera de esos servicios, aún así se necesitará que alguien haga la configuración. Y no es una configuración sencilla.

¿Estás configurando algunos servicios de aplicaciones para Exchange? Se requieren más de 80 objetos diferentes para crearlos, configurarlos y asociarlos correctamente para obtener la disponibilidad, el rendimiento y la seguridad necesarios.

Ciertamente es aquí donde se incurre en tiempo (y sus costes asociados) “en la red”.

Y aquí es donde necesitamos escalar. Dónde necesitamos tratar la infraestructura “como código”.

Esta es la razón por la que las plantillas están incluidas en el componente “A” de Automatización de DevOps. Porque las plantillas permiten que las operaciones de red (y de seguridad también) traten configuraciones comunes “como código” que se pueden administrar en un repositorio central. La plantilla se convierte en la “imagen dorada” a partir de la cual se aprovisionan y configuran los servicios de la aplicación. Ese enfoque permite una automatización y una orquestación que imitan la del aprovisionamiento de máquinas virtuales y proporciona la base para la escalabilidad operativa que las organizaciones necesitan para permitir el crecimiento del negocio.

DevOps, SDN, SDDC e incluso la nube no solo tratan de mejorar el tiempo de comercialización o reducir los costos operativos. También son clave para una escala eficiente que posibilite, en lugar de impedir, el crecimiento del negocio. El costo de agregar más y más operadores o ingenieros para administrar los recursos crecientes en todo el centro de datos (computación, red, seguridad, almacenamiento) va a devorar el crecimiento que surja de esa escala. Escalar de manera más eficiente utilizando la automatización y tratando la infraestructura como código puede ser una forma de gestionar la escala necesaria para respaldar el crecimiento deseado por la empresa.