Poniedziałkowy paraliż, który położył globalnych gigantów – od Zooma, przez Slacka, po Fortnite – był dla branży IT jak uderzenie obuchem. Jak to możliwe, że w czasach “zdecentralizowanej”, nieskończenie skalowalnej chmury, problem w jednym, fizycznym budynku w Wirginii (słynny region AWS US-EAST-1) jest w stanie wyłączyć pół internetu? Przecież uciekliśmy od naszych pękających w szwach serwerowni w piwnicy właśnie po to, by uniknąć takich scenariuszy.

A jednak, wróciliśmy do punktu wyjścia. Patrząc na czerwone dashboardy, przyszło nam zmierzyć się z brutalną prawdą: ta awaria nie jest argumentem przeciwko chmurze jako koncepcji. Jest bolesną lekcją ekonomii i weryfikacją kompromisów, na które branża godzi się każdego dnia, wybierając wygodę i niski koszt, myląc elastyczność z nieśmiertelnością.

Rzeczywistość centralizacji

Przez lata sprzedawano nam obietnicę chmury publicznej. Płacisz tylko za to, czego używasz. Skalujesz infrastrukturę w minuty, a nie miesiące. Nie martwisz się o zasilanie, chłodzenie ani wymianę dysków. To bezdyskusyjna rewolucja, która umożliwiła powstanie startupów takich jak Snapchat czy Canva.

Jednak ta rewolucja ma swoją cenę: uzależnienie. Dzisiejszy internet, wbrew idealistycznym wizjom, nie jest zdecentralizowaną utopią. To oligopol, w którym trzy firmy – Amazon Web Services, Microsoft Azure i Google Cloud – trzymają klucze do niemal całej cyfrowej gospodarki.

Awaria w regionie US-EAST-1 jest tego idealnym dowodem. To najstarszy, największy i często domyślny region AWS. Przez lata stał się technologicznym centrum grawitacji, hostującym kluczowe usługi, od których zależą inne, globalne funkcje Amazona. W ten sposób, nawet wewnątrz ekosystemu jednego dostawcy, stworzyliśmy pojedynczy punkt awarii (SPOF) dla usług, które same siebie uznają za “globalne”. Kiedy ten jeden klocek domina się przewrócił, pociągnął za sobą resztę.

Mit “wystarczającego backupu”

W tej chwili wielu menedżerów IT i dyrektorów finansowych, widząc skalę problemu, zapewne odetchnęło z ulgą: “przynajmniej mamy backupy”. To fundamentalne niezrozumienie problemu, które należy jasno sprostować.

Backup chroni przed utratą danych. Nie chroni przed awarią usługi.

Poniedziałkowy incydent, którego źródłem były błędy w API bazy danych DynamoDB, nie dotyczył (z dużym prawdopodobieństwem) utraty danych. Dane użytkowników Snapchata czy postępy w grze Duolingo były niemal na pewno bezpieczne, zreplikowane i zabezpieczone w centrach danych Amazona.

Problem polegał na tym, że nie działało API – “drzwi”, które pozwalają aplikacji się do tych danych dostać.

Posiadanie backupu w takiej sytuacji jest bezużyteczne. To tak, jakby mieć idealną kopię kluczyka do sejfu, który jest zamknięty w płonącym budynku, do którego nie ma dostępu. Możesz mieć setki kopii zapasowych, ale jeśli zawodzi cała platforma obliczeniowa, sieciowa i usługowa, twoje dane są po prostu niedostępne do czasu naprawienia awarii.

“Cyfrowy bliźniak” – święty graal niezawodności

Co więc jest prawdziwym zabezpieczeniem przed taką sytuacją? Odpowiedź jest jedna, choć niezwykle skomplikowana: architektoniczna redundancja na poziomie dostawców.

Świętym Graalem odporności jest architektura multi-cloud. Nie chodzi tu o używanie jednej usługi od Google, a drugiej od Amazona. Mówimy o posiadaniu pełnego “cyfrowego bliźniaka” (digital twin) całej naszej aplikacji u innego, konkurencyjnego dostawcy chmury.

Wyobraźmy sobie scenariusz idealny: nasza usługa działa jednocześnie na infrastrukturze AWS i równolegle na Microsoft Azure. Specjalne systemy (np. DNS) monitorują stan obu platform. W momencie, gdy region US-EAST-1 w AWS zaczyna zgłaszać błędy, cały ruch użytkowników jest w ciągu sekund automatycznie przekierowywany na bliźniaczą infrastrukturę w Azure. Użytkownik końcowy nie zauważa niczego, poza może chwilowym spowolnieniem.

\Brzmi idealnie. Dlaczego więc niemal nikt tego nie robi?

Brutalna ekonomia niezawodności

Odpowiedź jest banalna i brutalnie szczera: pieniądze. Wdrożenie prawdziwej architektury multi-cloud jest dla 99% firm na świecie, wliczając w to wielu giełdowych gigantów, po prostu nieopłacalne.

Nie mówimy tu o podwojeniu miesięcznego rachunku za chmurę. Mówimy o jego zwielokrotnieniu, a największe koszty są ukryte.

1.  Koszty technologiczne (złożoność): Nie da się prosto skopiować aplikacji z AWS na Azure. Każdy dostawca ma własne, unikalne usługi i odmienne API. Baza DynamoDB (AWS) to nie to samo co Cosmos DB (Azure) czy Spanner (Google). Utrzymanie logiki aplikacji, która potrafi płynnie działać na dwóch różnych fundamentach technologicznych, to gigantyczne wyzwanie inżynieryjne.

2.  Koszty operacyjne (ludzie): Taka architektura wymaga posiadania podwójnych, wysoce wyspecjalizowanych zespołów inżynierskich. Potrzebujesz ekspertów od AWS oraz ekspertów od Azure. W dobie deficytu talentów IT jest to luksus, na który stać tylko nielicznych.

3.  Koszty synchronizacji danych: To najtrudniejszy element. Jak zapewnić, że dane użytkownika (np. nowa transakcja bankowa lub zdobyty w grze przedmiot) są w tej samej milisekundzie spójne między bazami danych w Wirginii (AWS) i Teksasie (Azure)? Koszty transferu danych i złożoność logiki takiej replikacji są astronomiczne.

I tu dochodzimy do sedna. Biznes umie liczyć. Firmy takie jak Zoom, Duolingo czy Roblox świadomie dokonały kalkulacji ryzyka. Koszt i straty wizerunkowe związane z kilkoma godzinami przestoju raz na rok czy dwa lata są akceptowalnie niższe niż stały, gigantyczny koszt utrzymania prawdziwej redundancji multi-cloud.

Lekcja, którą musimy odrzucić

Awaria nie jest więc porażką inżynierów AWS ani dowodem na słabość chmury. To jest porażka naszych złudzeń na jej temat.

Chmura jest narzędziem. Można nim zbudować tanią, elastyczną infrastrukturę, która jest jednak fundamentalnie zależna od jednego dostawcy. Albo można nim zbudować ekstremalnie drogą, skomplikowaną i prawdziwie odporną na awarie twierdzę, działającą u wielu dostawców.

Wybranie obu tych opcji jednocześnie – tanio, prosto i w 100% niezawodnie – jest przywilejem, na który niemal nikogo nie stać.

aIncydent w Wirginii zmusił całą branżę do odpowiedzi na pytanie: Ile naprawdę jesteśmy w stanie zapłacić za 100% dostępności? Okazuje się, że znacznie mniej, niż lubimy o tym opowiadać na branżowych konferencjach.