El gasto en Cloud como métrica relevante 

Iniciativas y Objetivos 

Si la transformación digital nos ha dejado algo es la mentalidad del cambio constante, o de la mejora continua, según la cual cualquier compañía o individuo debe estar siempre en movimiento para cumplir sus objetivos. La clave está en avanzar a través de un flujo de pequeñas iniciativas revisables que provoquen cambios (en nuestros procesos, negocios, departamentos) y que su impacto pueda medirse para orientar la siguiente iniciativa.  

Este ciclo constante implica tener objetivos claros (que no necesariamente invariables), lanzar iniciativas con agilidad (para poder atribuir los resultados a las iniciativas y tener capacidad de iteración) y medir adecuadamente el impacto sobre los objetivos. 

Inicialmente puede parecer que medir el impacto de una iniciativa, en la era en la que las organizaciones almacenan toda la información con vistas a futuro, es algo sencillo. Sin embargo, tener los datos no proporciona la respuesta directamente. Lo difícil es interpretar dicha información y hacerse las preguntas adecuadas.  

Para medir si estamos logrando los objetivos tenemos que enlazar estos con unos buenos indicadores (KPIs) que estén claramente relacionados con los objetivos (además de contextualizados). Y después, identificar las métricas disponibles que se utilizarán para formular los KPIs. 

A veces la relación entre objetivo, indicador y métrica es sencilla y directa. Por ejemplo, si uno de los objetivos fuese incrementar las ventas anuales un 20%, el indicador sería la variación de ventas en el periodo de un año, y se calcularía a partir de las ventas que saldrían del CRM. 

En otras ocasiones la relación no es tan directa. Por ejemplo, si nuestro objetivo fuese aumentar un 20% el compromiso de nuestra plantilla, nos encontraríamos con que no existe un indicador directo ni universal y probablemente tendríamos que diseñar uno a medida, basado en la combinación de varias métricas, como, por ejemplo, la ratio de asistencia a eventos corporativos, incremento de números de ideas en el buzón de sugerencias, número de recomendaciones internas, etc. 

A este tipo de indicadores indirectos se les conoce cómo indicadores proxy, ya que cuando no podemos medir directamente el estado de un sistema necesitamos basarnos en otras mediciones que están relacionadas con el sistema que queremos medir. Estos indicadores proxy tendrán una relación física con el indicador buscado que podrá ser calculado a partir de ellos, de la misma forma que se calcula el clima de hace millones de años utilizando métricas alternativas disponibles actualmente como los niveles de isótopos.  

En este artículo hablaremos de una métrica muy interesante cómo es el gasto en Cloud, que puede ser relevante para formar indicadores por la cantidad de información que encierra.  

El gasto en Cloud 

Las organizaciones nativas en la nube operan bajo esta premisa de mejora continua ya que tienen la ventaja de que el ‘sistema operativo’ sobre el que corren sus cargas de trabajo están diseñados para ser gestionados por código, lo que les otorga la agilidad necesaria para aplicar cambios. Sus aplicaciones se diseñan de forma nativa para aprovechar los recursos cloud, dónde se realiza un pago por uso que da la oportunidad de conocer mejor la inversión realizada. 

Antes de la nube, calcular el gasto en infraestructura era complicado porque había muchos gastos compartidos (desde servidores, hasta el gasto energético del edificio), coste laboral de mantenimiento, licencias, el hardware era una inversión que amortizar, y no existía una necesidad que lo justificara el esfuerzo de calcularlo de forma continuada. Así que la infraestructura se consideraba generalmente parte de un centro de coste común de IT. El esfuerzo de desglosar el coste por unidades de negocio, aplicaciones o incluso equipo, era poco fructífero. 

Sin embargo, cuando operamos en Cloud, este dato nos viene dado en la factura y podemos conocer lo que cuesta toda la infraestructura que soporta nuestras cargas de trabajo. Esto nos hace más conscientes de la inversión necesaria en recursos para desplegar un servicio o sistema. Pero lo más interesante es que este gasto puede desglosarse hasta el nivel que deseemos, por lo que podríamos conocer cuanto consume cada área, aplicación, departamento incluido equipo. Y es por eso que el gasto Cloud se convierte en una métrica muy nutritiva. Aunque, como cualquier métrica, no es sencilla ni directa de aplicar, y necesitará ser contextualizada y calibrada antes de ser utilizada. 

Todos los Hyperscalers proporcionan una estructura jerárquica de cuentas, proyectos o grupos de recursos que permiten separar el gasto. Cuando este nivel de agrupación no es suficiente se recurre al uso de etiquetas sobre el recurso que luego nos permitirá explotar la información sobre el gasto.  

El gasto detallado junto con el uso de los recursos nos permite calcular aspectos como, por ejemplo, lo que nos cuesta almacenar un dato (un cliente, un expediente), el gasto de un servicio API, o el buscador de la página principal. Datos que antes del cloud eran imposible de obtener. 

El gasto en Cloud es una métrica entendible por los equipos de ingeniería y les hace más conscientes del impacto que tienen sus decisiones técnicas sobre el balance total del producto en el que trabajan. 

Cuando hablamos de la métrica basada en el gasto cloud nos centramos en la parte directamente relacionada con el uso de infraestructura, IaaS, la cual podemos obtener separando el gasto por tipo de recurso, dejando fuera otros gastos como el soporte o los servicios PaaS para otro tipo de análisis. 

El coste cloud (Iaas) es una métrica proxy de la tecnología subyacente que nos permite medir de forma directa o indirecta otros factores relevantes como: 

• Rendimiento de los sistemas. El rendimiento es la relación entre el trabajo útil obtenido en un proceso frente a los recursos totales utilizados. En nuestro caso se traduce en un indicador que mide el grado de aprovechamiento de los recursos cloud. Por ejemplo, puede utilizarse para comparar dos tecnologías equivalentes, midiendo la diferencia de número de peticiones atendidas entre dos alternativas con los mismos recursos (mismo coste). 

• Retorno de inversión. La atomicidad con la que se construyen aplicaciones (gracias a los microservicios, serverless, etc.) permite separar bien las distintas partes que la componen, así que se podría medir el retorno de inversión a nivel de característica de producto, es decir, si el coste de infraestructura es compensado por el aumento del negocio que provoca una nueva característica. 

• Sostenibilidad. Uno de los motivos que están cogiendo mayor peso en la decisión de la migración al cloud es la sustitución de CPDs tradicionales por otros que pueden obtener mejor eficiencia. Los objetivos ligados a la sostenibilidad pueden añadir iniciativas orientadas a reducir el uso de recursos que se traduce en un menor coste por un doble factor: reducción de recursos por optimización y sustitución de recursos más eficientes que generalmente es ofrecido por las nubes a menor precio.  

• Rentabilidad. Factor similar al anterior. Permite aumentar el margen de un sistema (producto o servicio de la organización) a partir de la reducción del gasto en la nube por medio del uso (optimización en el uso, etc.). A diferencia de la sostenibilidad, este factor puede mejorarse aplicando reducciones en el coste del cloud por medio de descuentos por compromiso de uso, como la reserva de instancias o utilización de instancias puntuales. 

Sostenibilidad 

La sostenibilidad se ha convertido en uno de los ejes principales de las estrategias de las organizaciones, formando parte de sus hojas de ruta. Las actividades de una organización empiezan a tener en cuenta su impacto medioambiental, aunque todavía estamos lejos de poder tener métricas que incluyan la cadena de valor completa.  

En este sentido el gasto en Cloud puede verse también como un indicador que está ligado con la sostenibilidad, ya que los proveedores cloud se convierten en socios estratégicos en la cadena de suministro y su huella repercute en la huella de las organizaciones. A menor gasto, mejor utilización de los recursos y por tanto menor impacto medioambiental. 

El proveedor de Cloud se preocupa por aplicar y desarrollar la tecnología más eficiente y con mayor rendimiento para mejorar márgenes derivados de la reducción energética principalmente. La inversión que realizan estas marcas para mejorar sus infraestructuras es difícilmente alcanzable de forma individual por las organizaciones ya que no pueden aplicar economía de escalas, mutualización de recursos (acondicionamiento, mantenimiento de facilities, seguridad), rotación de hardware más frecuentemente, etc. La eficiencia de estos Data Center se mide con la métrica conocida como Power Usage Effectiveness (PUE), que mide la relación de energía consumida total frente a la necesaria para realizar el cómputo y se estima que está en un 1,1 en los casos más eficientes.  

Pero tal y como sucede con la seguridad en la nube, la sostenibilidad es una responsabilidad compartida entre el proveedor del cloud y sus clientes. Aquí es dónde los clientes tienen margen para mejorar su impacto, y dónde la métrica del gasto nos puede ayudar indirectamente a mejorar. 

Las organizaciones que operan en Cloud deben hacer un uso responsable y activar principalmente criterios de optimización: 

1. Realizar un correcto ajuste de los recursos a sus necesidades, aprovechando la elasticidad de la nube para escalar como respuesta a la demanda. Así no es necesario sobredimensionar la infraestructura y por tanto el gasto. 
2. Aprovecha la atomicidad con la que se construyen las aplicaciones para aplicar políticas de diseño y ciclos de vida personalizados para cada recurso. Por ejemplo, se pueden separar los datos y utilizar sistemas de almacenamiento diferentes en función de la criticidad de la información, o de sus atributos, de forma que pueden archivarse datos utilizados ocasionalmente. 
3. Aprovechar la maestría obtenida en la entrega de código (CD) para actualizar la infraestructura sin impactar al negocio. La infraestructura de los fabricantes se va renovando constantemente por versiones más eficiente. Mover las cargas de trabajo a la nueva infraestructura puede ser sencillo para las organizaciones que hayan conseguido un nivel de madurez de élite en su proceso de despliegue. 
4. Utilizar la infraestructura como código (IaC) para recrear y eliminar entornos cuando sean necesarios, liberándolos cuando no se utilicen 
5. Diseñar pensando en unas características de fiabilidad, resiliencia, seguridad y latencia realistas para cada tipo de carga de trabajo. Aumentar la fiabilidad, resiliencia o reducir la latencia tiene consecuencias en las arquitecturas de las aplicaciones que impacta en los recursos consumidos. No todas las cargas de trabajo tienen las mismas exigencias, por lo que debemos ajustarnos a cada caso 

El consumo en Cloud nos puede servir para estimar un impacto inicial y, por comparación, ver cómo las iniciativas de optimización pueden conseguir reducir (proporcionalmente al negocio) el consumo y, por ende, operar de forma más sostenible. 

FinOps 

Tener consciencia sobre cómo impactan las decisiones técnicas sobre el coste de los sistemas convierte a los equipos de producto en pequeños inversores que deben tener en cuenta el balance entre coste y beneficio. 

Para los ingenieros de los equipos la nueva métrica del coste cloud supone un reto al tener en cuenta la eficiencia a la hora de diseñar e implementar su software. Decisiones tomadas durante la implementación, cómo la deuda técnica, pueden ahora tener impacto no sólo en la mantenibilidad del software, sino también en el coste. Esto implica una actividad extra que aumenta la carga cognitiva de los ingenieros. 

La carga cognitiva es la cantidad de actividades mentales que los desarrolladores deben tener en cuenta al mismo tiempo para ejecutar una tarea. El modelo DevOps aumentó su carga cognitiva al hacerles conscientes de los aspectos de desarrollo, productivización e infraestructura. Ahora, añadir una nueva variable como es el coste en recursos puede suponer una nueva sobrecarga.  

Para reducir esta carga, las organizaciones están incorporando áreas de soporte bajo la disciplina FinOps, que ayudan a la organización a maximizar la inversión en cloud y alinear objetivos entre los distintos interesados (finanzas, ingeniería, ejecutivos y negocio). Con respecto a los equipos de ingeniería, los especialistas en FinOps ayudarán a incorporar la métrica con la menor fricción posible, de la misma forma que los equipos de plataforma ayudan a los equipos de producto a centrarse en el desarrollo.