FOCUS, y por qué comparar dos nubes es más difícil de lo que debería

Haz una pregunta simple en dos nubes: cuánto nos costó el cómputo el mes pasado. En una, la respuesta está en una columna que describe una familia de instancias con un tipo de uso que codifica región, tenencia y sistema operativo en una sola cadena. En otra, está repartida entre un nombre de servicio y una categoría de medidor, con el descuento aplicado como línea negativa aparte. En una tercera, el cargo aparece el día en que se reconcilió y no el día en que el recurso se ejecutó.

Nada de esto está mal. El esquema de cada proveedor refleja cómo vende ese proveedor. El coste es que cualquier organización con más de una nube gasta tiempo real de ingeniería escribiendo una capa de traducción, y la traducción nunca está del todo terminada porque los esquemas cambian.

FOCUS, la especificación abierta de coste y uso de la comunidad FinOps, es la respuesta del sector: un esquema común para los datos de facturación que los proveedores publican junto a sus exportaciones nativas.

Qué normaliza

El valor está en ponerse de acuerdo en las cosas aburridas, porque las cosas aburridas son donde está el trabajo de traducción.

Nombres y significados de columna. Un conjunto definido de columnas con semántica especificada, para que el coste facturado signifique lo mismo en todas partes y dejes de mantener una tabla de correspondencias.

Las columnas de coste que importan. La especificación separa el importe realmente facturado del importe antes de descuentos y de la vista amortizada de un compromiso. Esa distinción es la que más a menudo se equivoca cuando los equipos construyen sus propios informes, porque una reserva pagada por adelantado aparece como un cargo grande en un mes y nada después salvo que amortices, y comparar una vista amortizada de una nube contra una vista facturada de otra produce conclusiones sencillamente falsas.

El tiempo. Periodos de cargo definidos, para que un total mensual signifique un mes natural de uso y no un ciclo de facturación que empieza el día en que se creó la cuenta.

Identificación de recurso y servicio. Identificadores consistentes y una taxonomía de categorías de servicio, para que cómputo sea cómputo entre proveedores.

Etiquetas. Un sitio definido para tus propias etiquetas de atribución, que es lo que hace posible la atribución entre nubes.

Lo que no resuelve

Ten claros los límites, porque el marketing tiende a no tenerlos.

Normalizar pierde detalle específico del proveedor. Las columnas que hacen útil una exportación nativa para el análisis profundo de una nube no están todas en el esquema común. Conserva también la exportación nativa; la normalizada es para comparar, no para sustituir tu fuente principal.

No hace comparables los servicios. Un servicio gestionado de Kubernetes y una plataforma serverless de contenedores caen los dos en una categoría de cómputo, y eso no hace comparable el coste por unidad de trabajo. La especificación fija el esquema, no la semántica de lo que compraste.

La adopción varía. La cobertura difiere por proveedor y por servicio, y la propia especificación está versionada y sigue evolucionando. Comprueba la versión vigente que admite cada uno de tus proveedores y los huecos conocidos antes de diseñar sobre una columna.

No te da un almacén. Sigues teniendo que ingerir, guardar y consultar los datos, y en un entorno grande el volumen es sustancial.

Si merece la pena el trabajo

La prueba honesta es cuántas nubes operas de verdad y quién hace la pregunta.

Una nube. No merece la pena. La herramienta nativa es mejor para un solo proveedor y el esfuerzo es puro gasto. Revísalo si una adquisición cambia la respuesta.

Dos o más nubes, con alguien haciendo preguntas transversales. Merece la pena. La alternativa es una capa de traducción a medida que entiende una sola persona y que se rompe cuando un proveedor cambia un formato de exportación.

Un proveedor de herramienta de costes de por medio. Pregúntale si consume el formato normalizado. Cada vez más lo hacen, y reduce su tiempo de incorporación y tu atadura a su modelo.

Los beneficiarios más claros son las organizaciones con un entorno multinube genuino, que en nuestra experiencia suele ser resultado de una adquisición o de una decisión regulatoria deliberada más que de una estrategia. Si estás en esa situación, las preguntas de comparación son constantes, y responderlas desde un mapa en vez de desde cuatro consolas es el mismo instinto de nadie ha visto el entorno entero.

Construir el pipeline

La forma es la misma en todas partes y lleva unas semanas, no un trimestre.

Activa la exportación de cada proveedor hacia almacenamiento de objetos, idealmente en el formato normalizado donde esté soportado, y conserva también la nativa. Aterrízala en un motor de consulta, particionada por fecha y proveedor, porque un escaneo completo de un año de datos de facturación en un entorno grande es caro y lo vas a hacer sin querer, que es exactamente el fallo que describe el control de coste de BigQuery.

Construye un número pequeño de vistas derivadas en vez de dejar que todo el mundo consulte lo crudo: coste por equipo, por categoría de servicio, por entorno, y la vista amortizada de los compromisos. Publica esas y guarda la tabla cruda para investigaciones.

Y después reconcilia cada mes contra el total de la factura de cada proveedor. Este es el paso que los equipos se saltan y es lo que mantiene fiable el pipeline. Una discrepancia o es un error de tu pipeline o es un cargo que no conocías, y las dos cosas merece la pena encontrarlas.

El requisito previo que nadie puede saltarse

La especificación normaliza los datos del proveedor. No puede normalizar los tuyos.

Si tus claves de etiqueta difieren entre nubes, con una en mayúscula en una, en minúscula en otra y con otro nombre en la tercera, la atribución entre nubes falla en el último paso por bueno que sea el esquema. Acuerda un conjunto pequeño de claves de etiqueta de atribución y hazlo cumplir en el motor de política nativo de cada nube, que es el mismo primer paso de dónde se esconde la factura de AWS y de la factura de Azure.

Hazlo antes del pipeline. Un conjunto de datos normalizado con etiquetas inconsistentes es una forma más rápida de producir la misma pregunta sin respuesta.

Lo que se olvida

• Los créditos y las devoluciones tienen sus propias columnas. Ignorarlos hace que tu coste reportado sea mayor que la factura, y la gente deja de fiarse del informe.
• La divisa. Los entornos multidivisa necesitan un criterio de conversión declarado, o las comparaciones mes a mes se mueven por razones que no tienen nada que ver con el uso.
• Cargos de mercado y de terceros. El software comprado a través de un mercado de nube aparece en la factura y no es infraestructura. Categorízalo o tu número de cómputo está mal.
• Las exportaciones cuestan dinero. Las exportaciones de facturación a almacenamiento de objetos y las consultas sobre ellas son en sí una línea, y un escaneo completo diario sin particionar es una forma genuinamente tonta de gastar dinero en informar de costes.
• Retención. Guarda al menos trece meses para que sea posible comparar año contra año.

Qué hacer esta semana

Lleva la misma pregunta a tus dos nubes más grandes: cuánto gastamos en cómputo el mes pasado, amortizado. Cronometra cuánto tardas en responder en cada una y escribe las dos definiciones que tuviste que usar. Esa diferencia es el argumento para normalizar y, si la respuesta llevó diez minutos en las dos, no tienes este problema y deberías gastar el tiempo en otra cosa. Lo evaluamos en la fase de costes de un proyecto cloud.