FOCUS 1.3: meno caos, più controllo sui costi cloud ibridi

La verità scomoda è che la maggior parte del “caos” dei costi cloud non nasce da fatture fuori controllo, ma da dati incomparabili. Ogni provider parla una lingua leggermente diversa, le SaaS aggiungono il loro dialetto, on-prem e colocation completano la babele. La FinOps Foundation ha rilasciato FOCUS 1.3 (FinOps Open Cost and Usage Specification) con un obiettivo preciso: ridurre la frizione quotidiana rendendo i dati di spesa davvero confrontabili e azionabili in ambienti multi-cloud e ibridi.

Cosa porta di nuovo FOCUS 1.3 (e perché conta davvero)

FOCUS è nato nel 2023 per standardizzare costi e usage. Oggi è supportato da oltre una dozzina di provider, inclusi i big (AWS, Google, Microsoft, Oracle, Alibaba, Huawei, Tencent) e piattaforme come Databricks e Grafana. La 1.3 alza l’asticella su tre punti che, nella pratica, bloccano processi e automazioni:

1) Allocazioni trasparenti delle risorse condivise. Non più solo “costi allocati” opachi: i provider possono esporre il metodo utilizzato (resource-based, usage-based o ibrido) e come viene calcolata la ripartizione. Per chi gestisce cluster Kubernetes multi-tenant o database condivisi, questo cambia il gioco: puoi verificare se la logica di riparto del provider è coerente con il tuo modello interno di chargeback.

2) Commit contrattuali separati dall’uso. Reserved Instances, Savings Plans e commitment simili spesso sono “spezzettati” dentro le righe di usage, rendendo impossibile una semplice domanda tipo: “quali commitment sono attivi e quando scadono?”. La 1.3 introduce un dataset dedicato ai contratti, queryable e con controlli di accesso separati. Finance vede termini e stato dei commitment; operations lavora su usage e capacità senza accedere ai dettagli sensibili.

3) Freschezza e completezza dei dati come metadati standard. Quante chiusure di fine mese sono saltate perché due giorni dopo arriva un delta di costi non tracciato? Con campi timestamp e flag di completezza, le pipeline possono verificare lo stato prima di far partire workflow dipendenti. Meno correzioni manuali, meno notti insonni.

Dal cloud “puro” all’ibrido: una lingua comune anche per AI e SaaS

Il FinOps non è più solo “costi cloud”. La pratica è maturata: si sposta a sinistra (entra nelle scelte architetturali) e sale di livello (arriva in portafogli tecnologici gestiti da SVP/COO). La community della Foundation conta circa 100.000 practitioner e 96 su 100 Fortune partecipano ai programmi. In parallelo, FOCUS si estende a SaaS, data center e – punto cruciale per chi costruisce sistemi AI – infrastrutture GPU.

Un esempio concreto lato provider: AWS ha reso disponibili gli export FOCUS 1.2, aggiungendo colonne per riconciliazione fatture, tracking delle prenotazioni di capacità (incluse EC2 Capacity Blocks for ML) e supporto a valute virtuali/token usati da molte SaaS. La 1.2 introduce granularità oraria/giornaliera/mensile e semplifica l’integrazione con dataset SaaS. La 1.3 non sostituisce questo lavoro: lo completa, chiarendo le zone grigie di allocazione, contratti e qualità del dato in ambienti sempre più ibridi.

Tradotto per chi sviluppa AI e data platform: se alleni modelli con workload bursty, usi risorse prenotate in modo intermittente e componi stack con SaaS a consumo, FOCUS diventa il collante che ti permette di parlare la stessa lingua con Finance, senza fogli di calcolo ad hoc.

Come lo applicherei in un team prodotto/piattaforma

Ecco un approccio pragmatico che ho visto funzionare:

- Definire FOCUS come “contratto interno” per tutti i sistemi di chargeback e reporting, anche quando un provider non emette nativamente FOCUS. Normalizzare i dati nel lake/l'warehouse in uno schema FOCUS versionato.

- Abilitare un gate di completezza. Nessun job di riconciliazione, cost allocation “definitiva” o chiusura mensile parte se i metadati non indicano dati finalizzati per il periodo e il servizio interessati.

- Separare ruoli e accessi: dataset “Contract Commitments” per Finance; “Cost & Usage” per Platform/Engineering. Evita over-sharing e semplifica l’audit.

- Validare cost model vs allocazioni provider: dove l’allocazione nativa non rispecchia la realtà del workload (per esempio pod a bassa priorità che sporcano il conto di un team), applicare regole correttive in pipeline, documentate e riproducibili.

Uno schizzo SQL (nomi campi esemplificativi) per interrogare rapidamente i commitment attivi:

-- Esempio indicativo: schema ispirato a FOCUS 1.3
SELECT contract_id,
       description,
       start_date,
       end_date,
       committed_units,
       provider
FROM focus_contract_commitments
WHERE CURRENT_DATE BETWEEN start_date AND end_date;

E un controllo di completezza prima della riconciliazione mensile:

-- Pseudocodice: blocca la chiusura se i dati non sono finali
IF NOT EXISTS (
  SELECT 1
  FROM focus_metadata
  WHERE service = 'compute'
    AND period = '2025-11'
    AND data_complete = TRUE
    AND finalized_at <= TIMESTAMP '2025-12-03 00:00:00'
) THEN
  RAISE 'Dati incompleti: posticipare la chiusura';
END IF;

Trade-off pratici che conviene conoscere

- Adozione asincrona dei provider. La Foundation rilascia due volte l’anno, ma ogni vendor aggiorna quando può. Impostate da subito il versioning (1.2 vs 1.3) e gestite la coesistenza.

- 1.0 → 1.2 ha breaking changes. Se siete su 1.0, testate 1.2 in parallelo: alcune colonne cambiano cardinalità e nullability. Evita migrazioni “big bang”.

- Allocazioni: standard ≠ verità assoluta. L’esposizione del metodo è un enorme passo avanti, ma la scelta del metodo resta vostra. Serve un accordo multiparte (Finance, Platform, Team prodotto) su come ripartire i shared cost.

- Cultura e processi prima degli strumenti. La 1.3 aiuta a spostare il FinOps “a sinistra”: decidete l’impatto economico già in fase di design (es. tenancy, prenotazioni, piani SaaS), non solo a posteriori.

Il punto di caduta

FOCUS sta diventando la lingua franca della spesa tecnologica in contesti ibridi. Anche senza supporto nativo, usarlo come schema interno porta benefici immediati: riconciliazioni più veloci, meno attrito tra Finance e Engineering, e decisioni più informate su AI, data e workload distribuiti. La 1.3 non è una “feature in più”: è l’anello mancante tra governance e operatività, perché rende esplicite le regole del gioco (allocazioni), separa ciò che va tenuto separato (contratti), e dice chiaramente quando i dati sono pronti per contare davvero.