Kiedy warto migrować do chmury?

W stronę Amazon Web Services, Google Cloud Engine i Microsoft Azure, czołowych graczy w branży rozwiązań popularnie zwanych chmurami, spogląda coraz więcej firm. Od małych, po korporacje, wszyscy zastanawiają się, czy „warto migrować do chmury”?

Krótką odpowiedzią jest „tak, migrujcie”, dłuższą jest „to zależy”.

Kiedy migrować do chmury?

Powiedzmy sobie szczerze: nie zawsze warto i nie zawsze jest to możliwe. Migracja do chmury dużo rzeczy ułatwia, ale trzeba najpierw wykonać trochę pracy, zanim będzie łatwiej, lepiej i szybciej. Jeśli wewnętrznie w firmie administratorzy nadal używają tylko ssh do zarządzania serwerami, to może być pierwszy znak przeciwko migracji. Brak automatyzacji natychmiast nas dyskwalifikują.

1. Audyt wewnętrzny

Zanim przejdziemy dalej, warto by było krytycznie spojrzeć na nasze systemy i „odhaczyć” kilka krytycznych pytań:

  • Czy jest automatyczne zarządzanie konfiguracją? (Puppet, Ansible, Saltstack, Chef lub inne narzędzie)
  • Czy jest zaimplementowany monitoring? Chodzi mi tu głównie o monitorowanie ważniejszych metryk, typu ilość błędów na stronie, konwersja użytkowników, interakcje pomiędzy komponentami architektury… czyli nie tylko niskopoziomowe statystyki systemowe.
  • Czy aplikacja potrafi działać na wielu serwerach jednocześnie?
  • Jak aplikacja reaguje na brak dostępu do różnych komponentów systemu? Jeśli aplikacja przestaje całkowicie działać, najpewniej będziemy chcieli coś z tym zrobić, zanim przejdziemy dalej, bądź w trakcie wykonywania drugiego punktu, którym jest pierwsza próba migracji.

2. Próba migracji

Czyli po prostu testowanie, jak będzie się zachowywał nasz system w innym środowisku. Proof of Concept, jak to się nazywa powszechnie, powinien się składać również z przygotowania podstawowej automatyzacji i skryptów migracyjnych. Warto również przyjrzeć się dokładniej poszczególnym możliwościom u wybranego dostawcy. Na przykład, jeśli używamy Dockera, lub nawet Kubernetes – w Google Cloud Engine może będziemy chcieli bliżej przyjrzeć się Kubernetes w modelu PaaS (Google Container Engine), lub nawet jego odpowiednikiem Elastic Container Engine w AWS.

Jeśli znowu używamy Chefa do zarządzania serwerami, może nas zainteresować OpsWorks w AWS.

Możliwości jest multum, dlatego warto zainwestować miesiąc lub dwa dla „rozejrzenia” się w sytuacji i wybrania opcji najlepszej dla nas. Wyjątkiem jest jeśli tworzymy nowe oprogramowanie, które możemy dostosować do wcześniej wybranego rozwiązania – wtedy będziemy chcieli wybrać coś, co będzie najbardziej odpowiadało specyfice aplikacji. Dobrze poprosić jakiegoś konsultanta, który będzie w stanie wskazać dostępne opcje.

3. „Kultura” w firmie

Nie mniej ważną zmienną w całym procesie jest kultura i sposób pracy w firmie. Często programiści i administratorzy nie są przygotowani psychicznie na taką migrację. Wymaga to bowiem dość istotnej zmiany w sposobie myślenia o systemach i sposobie pracy.

Przede wszystkim, trzeba założyć, że każdy serwer, który uruchomimy, może zostać w każdym momencie wyłączony – musimy więc planować od razu, że aplikacja będzie działać na kilku serwerach w różnych centrach danych (w AWS są to strefy dostępności – Availability Zones).

Sposób pracy trzeba będzie przeorganizować w ten sposób, żeby nie było potrzeby logowania się do serwerów manualnie. Stawiamy wszystko na automatyzację wszystkiego, co jest powtarzalne. Dla wielu osób to będzie problem, ponieważ będą się czuły pozbawione kontroli nad tym co się dzieje. Zalogowanie się na serwer, spojrzenie w logi, restart serwisów tak weszły już w krew, że wiele osób poczuje się bezradne w zderzeniu z tym nowym podejściem.

Niestety, jest to konieczne. Wyobraźmy sobie 200 serwerów, które serwują ten sam serwis. 80 z tych serwerów przestało funkcjonować i wymaga restartu serwera www. Będziesz się na każdy z nich ręcznie logował i to robił? W jaki sposób zidentyfikujesz te 80 serwerów, jeśli mają one nazwy w formacie ip-xx-yy-zz-ww.local? Może się też okazać, że łatwiej jest pozbyć się tych wadliwych maszyn i zastąpić je nowymi, zamiast inwestować czas na ich naprawianie. Zamienianie maszyn, w odróżnieniu od naprawiania ich „ręcznie”, dużo łatwiej jest zautomatyzować.

Czy to już wszystko?

Aby z sukcesem migrować do chmury, nie trzeba myśleć o żadnym z powyższych. Można po prostu utworzyć maszyny u wybranego dostawcy. Skonfigurować serwisy, jak to robiliśmy do tej pory i gwarantuję, że będzie wszystko działało. Miejscami może nawet szybciej niż na Twoich aktualnych serwerach fizycznych.

Jednak pozbawisz się przez to wszelkich udogodnień, które daje chmura: bezobsługowość, automatyczne skalowanie aplikacji i wysoka dostępność Twojej aplikacji.

Dodatkowo, narazisz się na utratę danych: jeśli stracisz jedyną maszynę, na której zainstalowałeś bazę danych, będzie ona nie do odzyskania. A taka sytuacja może się zdarzyć!

Niezależnie od tego, czy chcemy migrować do chmury, czy nie, warto popracować nad dobrymi praktykami, o których wspomniałem. Na pewno nie zaszkodzi, a z pewnością pomoże w stabilności systemu i przyjemności pracy z takim środowiskiem.

Podobne

Przyszłość pracy z chmurą publiczną
przeczytano 55
Przeglądając moją prezentację z przed kilku lat, uznałem, że dotknąłem tam ciekawego tematu. O ile jest on nadal dość burzliwy (hura, mikroserwisy), o...