Multi-Cloud

Strategia korzystania z usług wielu dostawców chmury jednocześnie. Zmniejsza uzależnienie od jednego dostawcy i zwiększa odporność na awarie.

Multi-cloud to strategia, w której świadomie korzystasz z usług kilku dostawców chmury naraz — na przykład AWS, Microsoft Azure i Google Cloud Platform jednocześnie. Zamiast trzymać całą infrastrukturę u jednego operatora, rozkładasz ją na wielu, żeby ograniczyć tzw. vendor lock-in (uzależnienie od jednego dostawcy) i zwiększyć odporność na awarie. Jak jednemu dostawcy wywali się region, Twoja aplikacja dalej działa u drugiego.

Po co to komu

Powody są zwykle trzy. Po pierwsze, negocjacje cenowe — kiedy nie jesteś przykuty do jednej platformy, masz realną kartę przetargową. Po drugie, cherry-picking usług: bierzesz bazy danych z jednej chmury, bo są tańsze, a usługi ML z drugiej, bo są lepsze. Po trzecie, wymogi prawne i ryzyko — niektóre dane musisz trzymać w konkretnym kraju, a rozproszenie ogranicza skutki pojedynczej awarii czy bankructwa dostawcy.

Uwaga na rozróżnienie: multi-cloud to wielu dostawców chmury publicznej, a hybrid cloud to łączenie chmury z własną serwerownią (on-premise). To dwa różne pojęcia, choć często mylone na rozmowach rekrutacyjnych.

Jak to wygląda w praktyce

Żeby nie pisać osobnego kodu dla każdej chmury, używa się narzędzi agnostycznych. Klasyk to Terraform (albo OpenTofu) — opisujesz infrastrukturę raz, a providery odpalasz dla różnych chmur:

  • terraform apply -target=module.aws_storage — wdrażasz bucket na AWS S3,
  • a w tym samym repo masz moduł dla azurerm stawiający odpowiednik na Azure.

Do uruchamiania aplikacji wszędzie tak samo króluje Kubernetes — kontener nie wie i nie obchodzi go, czy stoi na EKS (AWS) czy GKE (Google). To właśnie konteneryzacja czyni multi-cloud znośnym.

Na co uważać

Multi-cloud nie jest darmowy. Najczęstsze pułapki:

  1. Złożoność rośnie wykładniczo — każdy dostawca ma inne IAM, inne nazwy usług, inne pułapki. Zespół musi znać wszystkie.
  2. Koszty transferu (egress) — przesyłanie danych między chmurami potrafi zjeść oszczędności, które miałeś dzięki rozproszeniu.
  3. Mit „zero downtime za darmo” — sam fakt posiadania dwóch chmur nie daje failoveru. Musisz go zaprojektować, przetestować i utrzymywać, inaczej masz dwa razy więcej rzeczy, które mogą paść.

Dla małego projektu jedna chmura zwykle wystarczy — multi-cloud zaczyna mieć sens dopiero przy realnej skali albo twardych wymogach biznesowych.

Pojęcia powiązane: vendor lock-in, hybrid cloud, Infrastructure as Code (Terraform), Kubernetes, high availability, disaster recovery, cloud-agnostic, egress.