Przeprowadzka aplikacji biznesowych ze środowiska on-premise do infrastruktury – choćby w części opartej na usługach oferowanych w modelu chmury publicznej – jak każda, poważna operacja obarczona ryzykiem biznesowym powinna być przeprowadzona w sposób przemyślany i odpowiednio zorganizowany. Prezentujemy gotową listę aspektów, na które należy zwrócić uwagę, aby zadbać o sprawną migrację aplikacji do środowiska cloud computing.
Migracja działającego i wykorzystywanego w firmie oprogramowania do środowisk chmurowych może pozwolić m.in. na zwiększenie elastyczności aplikacji, poprawę efektywności ich działania w najbardziej newralgicznych okresach, czy obniżenie kosztów utrzymania. Aby jednak oczekiwane po przeniesieniu obciążeń aplikacyjnych do chmury obliczeniowej korzyści stały się realne, niezbędne jest przeprowadzenie procesu migracji w uporządkowany i dobrze zaplanowany sposób.
Duże znaczenie w procesie migracji do chmury ma wybór tych aplikacji, które warto przenieść do chmury w pierwszej kolejności. Należy więc skupić się na tych aplikacjach, których przeniesienie do chmury obliczeniowej przyniesie największe korzyści i będzie obarczone najmniejszym ryzykiem niepowodzenia. Bardzo dobrą wskazówkę podaje Google na swoim blogu (bit.ly/2P4FCxf). Zaprezentowana tam lista kontrolna pomaga wybrać te z aplikacji, które można przenieść do chmury przy najmniejszym ryzyku biznesowo-technicznym i potencjalnie największych korzyściach.
Poniżej prezentujemy omówienie jedenastu, najistotniejszych aspektów, które należy wziąć pod uwagę na etapie planowania i przygotowania projektu migracji oprogramowania biznesowego do środowisk chmurowych. Przy rozważaniu migracji aplikacji do środowisk wykorzystujących infrastrukturę publicznej chmury obliczeniowej należy zatem uwzględnić poniższe aspekty.
1. Jak bardzo krytyczna jest to aplikacja?
Które procesy biznesowe obsługuje, jak wielu użytkowników na niej polega i jakie skutki przyniesie jej niedostępność? Zazwyczaj wyróżnia się tutaj Tier 1 (aplikacje krytyczne), Tier 2 (średnio ważne), Tier 3 (mniej ważne, w tym środowiska deweloperskie, QA, testowe). Aplikacje określone jako Tier 3 powinniśmy rozważać w pierwszej kolejności. Poza ścisłą definicją krytyczności należy uwzględnić także wrażliwość aplikacji na inne czynniki, takie jak: dostępność, wrażliwość na opóźnienia, ręczne wdrażanie i utrzymanie, brak okien serwisowych lub ich krótki czas, a także globalna dostępność.
2. Jaki jest stan dojrzałości danej aplikacji?
W ramach typowego środowiska IT mamy do czynienia zarówno z aplikacjami wdrożonymi produkcyjnie, jak i tymi w trakcie wdrożenia, w trakcie tworzenia oraz w czasie pierwszych testów. Najkorzystniejsze efekty uzyskamy przenosząc do chmury aplikacje znajdujące się trakcie tworzenia i testowania, gdyż ewentualne zmiany pod kątem pracy w chmurze będzie można przeprowadzić najtaniej i najszybciej.
3. W jaki sposób aplikacja przetwarza dane?
Najkorzystniejszy jest model stateless, mniej korzystny będzie model stateful, zaś w najgorszym przypadku na danych tej aplikacji polegają też inne aplikacje.
4. Kto utworzył tę aplikację, od kogo została uzyskana i czy nadal wykonawca jest dostępny, jak dobrze jest udokumentowana?
Najlepsze efekty przynosi oprogramowanie napisane na własne potrzeby, przez pracowników, którzy nadal w firmie pracują. Im większą ilością szczegółowej dokumentacji dysponujemy, tym łatwiejsze jest dostosowanie migrowanej aplikacji do środowiska chmurowego.
5. Czy istnieją wymagania regulacyjne dla aplikacji i danych, które przetwarza?
Im mniej takich wymagań istnieje, tym lepiej. Migrację środowiska aplikacyjnego do chmury należy rozpoczynać od aplikacji, które takim regulacjom nie podlegają w ogóle.
6. Jakich problemów spodziewamy się przy migracji?
Czy będzie to proste przeniesienie w takim stanie w jakim aplikacja jest wykorzystywana obecnie (np. migracja maszyn wirtualnych), czy też niezbędny będzie refaktoring lub modernizacja aplikacji.
7. Czy aplikacja polega na stosie, którego nie będzie się opłacało odwzorowywać w chmurze?
Czy istnieją inne zależności w warstwie aplikacyjnej utrudniające uruchomienie aplikacji w środowisku chmury publicznej? Im mniej zależności i starszych technologii, tym lepiej.
8. Jakie niezależne procesy przetwarzania danych pracują w obrębie tej aplikacji?
Możliwe to m.in. przesyłanie wiadomości, monitoring, utrzymanie, generowanie raportów, wymiana danych z zewnętrznymi aplikacjami. Im mniej zależności, tym lepiej.
9. Jak działa baza danych tej aplikacji (oraz cały podsystem storage) i gdzie się znajduje?
Najlepiej, gdy są to kolokowane lub dedykowane serwery, które można łatwo przenieść do środowiska chmurowego. W przypadku składowania danych należy także wiedzieć, czy podsystem storage działa na poziomie plików czy bloków.
10. Jakie protokoły wykorzystuje aplikacja?
Czy mamy do czynienia ze stałym potokiem połączeń, czy używa Web services, czy używa wywołań RPC w którąkolwiek stronę, z jakich portów korzysta i w jaki sposób, czy używa rezerwowych usług i połączeń? Jak wygląda konfiguracja firewalla realizowana pod kątem tej aplikacji? Odpowiedzi na te pytania pozwalają ocenić stopień złożoności migracji.
11. Czy aplikacja lub jej bezpieczeństwo zależy od innego rozwiązania, które nie ma swojego odpowiednika w docelowej chmurze?
Często jest to aspekt warunkujący możliwość przeprowadzenia migracji aplikacji do środowiska chmury publicznej.
Odpowiedzi na powyższe pytania pozwolą przygotować listę aplikacji, które warto przenieść do chmury w pierwszej kolejności. Łatwiejsze stanie się również opracowanie zakresu zmian niezbędnych do wdrożenia w tych aplikacjach, które wymagają zmian lub szczególnego dostosowania środowiska. Dzięki powyższej liście kontrolnej realna będzie też ocena, w przypadku których aplikacji migracja do chmury nie jest warta zachodu.
