Chmura: wiadomo jak wejść, ale jak wyjść?

Transformacja cyfrowa przedsiębiorstw postępuje w ogromnym tempie, niezależnie od sektora. Wraz z nią rośnie nasycenie usługami chmurowymi. Niekwestionowanym liderem w tym obszarze są Stany Zjednoczone oraz Europa zachodnia i kraje skandynawskie.

W przypadku polskich przedsiębiorstw okres największej transformacji, jest jeszcze ciągle przed nami. Dlatego też obserwując to co dzieje się na zachodzie, warto wyciągać wnioski i ucząc się na doświadczeniach innych, wdrażać rozwiązania o znacząco lepszej jakości.

Dziś nikt nie rozmawia już o tym czy warto migrować rozwiązania do chmury, ale o tym w jaki sposób to zrobić. Tym samym budując dojrzały serwis IT w chmurze, należy rozważyć wiele opcji, które związane są z przeprowadzeniem migracji, a także dobraniem odpowiednich narzędzi. Niemniej jednak dojrzałość w świadczeniu usług wymaga, aby zaplanować nie tylko samą migrację, ale także możliwość wycofania się z wdrożenia, a w tym uniezależnienie się od dostawcy usług i jeśli zajdzie taka konieczność także jego zmianę.

Vendor lock-in

Obszar zajmujący się ograniczeniem ryzyka związanego z zablokowaniem możliwości wyjścia z chmury nazywany jest Vendor lock-in lub Provider lock-in. Oznacza on zabezpieczenie się na wypadek zmiany dostawcy usługi, która wystąpić może z różnych powodów, w tym takich jak: konsolidacja usług u innego dostawcy, migracja z uwagi na kontrakt strategiczny podpisany przez organizację, lub regulacje prawne, a także i polityczne np.: szeroko dyskutowany w ostatnim czasie Brexit.

Z holistycznego punktu widzenia, większość usług oferowanych w chmurach publicznych jest zbliżona, a przez to migracja pomiędzy dostawcami wydaje się nie przysparzać wielu wyzwań. Jeśli jednak przyjrzeć się temu zagadnieniu szczegółowo, zauważyć można znaczące ryzyko, w przypadku realizacji projektu migracji pomiędzy chmurami. Ryzyko to skategoryzować można w kilku grupach.

Jednym z głównych obszarów ryzyka związanego z potencjalnym wyjściem z chmury jest infrastruktura. Mimo, że usługi oferowane przez dostawców są zbliżone, należy pamiętać, iż nie są one identyczne. Największe zróżnicowanie zaobserwować możemy na poziomie rozwiązań platform takich jak PaaS czy też FaaS. Adaptując rozwiązania w tych warstwach musimy mieć świadomość, iż zmiana dostawcy platformy chmury, wymagać będzie nie tylko prostej migracji, ale także adaptacji lub całkowitego przepisania wdrożonych rozwiązań.

Szczególnym ryzykiem jest także warstwa aplikacji, która w celu optymalnego wykorzystania, pisana jest bezpośrednio na platformę, w konsekwencji czego, w przypadku migracji, wymaga adaptacji kodu źródłowego, lub wręcz przepisania rozwiązania od nowa. Jednocześnie przenosząc aplikacje pomiędzy środowiskami, należy także przygotować się na oczekiwania klienta, co do wdrożenia dodatkowych zmian w funkcjonalności. Przy czym aspekt, zarządzenia oczekiwaniami klienta to materiał na zupełnie inny artykuł.

Kolejnym obszarem ryzyka związanego z wyjściem z usługi jest transfer danych. Pojęcie to postrzegać możemy w dwóch wymiarach, jako koszt oraz czas. W pierwszym przypadku wyjście z chmury wymaga od nas zaplanowania kosztów związanych z transferem danych, który w przypadku dużych systemów może stanowić znaczący wpływ na budżet projektu, drugim natomiast obszarem jest czas migracji danych, który bezpośrednio wpływa na niedostępność usługi.

Ostatnim ze zidentyfikowanych obszarów ryzyka jest doświadczenie w migracji, a w tym dogłębna znajomość usług dostawców, obecnego jak i docelowego. Jako, że zagadnienie vendor lock-in, rozpatrywane winno być jeszcze przed uruchomieniem realizacją migracji, wymaga od nas przewidzenia zachowania się systemów, które nie zostały jeszcze wdrożone. Mnogość zmiennych w tym obszarze, może sprawić, iż samodzielnie nie będziemy w stanie przewidzieć i zidentyfikować każdego ryzyka. Tym samym zasadnym rozwiązaniem będzie zaproszenie do projektu dostawcy posiadającego doświadczenia z kilkoma dostawcami, a który poprzez testy oraz bazę przepracowanych wcześniej przypadków pomoże nam w ominięciu wielu niepotrzebnych wyzwań.

Należy również podkreślić, iż ryzyko związane z techniczną migracją usług to nie wszystko. Warto zwrócić również uwagę na zagadnienia projektowe oraz prawne, takie jak, przeprowadzenie studium wykonalności i przedstawienie planowanego rozwiązania w postaci dokumentu – solution design. Z doświadczenia, dogłębne przygotowanie przed rozpoczęciem wdrożenia, może zaoszczędzić wiele nerwów i niepotrzebnych emocji w trakcie implementacji rozwiązania.

Metodyczne podejście

Warto nadmienić, iż realizując wdrożenia, niezależnie od ich skali, warto oprzeć się o metodykę. Jedną z rekomendowanych w przypadku wdrożeń w obszarze usług chmurowych jest BOCAM (ang. Benefits Oriented Cloud Adoption Method), która poprzez systematyczne podejście pomoże nam z kompleksową realizacją projektu, włączając w to zagadnienie wyjścia z danej platformy.

Mimo, iż rozwiązania ofertowane w chmurze, szczególnie u wiodących dostawców mogą kojarzyć się nam z bezpieczeństwem oraz możliwością nieograniczonego skalowania usługi, w praktyce widzimy wiele przypadków, w których może dość do konieczności zmiany środowiska. Dlatego też, zanim wdrożymy rozwiązanie, warto zastanowić się nad ryzykiem wejścia w daną usługę i rozważyć co najmniej kilka podstawowych sposobów uniknięcia wyzwań związanych z wyciem od danego dostawcy (vendor lock-in).

W pierwszej kolejności zwróć uwagę na umowę, a w tym na koszty związane z transferem danych poza chmurę. Zabezpiecz kwestię automatycznego przedłużania się kontraktu i możliwości zmiany parametrów usługi w trakcie jej trwania. Wdrażaj możliwie generyczną architekturę w oparciu o Kubernetes czy Docker i nie zapominaj, iż strategia on-premises, zakładająca utrzymanie usług w organizacji to również opcja, a wybór najlepszego rozwiązania podyktowany jest zawsze specyficznymi wymaganiami biznesu.