To be or not to be a multi-cloud company?

Wprowadzenie

Są w życiu rzeczy, które warto, i są takie, które się opłaca. Nie zawsze to, co warto, się opłaca. Nie zawsze to, co się opłaca — warto.

Parafraza słów Władysława Bartoszewskiego nie jest przypadkowa. Decyzję, czy warto i czy opłaca się skorzystać z możliwości multi-cloud, rozważa dziś coraz więcej organizacji. Jakie konsekwencje wynikają z tej decyzji? W tym poradniku krok po kroku analizuję proces doboru odpowiedniej strategii chmurowej.

W internecie można znaleźć skrajne opinie: od zdecydowanych zwolenników multi-cloud, przez przeciwników, aż po typową odpowiedź konsultingową: „to zależy”. Punktem wyjścia powinny być zawsze potrzeby biznesowe, akceptowalny poziom ryzyka, dostępne kompetencje i długofalowy rachunek ekonomiczny.

1. Adopcja chmury publicznej w dużych przedsiębiorstwach

Chmura publiczna staje się standardem. Organizacje coraz rzadziej pytają „czy”, a coraz częściej „jak” wykorzystać jej potencjał. Dostawcy rozszerzają usługi, zespoły IT budują rozwiązania z gotowych komponentów, a integratorzy wspierają kolejne transformacje. Jednocześnie przedsiębiorstwa nadal zmagają się z długiem technologicznym oraz kulturą silosów.

Obecnie szczególną uwagę poświęca się innowacjom w obszarze danych i AI oraz FinOps, czyli świadomemu zarządzaniu kosztami chmury.

W sektorze finansowym wyraźnie widać trend multi-cloud. Wiele instytucji wykorzystuje dwóch dostawców chmury publicznej oraz lokalne centra danych lub chmury prywatne. Spotykamy połączenia Azure i Google Cloud, Azure i AWS, a także środowiska wykorzystujące trzy platformy. Wynika to z odmiennych strategii biznesowych, profilu ryzyka, wymagań regulacyjnych, budżetu R&D oraz podejścia do Disaster Recovery i Business Continuity.

Czy przedsiębiorstwo korzystające z Microsoft 365 oraz aplikacji sprzedażowych w AWS jest już organizacją multi-cloud? Czy dopiero zdolność do odtworzenia tej samej aplikacji u drugiego dostawcy w czasie określonym przez BCP daje prawo do takiej definicji?

Organizacja posiadająca landing zones w dwóch chmurach, przeszkolony personel, wspólną tożsamość, SSO, CI/CD, monitoring i standardy bezpieczeństwa niewątpliwie szybciej odtworzy usługę u alternatywnego dostawcy. Każda instytucja powinna jednak wypracować własną definicję, wynikającą z tego, co chce osiągnąć, jakie środki może zaangażować i przede wszystkim — po co to robi.

Dla mnie chmura publiczna jest narzędziem realizacji celów biznesowych, a multi-cloud oznacza równoczesne wykorzystywanie potencjału więcej niż jednej chmury publicznej.

2. Infrastruktura czołowych firm cloud computing

Analiza czołowych firm oferujących usługi SaaS pokazuje bardzo różne strategie. OpenAI, Stripe i ServiceTitan wykorzystują technologie Microsoft oraz AWS. Databricks korzysta z AWS, Google Cloud, Microsoft Azure i Oracle Cloud. Canva, Klaviyo, Grammarly i Miro zbudowały biznes przede wszystkim na AWS. Talkdesk wykorzystuje kilka regionów AWS oraz region Google Cloud do backupu baz danych, a Rubrik korzysta z Azure, AWS i GCP.

Nie istnieje jeden dominujący wzorzec. Firmy wybierają od jednego do czterech dostawców. Można postawić hipotezę, że im bardziej newralgiczny proces świadczony klientowi końcowemu, tym większa skłonność do dywersyfikacji. Nie jest to jednak reguła absolutna — architektura zależy także od modelu biznesowego, kosztów i akceptowalnego ryzyka.

3. Incydenty dostawców i odporność architektury

Udokumentowane awarie AWS, Microsoft Azure i Google Cloud pokazują, że nawet bardzo dojrzała infrastruktura nie eliminuje ryzyka. Możliwe są problemy z łącznością, opóźnienia, chwilowa niedostępność API, przestoje usług, a nawet awarie całych regionów lub komponentów o globalnym znaczeniu.

Decydując się na chmurę, należy uwzględnić te zagrożenia w BCP i DR. Potrzebne są replikacja, redundancja, odporność oraz właściwe wzorce aplikacyjne, takie jak Retry, Circuit Breaker i Health Endpoint Monitoring.

Każde dodatkowe zabezpieczenie zwiększa koszt rozwiązania. Dlatego parametry SLO, RTO oraz RPO trzeba ustalić realistycznie i powiązać z wartością procesu biznesowego. Wysoka dostępność na poziomie multi-cloud może zapewnić najwyższy poziom odporności, ale jednocześnie znacząco zwiększa złożoność infrastruktury.

Pozostaje zasada KISS: nie komplikuj bez potrzeby. Zanim powielimy całe środowisko u drugiego dostawcy, warto sprawdzić alternatywne koncepcje architektoniczne. Pomocne są również testy chaos engineering, pozwalające wykryć słabości wcześniej, zanim doprowadzą do kosztownego przestoju.

4. Zwrot z inwestycji multi-cloud

Nie warto „robić chmury dla chmury”. Trzeba kontrolować wartość, koszt i termin zwrotu z inwestycji, uwzględniając pełny kontekst projektu.

W uproszczonym modelu ROI należy uwzględnić:

• KI — koszt integracji infrastruktury dwóch chmur: tożsamość, monitoring, bezpieczeństwo i CI/CD;
• KO — koszt operacyjnej obsługi drugiej chmury;
• KD — koszt rozwoju i działania drugiego zespołu cloud;
• KA — koszt awarii i przestojów wynikających ze zwiększonej złożoności;
• ZO — oszczędności i dodatkowe przychody uzyskane dzięki drugiemu dostawcy;
• ZD — wartość dywersyfikacji ryzyka i unikniętych przestojów.

Przykład roczny: 200 000 zł korzyści dzięki drugiej chmurze, 20 000 zł unikniętych strat, 500 000 zł integracji, 10 000 zł kosztów operacyjnych, 200 000 zł kosztów zespołu i 20 000 zł strat wynikających ze złożoności. W pierwszym roku inwestycja może wykazywać głęboką stratę. W kolejnych latach, po odjęciu jednorazowego kosztu integracji, wynik znacząco się poprawia.

Każda organizacja musi znaleźć mierzalne i długoterminowe korzyści. Zachęta finansowa dostawcy kiedyś się kończy; jeśli nie istnieje trwały biznesowy powód korzystania z drugiej chmury, wynik pozostanie ujemny.

5. Kiedy jedna chmura to za mało?

Pierwszą grupą korzyści są partnerstwa technologiczne i biznesowe. Przykładem jest współpraca Microsoft Azure z Oracle Cloud Infrastructure czy partnerstwo Microsoftu z OpenAI. Połączenie usług dostępnych u różnych dostawców może zapewnić niższe opóźnienia, lepszą integrację i dostęp do unikalnych możliwości.

Drugą korzyścią jest podejście best-of-breed. Portfolio dostawców częściowo się pokrywa, ale nadal istnieją istotne różnice w funkcjach, zarządzaniu tożsamością, bezpieczeństwie, usługach danych, modelach AI i gotowych rozwiązaniach marketplace. Multi-cloud pozwala wybierać rozwiązania najlepiej odpowiadające potrzebom biznesu zamiast ograniczać się do oferty jednego producenta.

Trzecią korzyścią jest szybszy dostęp do technologii typu game changer: generatywnej AI, usług kwantowych, wyspecjalizowanych modeli, rozwiązań open source i nowych usług zarządzanych. Możliwość wyboru dowolnego dostawcy może skrócić czas uruchomienia projektu i stworzyć przewagę konkurencyjną.

Czwarty obszar to dywersyfikacja ryzyka, regulacje i pozycja negocjacyjna. Instytucje finansowe analizują krytyczność dostawców i ograniczają ryzyko monopolistycznego uzależnienia. Greenfield uruchomiony u drugiego dostawcy może ograniczyć vendor lock-in bez kosztownej migracji istniejących systemów.

Sama różnica cenowa rzadko uzasadnia zmianę platformy po poniesieniu wysokich kosztów budowy landing zone, procesów i kompetencji. Ceny usług mogą rosnąć, dlatego potrzebne są FinOps, monitoring wykorzystania, rezerwacje i negocjacje. Decyzję należy podejmować na podstawie całkowitego kosztu posiadania, a nie pojedynczej pozycji w cenniku.

6. Kultura i dojrzałość organizacji

Po strategii biznesowej najważniejsi są ludzie realizujący zadania operacyjne. IT jest partnerem biznesowym i katalizatorem zmian. Wykorzystanie potencjału chmury zależy od zdolności adaptacji, kompetencji i zaangażowania zespołu.

Portfolio usług chmurowych wzrosło z dziesiątek do setek pozycji. Nie sposób być ekspertem we wszystkich obszarach u wszystkich dostawców jednocześnie. Część specjalistów rozwija głęboką ekspertyzę u jednego dostawcy, inni koncentrują się na konkretnej domenie w wielu chmurach. Menedżerowie muszą dobrać właściwy model kompetencyjny, rekrutować, rozwijać i utrzymywać specjalistów oraz mierzyć się z niechęcią do reskillingu i upskillingu.

Więcej chmur oznacza szerszy wybór technologii i kandydatów, ale również większe wymagania organizacyjne. W Allianz Polska uruchomiłem program edukacyjny, w ramach którego przeszkolono ponad 400 inżynierów i menedżerów z AWS i Microsoft Azure.

Organizacje przechodzą w stronę BizDevOps, gdzie biznes i IT pracują bez tradycyjnych silosów. Agile, platformy chmurowe i automatyzacja pozwalają przesuwać uwagę z utrzymania środowisk na rozwój produktów i inicjatywy AI-driven. Bez właściwej kultury jedna chmura nie przyniesie zakładanych efektów, a druga tylko zwiększy chaos.

W obszarach z silnymi podziałami warto budować interdyscyplinarne, autonomiczne zespoły skupione na wspólnym celu, na przykład wdrożeniu produktu. Decyzje powinny zapadać w zespole, a zależności i bariery organizacyjne powinny być ograniczane.

Podsumowanie

Debata cloud kontra multi-cloud przypomina dawną rywalizację zwolenników Linuxa i Windowsa. Dziś wiele organizacji świadomie wykorzystuje kilka systemów i kilka platform, podczas gdy inne pozostają przy jednym zestawie technologii.

Nie istnieje rozwiązanie pasujące do wszystkich. Dobór strategii zależy od potrzeb organizacji, oczekiwanych rezultatów, dostępnych środków i odpowiedzi na pytanie „po co?”.

Analizę należy rozpocząć od ryzyka:

• Jak duże ryzyko polegania na jednym dostawcy jesteśmy gotowi zaakceptować?
• Na jakie maksymalne straty i przestoje możemy sobie pozwolić?
• Które procesy są krytyczne dla klientów?
• Jakie SLA zawarliśmy?
• Czy procedury DR i BCP są przetestowane?
• Jakie SLO, RTO i RPO rzeczywiście musimy zapewnić?

Jeżeli akceptujemy krótkotrwały przestój, a obecny dostawca zapewnia potrzebne partnerstwa i usługi, pozostańmy przy jednej chmurze. Jeśli któryś z tych warunków nie jest spełniony, policzmy ROI i uwzględnijmy koszty sieci, tożsamości, bezpieczeństwa, monitoringu, CI/CD, FinOps oraz rozwoju kompetencji.

Przy odpowiednio zaplanowanej architekturze hybrydowej dodatkowa chmura może stać się kolejnym dobrze dopasowanym elementem układanki. Bez planu będzie kosztownym i czasochłonnym projektem. Im więcej mierzalnych korzyści i strat uwzględnimy w perspektywie długofalowej, tym lepszą podejmiemy decyzję.

Multi-cloud może być szansą, ale organizacja musi być na nią przygotowana. Dokładanie kolejnego wyzwania przeciążonym zespołom bez właściwej kultury pracy nie przyniesie oczekiwanych korzyści — jedynie zwiększy złożoność.