Migracja systemów czy aplikacji do modelu chmurowego staje się coraz częstszym wyborem cyfryzujących się organizacji. Atrybuty cloud computingu, takie jak szybkość, skalowalność, elastyczność, możliwość szybkiego podnoszenia i wygaszania środowisk testowych, znajdują swoje odzwierciedlenie w stale rosnącym dwucyfrowo rynku. Mniejsze, zwinniejsze organizacje mogą szybko i sprawnie zbudować model biznesowy oparty o aplikacje typu cloud native, te większe – posiadające rozbudowane środowiska własne – muszą migrację do chmury planować i realizować w inny sposób.

Na pewno sytuacja na rynku chmurowym sprzyja zmianom. Do niedawna rynek regulowany, choć gotowy na chmurową transformację, musiał cały czas pozostawać w blokach startowych. Dla globalnych dostawców usług chmurowych Polska nie była rynkiem priorytetowym. Dziś sytuacja się zmienia, tworzone są regiony chmurowe dla Polski, co w przypadku rynku regulowanego ma ogromne znaczenie.

Nadal wyzwaniem pozostaje sposób, w jaki serwisy należy migrować do chmury publicznej. Odpowiedzi, czy też swoistą mapę transformacyjną znajdziemy w studium przypadku wspomnianej migracji w dużym polskim banku.

1. Kompetencje

Zmiana musi zacząć się od znalezienia odpowiednich kompetencji do jej realizacji. W omawianym przypadku duży polski bank, który chciał uruchomić swoje aplikacje w chmurze Google, jako partnera zmiany wybrał dużego regionalnego gracza – Oktawave z Grupy Netia. Od czasu połączenia się Netii z polskim operatorem platformy chmurowej Oktawave, powstał podmiot posiadający kluczowe kompetencje pozwalające przeprowadzać skomplikowane projekty z wykorzystaniem technologii Vmware na autorskiej platformie Netia Compute oraz migracje do globalnych chmur publicznych.

2. Analiza

Migracja do chmury, szczególnie w przypadku podmiotu regulowanego, to poważna decyzja biznesowa, sięgająca skutkami daleko poza sam proces migracji od strony technologicznej. Kluczowa była tu analiza potrzeb banku, ale też wyraźne wskazanie działań, które pozwolą po samej migracji utrzymać ciągłość działania procesów. Oktawave z Grupy Netia zaprosiło do współpracy i planowania zmiany nie tylko zespoły IT banku, ale również zespoły biznesowe. To pozwoliło na o wiele szersze spojrzenie na projekt niż tylko jak na technologiczną zmianę.

3. Współpraca i transparentność komunikacji

O przyszłym sukcesie projektu migracyjnego w dużej mierze decydował model współpracy pomiędzy zaangażowanymi zespołami Oktawave, softwarehouse’u i banku. Jasno określone tempo prac i harmonogram działań był komunikowany za pomocą sprawnie wyznaczonych kanałów informacyjnych w różnych płaszczyznach struktury firm. Dzięki transparentności informacji wyeliminowano sytuacje niedoinformowania poszczególnych zespołów czy ich członków o bieżącym statusie czy planowanych kolejnych działaniach. W przypadku tego projektu, który zaczął być realizowany już w okresie pandemii, komunikacja była kluczowa – zespoły spotykały się wirtualnie, błąd komunikacyjny mógł wpłynąć na realizację zadań.

4. Zaufanie i kompetencje

Dodatkowym wyzwaniem w projekcie było wypracowanie i utrzymanie właściwych relacji z działem compliance, który musiał zaakceptować i być pewny, że to, co proponuje Oktawave, jest zgodne z wytycznymi regulatora. W praktyce oznaczało to spotkania, na których omawiane były planowane przyszłe kroki migracyjne, wypracowano odpowiednie procedury, określające jak organizacja będzie funkcjonowała po migracji. Zespół Oktawave miał świadomość, jakie wymogi są stawiane w branży regulowanej, developerzy pisali kody w ten sposób, by mogły one przejść szereg testów bezpieczeństwa. Co ważne – wypracowane procedury przetarły w banku szlak dla kolejnych projektów, a organizacja zyskała bezcenną wiedzę, jak w przyszłości inicjować kolejne zmiany.

5. Ocena technologiczna

W tym projekcie istotne było określenie na jakim etapie technologicznym był bank i dokąd zmierzał. Aplikacja przeznaczona do migracji była obarczona długiem technologicznym, działała od lat w modelu monolitycznym. Ważnym było więc wypracowanie odpowiedniej ścieżki postępowania migracyjnego.

6. Realizacja i migracja

Jeszcze na etapie analizy projektu zespoły oceniły, co można wydzielić z aplikacji głównej, w jaki sposób przeprowadzić reengineering, by wykorzystać rozwiązania natywne dla chmury. Oktawave wybrało ścieżkę małych zmian, z wykorzystaniem metody lift&shift tych elementów, które można było w pierwszej kolejności przenieść do środowiska chmurowego. Część elementów aplikacji finalnie zostało uruchomionych w trybie legacy, ale z planami do dalszych, późniejszych zmian. Wybór metody małych kroków przy aplikacji legacy pozwolił bankowi przede wszystkim zapoznać się z potencjałem chmury i przygotować się do kolejnych zmian.

7. CI/CD

W przypadku tego projektu Oktawave wykorzystało procesy CI/CD (Continuous Integration/ Continuous Delivery), co pozwoliło zespołom wykonawczym w pełni kontrolować wprowadzane zmiany we wszystkich środowiskach (deweloperskim, przedprodukcyjnym, produkcyjnym i testowym). Operowanie na rozwiązaniach pozwalających przechowywać konfigurację zawartej na systemach kontroli wersji jest ważnym elementem późniejszego utrzymania środowisk w formie działającej i zgodnej. We wcześniejszej wersji środowiska cofnięcie się do poprzedniej wersji było procesem kosztownym, wymagającym dużych nakładów pracy zespołów. W tym projekcie przenoszenie konfiguracji odbywało się automatycznie, co znacznie skróciło czas i pozwoliło np. testować rozwiązania na środowisku niższym i mieć pewność, że w środowisku produkcyjnym działanie będzie właściwe.

Co dalej?

Projekt zakończył się sukcesem migracyjnym, obecnie realizowany jest kolejny – utrzymanie całego serwisu w chmurze. Na tym jednak nie koniec. Cały czas Oktawave pracuje nad rozwojem aplikacji, nad redesignem – czyli dalszym dostosowywaniem aplikacji do działania w formie mikroserwisów i zmianą starszej technologii na nową. Te działania wyraźnie pokazują, że transformacja cyfrowa jest procesem ciągłym.