El coste se decide en el pull request, no en la revisión de la factura

La revisión mensual de costes es una autopsia con hoja de cálculo. Alguien ve que la factura subió un 18 por ciento, pasa dos días averiguando qué cambio lo hizo y encuentra una fusión de hace cinco semanas que cambió una instancia mediana por una ocho veces mayor porque una prueba de carga fue lenta una tarde. Nadie objetó entonces, porque entonces nadie lo sabía.

La decisión que importaba ocurrió en un pull request, delante de un revisor que tenía toda la capacidad de preguntar "¿esto necesita ser tan grande?" y ninguna información que le sugiriera hacerlo. Ese es el hueco que llena Infracost: lee el plan de Terraform, pone precio a los recursos contra las tarifas públicas del proveedor y publica la diferencia mensual como comentario en el pull request, antes de la fusión.

Es una herramienta pequeña con un efecto de comportamiento grande, y casi todo el trabajo de adoptarla no es técnico.

De dónde salen los números

Infracost se ejecuta sobre la salida de terraform plan, normalmente el JSON de terraform show -json. Recorre los recursos planificados, los empareja con un catálogo de precios construido a partir de las tarifas públicas de los proveedores y produce una cifra mensual por recurso más una diferencia total contra el estado actual. Obtienes una tabla: este cambio añade estos recursos, quita aquellos y mueve el total mensual en esta cantidad.

También puede aplicar tarifas negociadas si le das ficheros de uso o un descuento empresarial, cosa que importa en cuanto tu tarifa efectiva se separa del precio de catálogo. La salida es una diferencia, no una previsión. Esa distinción es la clave, y el origen de todas las discusiones que vas a tener al respecto.

Lo que no puede ver

Es preciso en todo lo que tiene un precio fijo asociado a un recurso que existe: tamaños de instancia, clases de instancia de base de datos, operaciones de entrada y salida aprovisionadas, balanceadores, pasarelas NAT, disco asignado, cuotas fijas de clúster. Si el cambio es "esta máquina virtual se hace más grande", el número va a estar cerca.

No puede ver el uso. Peticiones e invocaciones, así que una función o una pasarela de API aparecen a cero. La transferencia de datos, que es con diferencia el hueco mayor, porque un cambio que añade un salto entre zonas puede costar más que el propio recurso y aparece como nada. El crecimiento del almacenamiento, porque pone precio al cubo por el tamaño que declaras y no por el que acaba teniendo. Y todo lo que esté fuera de Terraform: recursos creados por la aplicación, por un controlador de Kubernetes o pinchados en una consola.

Un fichero de uso que declare las peticiones mensuales supuestas, los gigabytes transferidos y los volúmenes de almacenamiento cierra parte de esto. Hazlo para el puñado de recursos donde el uso domina y sáltatelo en el resto.

Sé explícito con tus equipos sobre esa frontera. Una estimación que se equivoca con aplomo sobre la salida de datos hace más daño a la confianza que no tener estimación. El encuadre que aguanta es este: este número cubre el coste fijo de la forma que estás aprovisionando, y la parte que depende del uso sigue necesitando que alguien piense, igual que leer el plan de Terraform antes de aplicar te dice qué va a cambiar pero no qué va a hacer bajo carga.

El comentario es un cambio cultural, no un paso de CI

Conectarlo lleva una hora. Que sirva para algo lleva más.

El mecanismo es simple: el pull request pasa a llevar una consecuencia visible y cuantificada, pegada a la persona que todavía puede cambiar de opinión gratis. Un revisor que ve "más mil ochocientos al mes" junto a un cambio de clase de instancia hace una pregunta que de otro modo no habría hecho nunca. A veces la respuesta es "sí, lo necesitamos", y es un desenlace perfectamente bueno. El valor está en que la conversación ocurrió cuando cambiar la decisión no costaba nada.

Para eso, el plan tiene que ser reproducible, lo que significa que la integración continua planifica contra el estado real con un backend real. Si tus planes salen de portátiles, arregla eso primero; los patrones de estado y pipelines de Terraform en AWS son un requisito previo, no un extra opcional.

Umbrales que bloquean sin convertirse en un sello de goma

El paso siguiente obvio es romper la compilación por encima de un umbral, y aquí es donde los equipos se pasan. Un bloqueo duro ante cualquier subida se convierte en un sello de goma en dos sprints.

Lo que funciona es por tramos. Por debajo de un umbral absoluto pequeño, solo comentario y ninguna puerta. Por encima de una subida mensual apreciable, o por encima de un porcentaje del total actual de esa pila, exige aprobación explícita de un revisor con nombre. Para una subida muy grande, exige que la descripción declare el beneficio esperado y una fecha de revisión.

Elige el umbral absoluto en relación con el gasto actual de esa pila, no con una cifra para toda la empresa. Trescientos euros de subida son ruido en una cuenta de plataforma y una pregunta seria en una herramienta interna. Infracost admite comprobaciones de política basadas en la estimación, y puedes implementar la regla tú mismo sobre el JSON igual de bien. La lógica importa más que la herramienta.

Mantener el comentario legible

Todo comentario automático en un pull request acaba ignorándose. Los modos de fallo son predecibles:

• Publica un comentario y actualízalo en el sitio. Un comentario nuevo en cada empuje produce un hilo por el que nadie baja.
• Muestra la diferencia, no el inventario. Nadie lee sesenta filas de recursos que no cambian.
• Silencia los comentarios con diferencia cero. La mayoría de los pull requests no cambian el coste. Si el bot habla en todos, es ruido en todos.
• Pon el porcentaje junto al absoluto. "Más cuatrocientos" no significa nada sin saber si la pila cuesta ochocientos u ochenta mil.
• Hazte cargo de los falsos positivos. Cuando alguien diga que el número está mal, compruébalo y o arreglas el fichero de uso o documentas el hueco. Dos números equivocados sin explicación y el equipo deja de leer.

Lo que se olvida

• Los módulos multiplican. Un cambio en un módulo compartido aterriza en todos sus consumidores. La estimación en el pull request del propio módulo puede ser minúscula mientras el efecto sobre la flota no lo es.
• Los borrados también son una diferencia. Los números negativos son los que merece la pena celebrar, y la prueba de que una limpieza funcionó de verdad.
• Los descuentos distorsionan el orden. Con reservas aplicadas, el precio de catálogo puede ordenar dos opciones al revés. Mete las tarifas efectivas cuando la decisión esté ajustada.
• La no producción cuenta. Un entorno de preproducción dimensionado como producción es una línea recurrente real, en exactamente el mismo comentario.
• Estimación mensual, compromiso de años. Una clase de instancia de base de datos es una decisión con coste de salida, no un alquiler mensual.

El coste deja de ser un informe que alguien produce y pasa a ser una propiedad del cambio, visible en el momento en que se hace el cambio. Lo conectamos al pipeline de entrega durante la fase de costes de un proyecto cloud, normalmente en la misma semana en que arreglamos el backend de estado.

Qué hacer esta semana

Ejecuta Infracost en local contra el plan de tu pila más grande, sin integración continua de por medio. Mira el total y después los tres recursos más caros que contiene. Si alguno te sorprende, acabas de demostrar el argumento a favor del comentario en el pull request sin tener que defenderlo.