71. Multi-cloud a hybridní cloud strategie (kdy dávají smysl)

Úvod a kontext

Modul 11 představil AWS a stručně Azure/GCP jako jednotlivé
platformy. Seniorní architektonická otázka je jiná: má smysl
používat víc cloudů najednou, nebo kombinovat cloud s vlastní
infrastrukturou? Tahle lekce probírá multi-cloud a hybridní cloud
strategie věcně — včetně častého argumentu proti nim, protože
"protože to zní bezpečněji" není dostatečný důvod pro tak nákladné
rozhodnutí.

Teorie

Definice pojmů

• Multi-cloud — firma používá dva nebo víc veřejných cloudů
  (např. AWS a GCP) současně, ať už pro různé části systému, nebo
  redundantně pro stejnou část.
• Hybridní cloud — kombinace veřejného cloudu s vlastní
  (on-premise) infrastrukturou nebo privátním datacentrem, typicky
  propojenou vyhrazeným síťovým spojením.
• Multi-region (viz minulá lekce o DR) není totéž co multi-cloud
  — je to použití víc regionů v rámci jednoho poskytovatele a je
  výrazně jednodušší a levnější než skutečný multi-cloud.

Časté (a často mylné) důvody pro multi-cloud

• "Ochrana proti vendor lock-in." Validní obava, ale skutečná
  cena je vysoká: efektivní multi-cloud vyžaduje používat jen
  nejmenší společný jmenovatel služeb (typicky jen VM a základní
  síťování), protože pokročilé spravované služby (např. AWS
  DynamoDB, Google BigQuery) nemají přímé ekvivalenty u konkurence.
  Firma tím ztrácí právě ty spravované služby, které cloud dělají
  výhodným oproti vlastnímu datacentru.
• "Nejlepší služba od každého poskytovatele" (best-of-breed).
  Legitimní důvod — např. využít Google BigQuery pro analytiku a
  AWS pro zbytek infrastruktury. Funguje dobře, pokud jsou tyto
  části systému skutečně nezávislé (žádná těsná synchronní
  komunikace mezi cloudy s nízkou tolerancí k latenci).
• "Ochrana proti výpadku celého poskytovatele." Legitimní pro
  kritické systémy, ale nákladné — vyžaduje duplikovat nejen
  infrastrukturu, ale i provozní know-how (týmy musí znát obě
  platformy), a řešit synchronizaci dat mezi cloudy v reálném čase.
• Regulatorní požadavky. V některých odvětvích (finance,
  veřejná správa) zákon nebo interní politika vyžaduje, aby určitá
  data zůstala u konkrétního poskytovatele nebo v konkrétní zemi —
  to je často skutečný, nevyhnutelný důvod pro hybridní nebo
  multi-cloud řešení, ne volba z preference.

Skryté náklady multi-cloudu

• Duplicitní provozní znalosti. Tým musí ovládat IAM, síťování a
  monitoring pro každého poskytovatele zvlášť — AWS IAM role,
  Azure Active Directory role a GCP IAM se liší v detailech natolik,
  že "univerzální" znalost prakticky neexistuje.
• Datová gravitace a náklady na přenos. Přenos dat mezi cloudy
  (cross-cloud data transfer) bývá výrazně dražší než přenos v rámci
  jednoho poskytovatele, a synchronizace velkých datasetů mezi
  cloudy zavádí latenci a komplexitu.
• Zdvojená observabilita. Metriky, logy a alerting (modul 12)
  je potřeba sjednotit napříč platformami, protože nativní nástroje
  každého cloudu (CloudWatch, Azure Monitor, Google Cloud Monitoring)
  fungují jen pro danou platformu — obvykle to vyžaduje centrální
  řešení jako Prometheus/Grafana nebo komerční observabilita
  nezávislá na poskytovateli.

Hybridní cloud — typické scénáře

• Postupná migrace do cloudu. Firma s existujícím on-premise
  datacentrem migruje postupně, po aplikacích, a po přechodné
  období (měsíce až roky) běží obě prostředí současně, propojené
  VPN nebo vyhrazeným okruhem (AWS Direct Connect, Azure
  ExpressRoute).
• Citlivá data on-premise, výpočet v cloudu. Např. banka drží
  citlivá zákaznická data ve vlastním datacentru kvůli regulaci, ale
  škálovatelné výpočetní úlohy (např. dávkové zpracování) pouští do
  cloudu.
• Burst do cloudu (cloud bursting). Základní kapacita běží
  on-premise (levnější dlouhodobě), ale při špičkách (např.
  Vánoce pro e-shop) se dočasně přiškáluje kapacita v cloudu.

Praktické doporučení pro většinu firem

Pro naprostou většinu firem, které nemají explicitní regulatorní
důvod, je jeden cloud poskytovatel s dobře navrženou multi-region
architekturou (viz minulá lekce o DR) lepší poměr
komplexita/přínos než skutečný multi-cloud. Multi-cloud dává smysl
až ve chvíli, kdy firma má konkrétní, měřitelný důvod (regulace,
skutečně nezávislá best-of-breed služba, nebo dostatečně kritický
systém, kde cena duplicitní infrastruktury je zanedbatelná oproti
ceně výpadku celého poskytovatele) — ne jako preventivní opatření
"pro jistotu".

Praktický příklad

Terraform (modul 10) umí spravovat víc cloudových poskytovatelů
současně definováním více providerů v jednom projektu — praktická
ukázka pro scénář "primární infrastruktura v AWS, analytické
úložiště v GCP BigQuery" (legitimní best-of-breed případ):

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

provider "google" {
  project = "firma-analytika"
  region  = "europe-west3"
}

# Primární aplikační infrastruktura v AWS
resource "aws_instance" "app" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
}

# Analytické úložiště v GCP — nezávislá, dávková úloha
resource "google_bigquery_dataset" "analytics" {
  dataset_id = "prodejni_data"
  location   = "EU"
}

Tento vzor (jeden Terraform projekt, víc providerů) je technicky
snadný — skutečná komplexita multi-cloudu není v konfiguraci
infrastruktury, ale v provozu, bezpečnosti a sjednocení
pozorovatelnosti napříč platformami, jak popisuje teoretická část.

Shrnutí

Multi-cloud a hybridní cloud jsou legitimní strategie, ale s
výraznými skrytými náklady — duplicitní provozní znalosti, dražší
přenos dat mezi poskytovateli a zdvojenou observabilitu. Nejčastější
důvod "ochrana proti vendor lock-in" bývá dražší, než se zdá, protože
nutí firmu vzdát se pokročilých spravovaných služeb. Multi-cloud dává
skutečný smysl hlavně u regulatorních požadavků, jasně nezávislých
best-of-breed služeb nebo kriticky důležitých systémů — pro většinu
firem je lepší jeden poskytovatel s dobrou multi-region architekturou.
Terraform technicky umožňuje spravovat víc poskytovatelů v jednom
projektu, ale to neřeší provozní komplexitu, jen konfiguraci.

Kontrolní otázky

1. Proč bývá argument "multi-cloud jako ochrana proti vendor
   lock-in" v praxi dražší, než se na první pohled zdá?
2. Jaký je rozdíl mezi multi-region a multi-cloud architekturou a
   proč je multi-region obvykle jednodušší volba?
3. Uveďte jeden legitimní, konkrétní důvod pro hybridní cloud
   architekturu a vysvětlete, proč v tom případě dává smysl.
4. Mini cvičení: firma bez regulatorních omezení zvažuje přechod na
   multi-cloud "pro jistotu, kdyby AWS vypadl". Jaké otázky byste jí
   položili, než takové rozhodnutí schválíte?