Cloud Exit: kiedy własne serwery wygrywają z chmurą publiczną

W tym use case szczególnie ważne jest rozróżnienie między danymi gorącymi i zimnymi. Dane gorące, potrzebne do bieżącej obsługi transakcji, często lepiej zostawić blisko aplikacji. Dane zimne, archiwalne lub wsadowe, można przenieść do tańszego środowiska bez dużego wpływu na użytkownika. To proste rozróżnienie, ale właśnie ono często decyduje, czy projekt ma sens.

Drugi haczyk to backup. Firmy zakładają, że skoro przeniosą dane na własną macierz, to koszt kopii bezpieczeństwa też spadnie. Niekoniecznie. Jeśli wymagane są kopie nieusuwalne, retencja wielomiesięczna, testy odtworzeniowe i drugi ośrodek, oszczędność trzeba liczyć po całym łańcuchu, nie po samym storage produkcyjnym.

Use case 3: płacisz za usługi zarządzane, ale używasz ich bardzo podstawowo

To częsty przypadek po dwóch lub trzech latach od startu platformy. Firma ma zarządzaną bazę, cache, kolejki i kilka usług sieciowych, bo na początku liczyło się tempo. Potem okazuje się, że aplikacja używa tych usług dość zwyczajnie: bez zaawansowanej replikacji, bez trudnego skalowania, bez funkcji premium, które uzasadniają cenę.

Wtedy trzeba porównać koszt abonamentu z kosztem utrzymania tych samych komponentów poza chmurą. Linia po linii: backup, patchowanie, monitoring, testy odtworzeniowe, dyżury i odpowiedzialność za incydenty. NIST od lat przypomina o podziale odpowiedzialności w modelach chmurowych. Po wyjściu z chmury firma przejmuje obowiązki, które wcześniej były ukryte w usłudze.

To miejsce, w którym wiele zespołów popełnia błąd zakupowy. Rezygnują z usług zarządzanych, bo patrzą na cennik, a nie na własną dojrzałość operacyjną. Jeśli nie ma automatyzacji, monitoringu, procedur DR i ludzi, którzy naprawdę to utrzymają, on-prem nie będzie tańszy. Będzie tylko bardziej ryzykowny.

Z drugiej strony, jeśli aplikacja stoi głównie na standardowych komponentach, a zespół ma porządek operacyjny, migracja z chmury do on-premise może być rozsądna. Nie dla idei. Dla przewidywalnego kosztu i większej kontroli.

Najlepiej widać to na bazach danych używanych jak zwykły silnik SQL bez egzotycznych funkcji. Jeżeli zespół i tak ma kompetencje DBA, zna procedury odtworzeniowe i potrafi zautomatyzować patchowanie, różnica między usługą zarządzaną a własnym klastrem może być głównie finansowa. Jeżeli tych kompetencji nie ma, oszczędność z cennika jest iluzją.

Podobnie z kolejkami i cache. Jeśli są krytyczne dla ścieżki transakcyjnej, awaria własnej implementacji boli bardziej niż miesięczny rachunek. W takich miejscach nie opłaca się oszczędzać za wszelką cenę. Lepiej przenieść komponenty mniej wrażliwe niż ryzykować degradację całej platformy.

Use case 4: wymagania regulacyjne i kontrola operacyjna naprawdę zmieniają rachunek

Nie każda decyzja o Cloud Exit wynika z kosztu. Czasem kluczowe są wymagania dotyczące lokalizacji danych, audytu, sposobu szyfrowania, dostępu uprzywilejowanego albo kontroli nad łańcuchem dostaw. Jeśli regulacja lub kontrakt klienta wymusza określony model operacyjny, chmura publiczna może przestać być najprostszą opcją.

To nie znaczy, że on-prem jest automatycznie bardziej zgodny. Często jest odwrotnie: dostawca chmury ma lepsze certyfikacje i procesy niż pojedyncza firma. Problem pojawia się wtedy, gdy organizacja potrzebuje bardzo konkretnej kontroli technicznej lub prawnej, której nie da się osiągnąć bez nadmiernych obejść.

Przykład praktyczny: środowisko z długą retencją logów, restrykcyjnym dostępem administracyjnym i wymaganiem pełnej ścieżki audytowej dla zmian infrastruktury. W chmurze da się to zbudować, ale czasem koszt i złożoność obejść są większe niż utrzymanie wydzielonej platformy prywatnej. Wtedy decyzja nie jest już tylko finansowa. Jest operacyjna i kontraktowa.

Ten use case bywa nadużywany przez zarządy, które chcą „mieć wszystko u siebie”, choć realny wymóg dotyczy jednego systemu. To zły kierunek. Jeśli regulacja dotyczy 10% portfolio, przenieś 10%, a nie 100%.

Co najczęściej psuje projekt wyjścia z chmury

Najczęstsza porażka nie wynika z technologii, tylko z błędnego zakresu. Zespół bierze na siebie za dużo naraz: aplikację, dane, sieć, backup, observability i zmianę procesu wdrożeń. Potem okazuje się, że każdy obszar jest „prawie gotowy”, ale żaden nie jest gotowy produkcyjnie.

Drugi problem to niedoszacowanie okresu równoległego utrzymania. Przez kilka miesięcy płaci się jednocześnie za chmurę i nowe środowisko, bo trzeba migrować etapami, testować odtworzenie i utrzymać plan wycofania. Jeśli model finansowy tego nie uwzględnia, ROI wygląda dobrze tylko w arkuszu.

Trzeci błąd to pomijanie sieci. Opóźnienia, przepustowość, połączenia do partnerów, firewalle, VPN, segmentacja i DNS potrafią zjeść więcej czasu niż same maszyny. W środowiskach hybrydowych sieć jest zwykle pierwszym miejscem, gdzie wychodzi brak dyscypliny architektonicznej.

Jest jeszcze kwestia ludzi. Jeśli cała wiedza o nowej platformie siedzi w dwóch osobach, to nie jest gotowość operacyjna, tylko ryzyko personalne. Własna infrastruktura bez procedur, runbooków i automatyzacji szybko zamienia się w droższy odpowiednik starej serwerowni.

Jak podejść do migracji, żeby nie zepsuć produkcji

Najbezpieczniejszy model to migracja warstwami. Najpierw komponenty najmniej ryzykowne i najlepiej mierzalne kosztowo, potem elementy stanowe, na końcu to, co ma największą zależność od użytkownika końcowego. Odwrócenie tej kolejności zwykle kończy się nerwowym rollbackiem.

Dobra sekwencja wygląda często tak:

1. Uruchom środowisko docelowe z monitoringiem, backupem i automatyzacją od pierwszego dnia.
2. Przenieś workloady wsadowe lub archiwalne, bo łatwo zmierzyć efekt i ograniczyć ryzyko.
3. Zmigruj dane stanowe po testach odtworzeniowych i próbach wydajnościowych.
4. Przełącz ruch produkcyjny etapami, z planem rollbacku i oknem obserwacji.
5. Wyłącz stare zasoby dopiero po potwierdzeniu kosztu, wydajności i stabilności.

Przyspieszanie tej sekwencji zwykle kończy się tym samym błędem: zespół przenosi produkcję przed rzetelnym sprawdzeniem odtworzenia i zachowania systemu pod realnym obciążeniem. Samo uruchomienie aplikacji w nowym miejscu nie oznacza jeszcze gotowości operacyjnej. Najdroższe awarie po Cloud Exit biorą się właśnie z pomylenia migracji technicznej z gotowością do utrzymania.

Jeśli zespół pracuje na Kubernetes, warto osobno ocenić, czy przenoszona jest sama warstwa orkiestracji, czy także cały model operacyjny wokół niej. Sam klaster poza chmurą nie daje jeszcze tej samej jakości, jeśli brakuje rejestru obrazów, polityk bezpieczeństwa, logowania, metryk i procesu aktualizacji. Właśnie tu wiele organizacji odkrywa, że płaciło nie za „gołe VM”, tylko za wygodę całego ekosystemu.

Które komponenty najczęściej warto przenosić jako pierwsze

Pełny Cloud Exit często jest przereklamowany. W wielu organizacjach lepiej działa model hybrydowy: stabilne i kosztowne komponenty trafiają na własną platformę, a zmienne, internetowe albo eksperymentalne zostają w chmurze. To zwykle lepsza decyzja niż wojna z hyperscalerem prowadzona z powodów ideologicznych.

Na pierwszy ruch najlepiej nadają się warstwy wsadowe, archiwa, repozytoria plików, systemy raportowe i te bazy, które mają przewidywalny profil obciążenia oraz niewielką zależność od usług natywnych. To komponenty, na których łatwo policzyć efekt i stosunkowo łatwo przygotować plan odwrotu, jeśli coś pójdzie źle.

Znacznie gorszym kandydatem na start są elementy stojące bezpośrednio na ścieżce klienta: fronty internetowe z dużą zmiennością ruchu, krytyczne kolejki, usługi bezpieczeństwa i wszystko, co korzysta z głęboko zintegrowanych mechanizmów dostawcy. Tam koszt błędu jest wyższy niż potencjalna oszczędność z pierwszych miesięcy.

Przed decyzją wystarczą trzy pytania. Czy całkowity koszt naprawdę spada po doliczeniu migracji i operacji? Czy SLA, RTO i RPO pozostają akceptowalne? Czy zespół umie to utrzymać bez ręcznego gaszenia pożarów?

Jeśli na któreś z nich odpowiedź brzmi „jakoś to ogarniemy”, projekt jest niedojrzały. Jeśli odpowiedź brzmi „tak, i mamy to policzone dla konkretnego workloadu”, wtedy temat warto prowadzić dalej, najlepiej jako selektywną zmianę architektury, nie wielki program przenoszenia wszystkiego naraz.

Najpierw patrz na profil użycia, dopiero potem na wysokość faktury. Kandydatem do wyjścia z chmury jest workload przewidywalny, mało sezonowy i słabo zależny od usług natywnych dostawcy. Dobrze rokują środowiska, w których przez większość miesiąca zasoby są zajęte w podobnym stopniu, wdrożenia są rzadkie, a koszt storage lub egress stanowi dużą część rachunku. Sama duża faktura niczego jeszcze nie przesądza.

Jeden mocny wniosek na koniec: jeśli organizacja nie umie utrzymać porządku operacyjnego w chmurze, zwykle nie utrzyma go też poza chmurą. Cloud Exit nie naprawia chaosu. Co najwyżej przenosi go na własny sprzęt.

Dla zespołów, które chcą policzyć taki scenariusz bez zgadywania, sensownym kolejnym krokiem są usługi DevOps i chmury prywatnej albo projekt hybrydowy skupiony na najdroższych komponentach.