Architettura dei costi

1) Principi e ruoli

Cost as a Feature. Il prezzo è una parte del prodotto UX e delle soluzioni architettoniche.
Responsabilità congiunta. Ingegneri, piattaforma/DevEx, finanza, prodotto - un unico loop di feedback.
Un'unica fonte di verità. Directory tag/etichette, dizionario costi e origini dati.
« ». Dashboard integrati, gate automatici e policy.

Ruoli: architetto del valore, analista, proprietario del prodotto, Platform Team.

2) Modello di dati di costo

• Per API: '$/1000 query', '$/millisecondo CPU', '$/GB egress'.
• Per i dati: $/GB di memorizzazione, $/richiesta di database, $/milioni di messaggi.
• Per l'utente: «CAC», «ARPU/ARPPU», «Grosse Margin», «LTV: CAC».
• Per flusso: $/transazione, $/deposito, $/test.

cost_record {
ts, provider, account, region, service, usage_qty, usage_unit,
list_price, net_price, discounts,
tags: { env, team, product, feature, tenant, cost_center, pii, tier },
resource_id, allocation_keys: {req_id?, tenant_id?, dataset?}
}

Tag dorati (obbligatori): «env», «team», «product», «feature», «cost _ center», «owner», «pii», «tier (hot/warm/cold)», «region».

3) Attributo: showback/chargeback

Showback: report trasparenti per comando/file senza tariffare i trasferimenti interni.
Chargeback: distribuzione secondo le regole: costi diretti per il proprietario; risorse shared - RPS, secondi CPU, orologi GB, quantità di eventi.

cluster_cost = sum(provider_cost where resource in "k8s-node:")
weights = { service: cpu_seconds(service)/total_cpu_seconds }
for service in services:
charge[service] = direct_cost(service) + cluster_cost weights[service]

4) Policy as Code

Le regole di bilancio sono limiti di «eng/team/feature»; auto-alert/blocco di deploy in caso di superamento previsto.
Requisiti etichette: risorse senza tag obbligatori - deny nel controller admissione.
I limiti del profilo includono il divieto di macchine grandi in «dave», TTL in risorse ephemerali, ridondanza minima.

yaml policy: require-tags-and-limits deny_if_missing_tags: [team, product, env, cost_center, owner]
constraints:
env==dev:
max_instance_type: "c6i. large"
ttl_hours: 72

5) Calcoli: pattern di riduzione dei costi

La dimensione corretta (rightsizing) è una selezione automatica basata su p95/p99, stagionale e headroom.
Scalabilità automatica: target-based (CPU/RPS/lag), funzioni step; Protezione da thrash attraverso l'isteresi.
Selezione del modello price: on-demand vs spot/preemptible, Reserved Impianti/Savings Plans; una miscela per critici e fondi.
Trasportatori batch: finestre di carico a basso costo, compressione batch, code prioritarie.
Cache e coalizione di query: riduzione delle letture da fonti costose.
Edge/Ottimizzazione rete: HTTP/2/3, keep-alive, compressione, CDN.

if rps > target1. 2 for 3m: replicas += ceil(rps/target); cool_down 5m if rps < target0. 6 for 10m: replicas = max(min_replicas, replicas-1)

6) Conservazione e dati: caldo/caldo/freddo

Tiring: hot data (accesso immediato), caldo (richieste rare), freddo/archivio.
Formati: colinvertebrati (Parket/ORC) per analisi, compressione e partizionamento per data/chiave.
TTL/ILM: «hot 7d warm 90d cold 365d delete».
Livello cache: Redis/Memcached con ricest coalescing, protezione contro le tempeste miss.
Quote e budget delle richieste: limiti prevedibili per join/scan costosi.

yaml dataset: events_main lifecycle:
- phase: hot; duration: 7d; storage: nvme
- phase: warm; duration: 90d; storage: ssd; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d

7) Rete ed egress

Ridurre al minimo il traffico interregionale: copia locale e aggregazione sul bordo.
CDN e caschi: origin-shield, TTL ragionevoli, convalida/invalidità.
I protocolli sono binari (gRPC) per chattare, la compressione solo se è vantaggiosa.
Deadback degli eventi e filtraggio sul produttore, «Non portiamo la spazzatura».

8) Abbondanza e costo SRE

Mappe del costo della telemetria: '$/loga-GB', '$/metrica-serie', '$/pista'.
Sempilamento e aggregazione: tail-based sampling, downsampling metriche, retensh per importanza (le metriche SLO sono la priorità superiore).
Deadup dei reparti e loghi di igiene: proibizione del PD, riduzione dei campi fantasma, limiti per la dimensione dell'evento.

9) CI/CD e ambienti di prova

Stand Ephemeral con auto-TTL, ambienti «per PR».
Perf-smoke in PR - Test brevi per la valutazione precoce dei costi di richiesta.
Cache/manufatti: riutilizza contenitori, compilazioni.
GATES: il bild/deposito viene rifiutato se il «prezzo della latitanza »/RPS è peggiorato rispetto al basline> X%.

10) Previsioni, budget e anomalie

Forecasti: stagionalità/trend, eventi (campagne, release), correlazione «fici-costo».
Budget di livello: team/product/feature/tenant; escalation all '80/90/100%.
Anomalie: picchi improvvisi per servizio/regione/account; «Bisect» automatico e rientro del flag.

if forecast(month_end_cost) > budget0. 9 and variance ↑:
alert(team_owner)
suggest: rightsizing + RI/SP coverage + ILM tighten

11) Acquisti e commercio

RI/Savings Plans/Committed Use - Coprire una base stabile; Monitora la copertura e gli interessi «unutilized».
Spot/Preemptible: attività di sfondo e tolerant-workflow; checkpointing e riavvio rapido.
Licenze e SaaS: la matrice di RE, il benchmarking delle alternative, il periodico «vendor fitness review».

12) Multilateralità e billing

Partitioning by tennis: separazione logica/fisica, limiti e quote.
Tenant-aware limitatori/classificatori - prevengono il «vicino rumoroso».
Modelli Usage: bollo per eventi, RPS, quantità di dati metriche trasparenti per i clienti.

13) Sicurezza e compliance come fattore di costo

Kripto e memorizzazione: FPE/chiavi - spese per KMS/HSM; ottimizzare la frequenza delle operazioni.
Copie regolatorie: separare i ritenshi «legali» da quelli operativi; l'archivio costa meno dello stoccaggio caldo eterno.
Data minimization: meno dati - Meno fatture e rischi.

14) Ingegneria anti-pattern (costoso!)

API a chate senza batch o cache.
Code illimitate e parallelismo illimitato - aumento della latitanza e del conto.
TTL zero e chiavi calde senza coalizione.
Dashboard con milioni di metriche.
Le risorse senza tag → uno spreco grigio senza proprietario.
L'assenza di ILM/TTL fa crescere lo storage per sempre.

15) Strumenti e manufatti (vendor-neutral)

Directory tag (schema + linter in CI).
Estratto cost (aggregazione usage/billing, normalizzazione in un unico formato).
Dashboard unit economics (costo API, valore dataset, valore tenant).
Modifica automatica (rightsizer, raccomandatore RI/SP, enforder ILM).
Regole di costo (admissione/OPA/Kyverno) e linee rosse di bilancio.

16) Mini-ricette

Formula prezzo richiesta (HTTP)

request_cost = (cpu_ms $/cpu_ms) +
(mem_mb_s $/mb_s) +
(egress_mb $/mb) +
(db_calls $/call) +
(cache_ops $/op miss_penalty)

Controllo rapido del servizio

Top 3 endpoint costosi a $/1000 req.
Hit/miss cache e chiavi di tempesta.
Elenchi delle risorse senza tag.
L'ILM e i dataset.
Copertura RI/SP (%).

Polizze retry a costi contenuti

retry = min(3, floor(budget_ms / (base_timeout_ms 1. 5^attempt)))
jitter = uniform(0. 5..1. 5)

17) Assegno-foglio dell'architetto di valore

1. Definite le metriche unit ('$/req', '$/GB-mont',' $/txn ') e i proprietari?
2. Tag-policy enfanced? Le risorse senza tag vengono bloccate?
3. Showback/changeback e report prodotti/file sono stati implementati?
4. Scale automatico e rightsizing configurati, headroom definito?
5. I dati vengono applicati (hot/warm/cold), ILM/TTL?
6. Egress e flussi interregionali sono minimizzati? CDN/cache abilitati?
7. Abilità ottimizzata (sampling, retention, downsampling)?
8. CI/CD gate su regressione costi e policy-checks sono attivi?
9. Previsioni/budget/analisi anomalie automatizzate?
10. RI/SP/Spot-mix copre i carichi di lavoro di base?
11. Per multi-tenant ci sono quote, limitatori e usage-metriche trasparenti?
12. Documentato con il runbook e il piano della costa-review mensile?

Conclusione

L'architettura del costo non è «risparmio a tutti i costi», ma la gestione del valore: quanto costa ogni millisecondo e quanto guadagna. Integrando il costo nell'architettura, nei processi e negli strumenti (tag, policy, gate, dashboard, ILM, autoscale), si ottiene una piattaforma dove le decisioni vengono prese in base alle metriche e all'economia piuttosto che all'intuito. Questo accelera il prodotto, riduce i rischi e rende le imprese prevedibilmente redditizie.