Firmy coraz częściej zdają sobie sprawę, że uzależnienie od jednego dostawcy chmury może utrudnić im reakcję na kryzys, zmianę cen czy napięcia geopolityczne. Mimo to wiele organizacji przecenia swoją gotowość do przeniesienia kluczowych systemów do innej infrastruktury.
Wyjście z chmury może potrwać miesiące
Badanie Leaseweb, w którym wzięło udział 800 przedstawicieli kadry zarządzającej, pokazuje wyraźną rozbieżność między przekonaniami firm a ich rzeczywistymi możliwościami. Aż 89% respondentów przyznało, że nie zdołałoby przenieść krytycznych dla biznesu obciążeń do innego dostawcy w ciągu trzech tygodni. Ponad połowa ocenia, że taki proces potrwałby dłużej niż trzy miesiące albo byłby niemożliwy.
Jednocześnie 76% badanych uważa, że ma pełną lub dużą kontrolę nad przenoszeniem danych. Taka pewność może być złudna, bo migracja nie polega wyłącznie na skopiowaniu plików. Aplikacje bywają zaprojektowane specjalnie pod kątem usług i narzędzi konkretnego dostawcy, dlatego ich uruchomienie w innym środowisku może wymagać znacznych zmian.
Skala trudności różni się też w zależności od kraju. W badaniu najdłuższy średni czas migracji odnotowano w Holandii — wyniósł on 4,7 miesiąca.
AI może pogłębić zależność
Rozwój sztucznej inteligencji może jeszcze bardziej wiązać firmy z ograniczoną liczbą dostawców. Korzystanie z konkretnych modeli, platform i usług AI może sprawić, że przeniesienie całego środowiska stanie się trudniejsze, a organizacje będą miały mniej alternatyw.
79% ankietowanych liderów spodziewa się, że uzależnienie od dostawców pogłębi się właśnie za sprawą AI. W takiej sytuacji warto wcześniej sprawdzić, które elementy infrastruktury można przenieść, jakie dane i aplikacje są powiązane z konkretnymi usługami oraz ile czasu zajęłaby ewentualna zmiana.
Komentarz autora: Sama deklaracja kontroli nad danymi nie wystarczy, jeśli aplikacje są ściśle związane z usługami jednego dostawcy. Warto regularnie sprawdzać, jak wyglądałaby migracja najważniejszych systemów. Taki test może ujawnić problemy, zanim konieczna będzie szybka zmiana infrastruktury.
Więcej o ryzyku związanym z zależnością od scentralizowanej infrastruktury przeczytasz w artykule Kryzys AWS: Dlaczego kryptowaluty nie mogą polegać na scentralizowanej infrastrukturze.
Firmy szukają większej niezależności
Mimo problemów z migracją wiele organizacji już podejmuje działania, by ograniczyć zależność od jednego dostawcy. Zrobiło tak 78% badanych. Co ciekawe, najwyższy odsetek — 91% — odnotowano w Stanach Zjednoczonych, choć kwestie suwerenności cyfrowej często kojarzone są przede wszystkim z debatą w Unii Europejskiej.
Firmy są również gotowe zapłacić więcej za większą kontrolę nad swoją infrastrukturą. Średnio deklarują, że zaakceptowałyby wzrost kosztów o 16%, jeśli w zamian zyskałyby większą niezależność.
Plan awaryjny warto przygotować wcześniej
Uzależnienie od dostawcy nie zawsze oznacza, że firma nie kontroluje swoich danych. Problemem mogą być jednak aplikacje, integracje i usługi, które trudno odtworzyć w innym środowisku. Sama możliwość pobrania danych nie gwarantuje więc, że cały biznes da się szybko przenieść.
Dlatego organizacje powinny oceniać nie tylko bieżące koszty i wygodę korzystania z chmury, lecz także realny czas oraz nakłady potrzebne do zmiany dostawcy. Jak ostrzega Leaseweb, lepiej rozpoznać te zależności zawczasu niż dopiero wtedy, gdy wymusi to nagła podwyżka cen lub sytuacja geopolityczna.
Ktoś tu w końcu głośno mówi o tym, co wszyscy czujemy — managed services to wygoda, ale też łańcuch. Z technicznego punktu widzenia sens ma budowanie abstrakcji (Terraform/Ansible + CI), konteneryzacja i trzymanie stanu tam, gdzie można (DB w osobnych warstwach). Narzędzia typu Crossplane, Kubernetes Operators czy SPIFFE naprawdę ułatwiają portowanie aplikacji między chmurami — to nie bajka, to realne opcje, tylko trzeba zacząć wdrażać zanim pojawi się kryzys.
16% więcej za niezależność brzmi ładnie w prezentacji zarządu, ale realnie większość CIO wybierze tańsze i prostsze rozwiązanie dopóki nie będzie bolesnego zdarzenia. Badania menedżerów często przeceniają gotowość operacyjną — decyzje zapadają na podstawie SLAs i marketingu, nie na podstawie testowanej procedury RTO/RPO. No i pamiętajcie: część lock-inu jest świadoma — firmy płacą za outsourcing skomplikowanych kompetencji.
Rzeczywiście, artykuł dobrze to podsumowuje, ale warto doprecyzować kilka punktów. Migracja to nie tylko kopiowanie obiektów S3 — największy problem to stateful services: bazy danych (IOPS, consistency), identity (IAM/policies), i integracje z usługami PaaS (managed queues, serverless). Egress cost + sieciowe peeringi i latency też mogą zablokować ruch. Trzy tygodnie? Realistyczne tylko dla prostych stateless app + CDN. Jeśli planujecie migrację, policzcie też czas na testy przywracania (restore), synchronizację DB (replica lag), oraz zmianę CI/CD (secrets, runners). Lift-and-shift vs refactor — wybierzcie strategię i mierzcie RTO/RPO.
Mamy to za sobą — rok temu przenosilismy krytyczne uslugi z jednego cloud providera po podwyzce cen. Największy ból: function-as-a-service i event-driven flows, bo trzeba bylo przepisać triggery i zmienic modele auth. Egress zawsze gryzie po kieszeni, a dokumentacja do migracji jest luksusem, ktorego brak. Finalnie zajelo to ~2 miesiace calkowitych prac, ale bez nocnych korekt sie nie obeszlo. Teraz multi-cloud, ale kosztem wiekszej złożoności.
Ktoś ma doświadczenia z przenoszeniem modeli ML/LLM między dostawcami? Interesuje mnie głównie: ile trudności daje przeniesienie danych treningowych + embeddings (vector DB), i czy ktoś używał narzędzi do „model portability” — np. ONNX + własne inference jako fallback. Czy lepiej trzymać inference on-prem i tylko storage w chmurze, czy odwrotnie? Jakie są realne koszty egress przy dużych datasetach?
Wynik „78% podejmuje działania” pokazuje dobre intencje, ale praktyka wygląda inaczej. Firmy często mylą posiadanie procedur z ich przetestowaniem — disaster recovery na papierze nie znaczy, że można w 3 tygodnie przestawić produkcję. Dodatkowo regulacje i suwerenność cyfrowa zmuszają do trzymania pewnych danych lokalnie, co komplikuje story. A ostatecznie większość kosztów migracji to praca ludzi (refactor, testy), nie sam transfer danych — warto to uwzględnić w kalkulacji.