Topologia multi-cloud

1) Quando la nuvola multi è giustificata

• Affidabilità/disponibilità: zone di guasto indipendenti a livello di provider.
• Sovranità/compilazione: conservazione/elaborazione per giurisdizione (data residency).
• Gestione dei rischi: riduzione della vendemmia, leva acquisti/prezzi.
• Geografia/performance: più vicino all'utente e alle origini dati.
• Servizi speciali: accesso alle migliori funzionalità di nicchia delle nuvole diverse.

• Notevole complessità SDLC/osservabilità/operazioni.
• Aumento del costo egress e latitanza tra i provider.
• I diversi modelli IAM/rete/quote/limiti possono aumentare i rischi operativi.

2) Pattern topologici

3) Livello di rete e routing

3. 1 Accesso globale

Ruling GSLB/DNS: latency-/health-based; TTL brevi nelle finestre delle migrazioni.
Anycast + proxy L7: unico IP, routing per la salute delle regioni.
Criteri giurisdizionali: geo-blocking/geo-pinning del traffico.

python def pick_cluster(client, intent):
вход: ip, geo, tenant, feature allowed = filter_by_compliance(client. geo) # sovereignty healthy = [c for c in allowed if sdo (c). ok and slo(c). ok]
return argmin(healthy, key=lambda c: latency_estimate(client, c))

3. 2 Connettività trasversale

Canali privati/peering dove possibile; Altrimenti, TLS+mTLS via internet.
Egress Control: aggregazione/compressione, cache/aggregatori locali.
Reti come codice: Terraform/Blueprint, criteri CIDR, percorsi e passaruota egress.

4) Dati e consistenza

4. 1 Modelli

La consistenza globale forte è raramente realistica (latitanza/griglia/costo).
Pragmatic eventual - CDC bidirezionale (change data capture) con risoluzione dei conflitti.
CRDT/idipotenza: per contatori/set/logi sono le strutture di commutazione.

4. 2 Pattern

Dual-write con outbox - Registrazione transazionale evento → broker → Replica in un cloud adiacente.
Read-locale/Write-home: scrittura nella regione/cloud domestico, lettura locale (con versioni e regole stale).
La protezione split-brain è un oggetto di divergenza, «compensazione» (saga), arbitraggio manuale per gli invarianti di denaro.

DB → Debezium/stream → Events(topic@vN) → Cross-cloud relay → Apply w/ resolver resolver: prefer_higher_version          prefer_home          business_rule()

4. 3 Storage degli oggetti

Replica asincrona di serbatoi, hash/manifesti, deadup.
I criteri ILM (hot/warm/cold) sono indipendenti dalle nuvole.
Regole di sovranità: «Il PII non lascia la UA/EEA» - valuta come codice.

5) Identità, segreti e chiavi

La Federazione dell'Identità è un unico IdP, token a breve vita, OIDC-trust su pipline.
Segreti: KMS/HSM di ogni nuvola + astrazione di classe Vault; dual-key per rotazioni/commutazioni.
PoLP/ABAC - Diritti basati su attributi (cloud, region, eng, data _ class).
Crypto domini: diverse chiavi radici per le giurisdizioni crypto-erasure per area.

6) Ambiente esecutivo: cluster e interferenze

Multiclaster (K8s): un cluster per cloud/regione; controllo fleet tramite GitOps (ArgoCD/Fleet).
Сервис-меш: mTLS, retries, circuit-breakers, failover policies cross-cluster.

• Servizi statici in posizione dati.
• API interattive in ogni cloud (Active/Active).
• Batch/ETL → finestre verdi/regione economica (carbon/cost aware).

rego package placement

allow[cloud] {
input. service. pii == false cloud:= input. clouds[_]
cloud. features. contains("cheap_gpu")
}

deny["PII outside allowed region"] {
input. service. pii == true not input. target_region in {"eu-central","eu-north","eu-west"}
}

7) Osservabilità e SLO nel multi-cloud

Etichette multiarendiche: «cloud», «region», «tenant», «data _ domain».
SLI/SLO per-cloud e globale: «Disponibile globalmente se le nuvole sono disponibili».
Raccolta di telemetria: aggregazione locale + con controllo egress.
Trace: trace-id globali, esplorazione del contesto, sempilamento tail-based in coda.
Dashboard di confronto: A vs B per endpoint/p99/errore-budget burn.

8) SDLC/IaC e «regole come codice»

Unico mono-catalogo di IaC: provider-moduli/stack, invarianti (tag, reti, crittografia).
GitOps: manifesti dichiarativi, oggetto draft, promo degli ambienti.
Test di conformazione: appalti API/eventi, Canadies per entrambe le nuvole.
Release-gate: un blocco in caso di rischio di violare il SLO in una singola nuvola (previsione burn rate), in assenza di corrispondenza di sovranità.

yaml gate: multi-cloud-slo-and-compliance checks:
- slo_burn_rate(global) < 1. 0
- slo_burn_rate(cloud:A) < 2. 0
- compliance_rule("pii_in_region") == pass
- egress_forecast < budget on_fail: block_release

9) Costo e carbonio (FinOps/GreenOps)

«$/req», «$/GB-egress», «$/req».
Routing a costo/carbonio per batch non critico: orologi/regioni a basso costo/verde.
Egress-cap: budget per il traffico tra le lame; cache/aggregazione/compressione/TTL.
RI/SP/Committed Use in ogni nuvola + «strato elastico» su spot/preemptile.

10) Test di feed e esercitazioni

Game-days: «spegnere la nuvola A», «rallentare il database», «sfondare i limiti egress».
Assegno-punti: RTO/RPO, tempo di convergenza DNS, flagellazione flag, comportamento della cache.
Chaos-smook nei comunicati: la degradazione delle dipendenze non deve portare a una cascata di retrai.

11) Sicurezza, privacy, compilazione

Zero-Trust: mTLS tra servizi/nuvole, firma manufatti, SBOM.
DPA/sovranità: directory dei dataset, regole di localizzazione, Legale Hold sopra ILM.
Segreti e chiavi: cronologia delle rotazioni, playbook compromise/kill-switch.
Webhook e integrazioni esterne: firma, anti-replay, endpoint regionali.

12) Modelli di integrazione dati/eventi

12. 1 Ponte bidirezionale Kafka (idea):

cloudA. topicX ⇄ relayA→B ⇄ cloudB. topicX cleanup. policy=compact,delete  key-based routing  idempotent producer

12. 2 Tabella Outbox e ripetizione:

sql
-- outbox id uuid pk, aggregate_id, type, payload jsonb, version int, created_at timestamptz
-- transactional insertion with domain table change

A seguire, il connettore legge outbox e pubblica l'evento nel broker locale + reimpostazione.

12. 3 Strategia dei conflitti (pseudo):

python def resolve(local, remote):
if local. version > remote. version: return local if remote. version > local. version: return remote equal versions: domain rules return business_tiebreak (local, remote)

13) Anti-pattern

«Trasciniamo tutto in due nuvole». La complessità raddoppiata senza vincere.
Transazioni sincronizzate a due lati a caldo.
Un'unica chiave di crittografia globale per tutte le nuvole/regioni.
Loghi/roulotte con PII senza maschera e senza regole di localizzazione.
Nessuna misurazione esterna (la disponibilità reale è visibile solo dalla pagina di stato del provider).
Nessun playbooks/esercitazione - DR non funzionante al momento X.
Cascata di retrai quando una sola nuvola è degradata (nessun limitatore/shading/breaker).
L'egress non registrato è un conto a sorpresa.

14) Assegno-foglio architetto

1. I driver multi-cloud (SLO/DR/sovranità/costo) sono stati formulati?
2. È stato selezionato un pattern (AA/AP/DR-Only/Poly-Service) e registrato RTO/RPO?
3. Piano di rete: GSLB/Anycast, provini di salute, egress-cap, canali privati?
4. Dati: CDC/CRDT/dual-write, regole di risoluzione dei conflitti, outbox?
5. Sovranità: mappa dei dati/regioni, politica come codice e loro gate?
6. IAM/segreti - Federazione, token a breve vita, KMS per domini?
7. Cluster/mesh: strategia failover, limiti/break/timeout?
8. Osservabilità: etichette «cloud/region», SLO per-nuvola e globale, sintetico esterno?
9. Un catalogo unico, un test di conformità, un rilascio-gate?
10. FinOps/GreenOps: metriche unit, budget egress, finestre «green» batch?
11. Esercitazioni: game-days regolari, protocolli e retesti?
12. Exit Plan: esportazione di dati/formati/scadenze, secondo-source per i servizi chiave?

15) Mini esempi di configurazione

15. 1 Criterio di routing giurisdizionale (pseudo-YAML):

yaml route:
pii:
allowed_regions: ["eu-central","eu-north","eu-west"]
deny_cross_cloud: false analytics:
allowed_regions: ["eu-","us-"]
prefer_low_carbon: true weights:
eu-central@cloudA: 60 eu-central@cloudB: 40

15. 2 Prova di salute per GSLB:

http
GET /healthz
200 OK x-region: eu-central x-slo: ok    at-risk    breach

15. 3 flag failover (pseudocode):

python if slo_at_risk("cloudA", "payments"):
route. weight["cloudA"] -= 20 route. weight["cloudB"] += 20 enable_stale_rates(ttl=1560)

Conclusione

Il multi-cloud è una disciplina ingegneristica, non un'etichetta. Richiede motivazioni chiare, una scelta consapevole della topologia, un lavoro elaborato con i dati, una forte automazione e politiche rigorose. Se misurate i rischi e i costi, costruite reti e dati «manuali», allenate i feeling e tenete il passo libero, la piattaforma multi-cloud vi darà sostenibilità, flessibilità e libertà - senza sorprese nei conti e senza compromessi sull'esperienza utente.