Topologia wielobarwna

1) W przypadku uzasadnienia wielu chmur

• Niezawodność/dostępność: niezależne strefy awaryjne na poziomie dostawcy.
• Suwerenność/zgodność: przechowywanie/przetwarzanie przez jurysdykcję (miejsce zamieszkania danych).
• Zarządzanie ryzykiem: zmniejszenie lokalizacji sprzedawcy, dźwignie zakupu/ceny.
• Geografia/wydajność: bliżej użytkownika i źródeł danych.
• Usługi specjalne: dostęp do najlepszych „niszowych” możliwości różnych chmur.

• Znacząca złożoność SDLC/obserwowalność/operacje.
• Wzrost wartości wyjścia i opóźnienia między dostawcami.
• Różne modele IAM/sieci/limity/limity → większe ryzyko operacyjne.

2) Wzory topologiczne

3) Warstwa sieciowa i routing

3. 1 Globalne logowanie

GSLB/DNS routing: latency-/health--based; krótkie TTL do okien migracji.
Anycast + L7 proxy: pojedyncze IP, regionalne szlaki zdrowotne.
Polityka według jurysdykcji: ruch geo-blokujący/geosiatki.

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 Łączność między chmurami

kanały prywatne/peering, w miarę możliwości; inaczej - TLS + mTLS przez Internet.
Kontrola wyjścia: agregacja/kompresja, lokalne bufory/agregatory.
Sieci jako kod: Terraform/Plany, polityki CIDR, trasy i bramy wyjścia.

4) Dane i spójność

4. 1 Modele

Globalnie silna konsystencja jest rzadko realistyczna między chmurami (opóźnienia/sieci/koszty).
Wydarzenie pragmatyczne: dwukierunkowa CDC (zmiana wychwytywania danych) z rozwiązywaniem konfliktów.
CRDT/idempotencja: dla liczników/zestawów/dzienników - struktury komutacyjne.

4. 2 Wzory

Dual-write with outbox: transactional event recording → broker → replikacja do sąsiedniej chmury.
Read-local/Write-home: pisze do regionu „home ”/chmury, czyta - lokalnie (z wersjami i nieustannymi zasadami).
Ochrona split-brain: wykrywanie rozbieżności, „odszkodowanie” (saga), ręczne arbitraż dla monetarnych niezmienników.

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

4. 3 Przechowywanie obiektów

Asynchroniczna replikacja wiader, hashes/manifestów, dedup.
Zasady ILM (gorące/ciepłe/zimne) są niezależne od chmury.
Zasady suwerenności: „PII nie opuszcza UA/EOG” - są zatwierdzane jako kod.

5) Tożsamość, sekrety i klucze

Federacja tożsamości: pojedynczy IdP, krótkotrwałe żetony, zaufanie OIDC na rurociągach.
Sekrety: KMS/HSM każdej chmury + abstrakcja klasy skarbca; podwójny klucz do obrotów/przełączników.
PoLP/ABAC: prawa oparte na atrybutach (chmura, region, wg data_class).
Domeny krypto: różne klucze korzeniowe dla jurysdykcji → crypto-erasure by scope.

6) Środowisko wykonawcze: klastry i oczka

Wielokrotność (K8s): jedna gromada na chmurę/region; kontrola floty za pośrednictwem GitOps (ArgoCD/Fleet).
Сервиα-мЕZ: mTLS, retries, circuit-breakers, failover policies cross-cluster.

• Usługi statyczne → na miejscu.
• Interaktywne API → w każdej chmurze (Active/Active).
• Partia/ETL → „zielone” okna/tani region (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) Obserwowalność i SLO w wielu chmurach

Etykiety wieloleasingu: 'chmura', 'region', 'lokator', 'data _ domain'.
SLI/SLO per-cloud i globalnie: „globalnie dostępne, jeśli dostępna jest ≥ 1 chmura”.
Kolekcja telemetryczna: lokalnie + agregacja z kontrolą wyjścia.
Ślady: globalny identyfikator, propagacja kontekstowa, pobieranie próbek na podstawie ogona przez ogony.
Porównanie desek rozdzielczych: A vs B na punkt końcowy/p99/błąd-budżet oparzenia.

8) SDLC/IaC i „polityka jako kod”

Pojedynczy katalog mono IaC: moduły dostawcy/stosy, niezmienne (tagi, sieci, szyfrowanie).
GitOps: manifesty deklaracyjne, wykrywanie dryfów, środowiska promo.
Testy zgodności: kontrakty API/event, Kanary dla obu chmur.
Bramy uwolnienia: blok zagrożony naruszeniem SLO w jednej chmurze (prognoza stopy spalania), w przypadku braku meczów suwerenności.

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) Koszt i węgiel (FinOps/WP)

Mierniki jednostkowe: '$/req', '$/GB-egress', 'gCO α e/req'.
Koszty/emisja dwutlenku węgla dla partii nieistotnej: tanie/zielone zegarki/regiony.
Egress-cap: budżet na ruch międzychmurowy; pamięci podręcznej/agregacji/kompresji/TTL.
RI/SP/Committed Użycie w każdej chmurze + „elastyczna warstwa” na miejscu/preemptywne.

10) Testowanie nie powiodło się i ćwiczenia

Dni gry: „gasić chmurę A”, „spowolnić bazę danych”, „break through egress limits”.
Punkty kontrolne: RTO/RPO, czas konwergencji DNS, rolka funkcji flagi, zachowanie pamięci podręcznej.
Chaos dymu w uwolnieniach: degradacja zależności nie powinna prowadzić do kaskady retras.

11) Bezpieczeństwo, prywatność, zgodność

Zero-Trust: mTLS między usługami/chmurami, podpis artefaktowy, SBOM.
DPA/suwerenność: katalogi zbiorów danych, zasady lokalizacji, Legal Hold na górze ILM.
Sekrety i klucze: magazyn rotacyjny, playbooks compromise/kill-switch.
Haki internetowe i integracje zewnętrzne: podpis, anty-replay, regionalne punkty końcowe.

12) Szablony integracji danych/zdarzeń

12. 1 Dwukierunkowy most Kafka (pomysł):

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

12. 2 Stół i przekaźnik skrzynki zewnętrznej:

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

Następnie złącze odczytuje skrzynkę odbiorczą i publikuje to wydarzenie lokalnemu maklerowi + przekaźnikowi.

12. 3 Strategia konfliktu (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) Anty-wzory

"Przeciągnij wszystko tak, jak jest w dwóch chmurach. "Podwojenie trudności bez wygranej.
Synchroniczne transakcje w chmurze na gorącym torze.
Pojedynczy globalny klucz szyfrujący dla wszystkich chmur/regionów.
Kłody/szlaki z PII bez przebrania i bez zasad lokalizacji.
Brak zewnętrznych pomiarów (rzeczywista dostępność jest widoczna tylko na stronie statusu dostawcy).
Brak odtwarzaczy/wiertarek - DR nie działa w tej chwili X.
Kaskada retras podczas degradacji jednej chmury (bez ograniczników/cieniowania/wyłączników).
Nieoficjalne dla wyjścia są nieoczekiwane rachunki.

14) Lista kontrolna architekta

1. Wielochmurowe sterowniki (SLO/DR/suwerenność/koszt)?
2. Wybrany wzór (AA/AP/DR-Only/Poly-Service) i RTO/RPO?
3. Plan sieci: GSLB/Anycast, próbki zdrowia, egress-cap, kanały prywatne?
4. Dane: CDC/CRDT/dual-write, conflict resolution rules, outbox?
5. Suwerenność: mapa danych/regionów, politycy jako kod i ich bramy?
6. IAM/tajemnice: federacja, krótkotrwałe żetony, KMS według domeny?
7. Klastry/siatka: strategia awaryjna, limity/przerwy/terminy?
8. Obserwowalność: etykiety „chmura/region”, SLO per-chmura i globalnie, zewnętrzna syntetyka?
9. SDLC/IaC/GitOps: pojedynczy katalog, testy zgodności, bramy?
10. FinOps/Ops: mierniki jednostek, budżet wyjścia, „zielone” okna partii?
11. Wiertła: regularne dni gry, protokoły i powtórzenia?
12. Plan wyjścia: eksport danych/formaty/terminy, drugie źródło dla kluczowych usług?

15) Mini konfiguracje próbki

15. 1 Polityka routingu jurysdykcji (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 Próbka zdrowotna dla GSLB:

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

15. 3 Flaga awaryjna (pseudokoda):

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

Wnioski

Wielobłok to dyscyplina inżynieryjna, nie etykieta. Wymaga jasnych motywów, świadomego wyboru topologii, przemyślanej pracy z danymi, silnej automatyzacji i surowej polityki. Jeśli mierzysz ryzyko i koszty, zbudujesz sieci i dane „zgodnie z podręcznikiem”, pociąg fylovers i kierujesz się ku prostocie, platforma multi-cloud zapewni Ci stabilność, elastyczność i swobodę - bez niespodzianek w rachunkach i bez uszczerbku dla doświadczenia użytkowników.