projekt, nie abonament
Rozchmurzanie
Chmura publiczna jest świetna przy zmiennym obciążeniu. Przy stałym bywa wielokrotnie droższa od tego samego zasobu gdzie indziej - a rachunek rośnie tak powoli, że nikt nie zauważa momentu, w którym przestała się opłacać.
To jest decyzja z faktury, nie z przekonania
Chmura publiczna wygrywa tam, gdzie obciążenie skacze: sezon, kampania, nagły ruch. Płacisz za szczyt tylko wtedy, gdy szczyt jest. Przy obciążeniu stałym ten sam mechanizm działa przeciwko Tobie - płacisz co miesiąc za elastyczność, której nie używasz.
Rachunek rośnie po cichu. Dokładany zasób, kolejne środowisko testowe, kopia zapasowa w innym regionie, transfer wychodzący. Każda pozycja z osobna wygląda niegroźnie i dlatego nikt nie zauważa progu, na którym całość przestała się opłacać.
Dlatego zaczynamy od trzech ostatnich faktur i profilu obciążenia, nie od propozycji migracji.
Co robimy
- analiza kosztów - rozbicie rachunku na zasoby stałe, zmienne i transfer
- rachunek porównawczy wobec serwerów dedykowanych i chmury prywatnej, z kosztem administracji po obu stronach
- konfiguracja chmury prywatnej na Hetznerze
- migracja z AWS - planowana etapami, z okresem pracy równoległej
- strategie wyjścia z vendor lock-in - co zrobić z bazami zarządzanymi, orkiestracją i usługami, które nie mają odpowiednika poza jednym dostawcą
Trzy pozycje, które zwykle zaskakują
Transfer wychodzący bywa liczony osobno i potrafi być znaczącą częścią rachunku, mimo że nikt nie zamawiał go świadomie. Środowiska nieprodukcyjne pracują dwadzieścia cztery godziny, choć są używane w godzinach biurowych. Kopie zapasowe i migawki zostają po projektach, które skończyły się rok temu.
Te trzy rzeczy potrafią obniżyć rachunek bez żadnej migracji. Jeśli po ich uporządkowaniu koszt wraca do sensownego poziomu, projekt kończy się na tym etapie - i tak też o tym mówimy.
Jak wygląda migracja
Etapami, z okresem, w którym stare i nowe środowisko pracują równolegle. Najpierw przenosimy to, co najmniej związane z usługami zarządzanymi: maszyny wirtualne, pliki, środowiska testowe. Bazy i orkiestracja idą później, bo tam ryzyko jest największe, a odtworzenie funkcji zarządzanej wymaga świadomej decyzji, ile administracji serwerami bierzecie na siebie.
Ścieżka powrotu istnieje na każdym etapie, dopóki nie wyłączymy starego środowiska. Wyłączenie jest ostatnią czynnością, nie pierwszą.
Co zwykle zostaje w chmurze
Wyjście rzadko jest całkowite i nie musi być. Poczta i pakiet biurowy zostają w Microsoft 365, bo utrzymywanie własnego serwera pocztowego to dziś koszt i ryzyko bez rekompensaty. W chmurze zostaje też kopia zapasowa poza siedzibą - jej sensem jest właśnie to, że leży gdzie indziej.
Przenosi się natomiast to, co pracuje stale i przewidywalnie: maszyny wirtualne z aplikacją, bazy danych o ustabilizowanym obciążeniu, środowiska deweloperskie. Podział przebiega wzdłuż zmienności obciążenia, nie wzdłuż rodzaju usługi - i to jest jedyne kryterium, które broni się na fakturze rok później.
Dla kogo
Firmy z przewidywalnym, stałym obciążeniem i rachunkiem, który rósł szybciej niż korzystanie. Najczęściej: aplikacja własna z ustabilizowaną liczbą użytkowników, systemy wewnętrzne przeniesione do chmury „przy okazji”, środowiska deweloperskie żyjące bez nadzoru.
Temat jest złożony i rzadko ma jedną poprawną odpowiedź. Jeśli jesteś w tym miejscu i szukasz rozwiązań - trzeba porozmawiać, a nie wypełnić formularz z liczbą stanowisk.
Najczęstsze pytania o wyjście z chmury
Co właściwie znaczy „rozchmurzanie”?
Przeniesienie części albo całości obciążenia z chmury publicznej na tańszą platformę: serwery dedykowane, chmurę prywatną albo sprzęt na miejscu. To nie jest ideologiczny powrót do własnej serwerowni - to decyzja liczona na fakturach, podejmowana wtedy, gdy obciążenie jest przewidywalne.
Ile realnie da się zaoszczędzić?
Zależy od profilu obciążenia i tego, ile z rachunku pochodzi z usług zarządzanych. Największe różnice widać przy stałej mocy obliczeniowej i dużym ruchu wychodzącym - transfer poza chmurę bywa osobną, sporą pozycją, o której przy wdrożeniu nikt nie myślał. Rachunek robimy przed migracją, nie po.
Kiedy NIE warto wychodzić z chmury?
Przy dużej zmienności obciążenia, sezonowych szczytach, zespole rozproszonym po świecie i tam, gdzie korzystacie z usług zarządzanych, których odtworzenie zjadłoby oszczędność w postaci czasu administracji. Jeśli rachunek wychodzi na niekorzyść, mówimy to wprost i kończymy na analizie.
Co z vendor lock-in?
Im więcej usług zarządzanych, tym trudniej wyjść - bazy typu RDS, orkiestracja typu EKS i funkcje bezserwerowe wiążą najmocniej. Strategię wyjścia projektuje się przed wdrożeniem albo dopisuje później, drożej. W obu przypadkach chodzi o to, żeby dało się odtworzyć środowisko u innego dostawcy w rozsądnym czasie.
