Uzależnienie od jednego dostawcy (vendor lock-in) to problem coraz częściej podnoszony przez organizacje migrujące kluczowe części swoich operacji do chmury. Można uniknąć bądź zmniejszyć negatywny wpływ ryzyka podejmując już na początku procesu pewne kroki i zadając właściwe pytania.
Firmy coraz śmielej przenoszą swoje operacje IT do chmury publicznej mając świadomość, że migracja do chmury może przynieść firmie wiele korzyści, od zwiększonej sprawności działania, poprzez elastyczność do oszczędności kosztów. Pomimo tych pozytywów wiele firm rozważających wykorzystanie usług chmurowych dla części – często kluczowych – swoich operacji biznesowych, ma uzasadnione obawy. Jedną z głównych jest ryzyko uzależnienia od jednego dostawcy usług.
Na początku należy zadać sobie pytania co się stanie, jeśli:
- oferta dostawcy usług w chmurze (Cloud Service Provider – CSP) nie spełni wymagań i nie będzie odpowiadać potrzebom?
- CSP dokona poważnych zmian w dostarczanych produktach i usługach, która utrudnią bądź uniemożliwią działalność firmy?
- CSP zakończy działalność lub zostanie przejęty przez innego operatora i działalność będzie wygaszana?
W większości przypadków migracja do chmury, jeśli jest zaplanowana i wykonywana poprawnie, przebiega płynnie i bezproblemowo. Ale po migracji mogą pojawić się problemy z CSP, których nie da się rozwiązać a przejście do innego dostawcy usług chmurowych może oznaczać znaczne koszty, być bardzo problematyczne techniczne jak i prawnie. Co zatem możesz zrobić, aby uniknąć uzależnienia od dostawcy chmury, a przynajmniej zminimalizować negatywne skutki tej zależności?
Źródła obaw
Obawy związane z nadmiernym uzależnieniem od jednego dostawcy usług w chmurze mają kilka źródeł. Po pierwsze, jest to brak kontroli nad danymi i infrastrukturą, które stanowią podstawę działania aplikacji biznesowych. Świadomość utraty pełnej kontroli nad takimi aspektami jak bezpieczeństwo czy zarządzanie infrastrukturą może dla niektórych stanowić barierę mentalnościową.
Kolejną niepokojącą sprawą jest powierzenie jednemu dostawcy realizacji wielu krytycznych, z punktu widzenia przedsiębiorstwa, potrzeb – sieć, serwery, dane, zarządzanie dostępem, dostępność aplikacji itp. – wszystkie te aspekty powierzamy w ręce jednej firmy. Takie uzależnienie może być niezwykle szkodliwe dla organizacji, jeśli coś pójdzie nie tak na linii dostawca-firma. Uzasadnione są też obawy, że jeden dostawca usług w chmurze nie zaspokoi tak bieżących jak i przyszłych potrzeb firmy wynikających z jej rozwoju biznesowego. CSP może mieć problem z zapewnieniem uzgodnionego SLA czy odpowiedniego poziomu bezpieczeństwa danych (wynikającego np. z RODO lub szczegółowych regulacji branżowych. Wszystko to może zmusić firmę do rewizji swojego zaangażowania w umowę z określonym dostawcą.
Marcin Zmaczyński Head of Marketing CEE w Aruba Cloud:
Kiedy potencjalny klient rozważa powierzenie danych lub infrastruktury podmiotowi zewnętrznemu, musi mieć pewność, że nie straci kontroli nad swoimi zasobami. Perspektywa utraty dostępu poprzez vendor lock-in może oznaczać poważne kłopoty. Dlatego naszym zadaniem, jako dostawcy usług chmurowych, jest z jednej strony rzetelne wyjaśnienie wszystkich wątpliwości dotyczących takich kwestii jak przenaszalność aplikacji, kompatybilność z innymi platformami czy ewentualne dodatkowe koszty, a z drugiej dostarczenie usługi o jakości, która nie będzie budziła obaw.
Nie należy również ignorować ryzyka zaprzestania działalności przez dostawcę bądź zmian związanych z dostępnymi regionami i usługami. W świadomości każdego menedżera IT znajdują się trudności (organizacyjne, kadrowe, technologiczne itp.) i koszty związane z ewentualnym transferem do nowego dostawcy. Taka zmiana może być nawet bardziej kosztowna niż pierwotna migracja do chmury z on-premise.
Cztery rodzaje ryzyka
Choć domyślnie przyjmujemy, że to się nigdy nie wydarzy i chcielibyśmy, aby tak było to trzeba się liczyć z sytuacją, w której nie będziemy mieć innego wyjścia jak tylko zmiana dostawcy. Aby temu zapobiec należy przeprowadzić analizę ryzyka jeszcze zanim podejmiemy decyzję o migracji czy wyborze dostawcy. Ryzyka związane z wyborem i zależnością od jednego dostawcy usług można podzielić na cztery grupy, są to ryzyka związane z infrastrukturą, transferem aplikacji, danych i kompetencjami.
Ryzyko infrastruktury
Mimo, że główni dostawcy hiperskalowi (AWS, MS Azure, Google Cloud) oferują de facto podobne, jeśli nie identyczne usługi to miarodajne porównanie ich parametrów ze sobą, a zwłaszcza zestawienie odpowiadających sobie konfiguracji jest bardzo trudne. Dotyczy to formatów maszyn wirtualnych, których ceny różnią się w zależności od dostawcy, co utrudnia zapewnienie odpowiedniego wykorzystania zasobów i oszczędności w przypadku zmiany dostawcy. Dotyczy również oferty i form rozliczeń za dostęp do baz danych. Dostawcy oferują różne komponenty w atrakcyjnych cenach, ale jednocześnie może brakować opcji, która nas interesuje. Te różnice w podstawowej infrastrukturze powodują trudności z przejściem od jednego dostawcy usług w chmurze do innego.
Ryzyko transferu aplikacji
Budując aplikacje biznesowe z wykorzystaniem natywnych funkcji udostępnianych przez dostawcę (co jest standardową praktyką ze względu na oszczędności i efektywność działania aplikacji) musimy liczyć się koniecznością trudnej i kosztownej rekonfiguracji lub wręcz przebudowy aplikacji zgonie ze środowiskiem natywnym innego dostawcy. Opracowując na przykład aplikację analityczną na platformie Microsoft Azure wykorzystujemy nie tylko podstawowe usługi chmurowe jak moc obliczeniowa, pamięć, bazę danych czy sieć, ale również funkcjonalności uczenia maszynowego czy zarządzania klastrami. Zmiany w aplikacji przy przenoszeniu do innego dostawcy nie będą w tym przypadku proste i część aplikacji będzie trzeba zbudować od podstaw.
Jednym z powodów jest brak standardów i otwartych interfejsów API. Każdy CSP ma swoje własne specyfikacje i standardy, które sprawiają, że bardzo transfer pomiędzy nimi jest najeżony problemami. Innym powodem jest to, że technologia i potrzeby klientów zmieniają się bardzo szybko. Wiemy, że klienci i partnerzy domagają się ulepszeń i zmian w dostarczanych produktach a szybka adaptacja do potrzeb jest koniecznością. Jednak im więcej zmian dokonywanych jest w aplikacji wykorzystując natywne interfejsy dostawcy tym bardziej „wrasta” ona w środowisko dostawcy i tym trudniej potem ją przenieść do innego dostawcy.
Ryzyko transferu danych
Transfer danych z jednego CSP do innego nie należy do łatwych zadań i podczas tego procesu pojawi się mnóstwo pytań związanych m.in. z tym:
- kto jest odpowiedzialny za wydobycie danych z baz danych w chmurze czy hurtowni danych (klient czy dostawca) i kto ponosi koszt?
- w jakim formacie będą dane? Czy będzie kompatybilny nowym dostawcą usług w chmurze, czy też konieczne będą istotne zmiany w formatowaniu danych w ramach procesu ETL?
- czy transfer/transformacja danych nie spowoduje utraty funkcjonalności aplikacji biznesowych?
- jak długo potrwa i ile będzie kosztować przeniesienie wszystkich danych? (często transfer Do dostawcy jest tani lub darmowy, pobieranie danych jest droższe).
Prace nad standardami wymiany danych, zwłaszcza branżowe, napotykają na problemy a firmom trudno je zastosować ze względu na często specyficzne wymagania biznesowe.
Ryzyko kompetencji
Migracja do wybranego dostawcy oznacza konieczność budowy nowych kompetencji w zespole IT, szkolenia i często certyfikacje. Poza tym, zespół uczy się w trakcie migracji i po, w ramach procesów utrzymania i rozwoju aplikacji. Z czasem kompetencje, znajomość narzędzi i najlepsze praktyki konfiguracji itp. są już na wysokim poziomie, pozwalając na sprawne funkcjonowanie organizacji w oparciu o usługi w chmurze.
Jeśli w tym momencie przedsiębiorstwo decyduje się przenieść swoje aplikacje do innego CSP, zespołowi IT zajmie to trochę czasu, ponadto pojawi się koszt szybkiego pozyskania know how o nowej platformie. Szkolenia i zdobycie nowych wymaganych certyfikatów zajmie sporo czasu. Ryzyko związane z kompetencjami jest czynnikiem często zaniedbywanym, ale jest równie ważne, jak inne zagrożenia i może generować spore, trudne do oszacowania koszty.
W artykule opublikowanym przez Journal of Cloud Computing autorzy zaprezentowali wyniki badania przeprowadzonego w 2016 roku wśród przedsiębiorstw w Wielkiej Brytanii, w którym badano m.in. obawy związane z vendor lock-in w kontekście dostawców chmury. Poniżej wykres pokazujący wyniki. Wśród obaw najwyżej – jako krytyczne lub średnie znaczenie – respondenci umieścili brak pełnego odstępu do danych, bezpieczeństwo (zagrożenie wyciekiem danych), dotrzymanie SLA oraz utrudniona migracja danych i aplikacji pomiędzy platformami.
Zredukuj ryzyka w pięciu krokach
Powyższa charakterystyka rodzajów ryzyka może brzmieć złowieszczo i zniechęcać do migracji do chmury w ogóle. Jednak ryzyko ma to do siebie, że choć nie zawsze da się wyeliminować to da się nim zarządzać. Poniżej znajdziemy kilka propozycji co można zrobić na poszczególnych etapach migracji do chmury, aby ryzyko zredukować bądź się przed nim zabezpieczyć.
1. Poznaj swojego dostawcę
Dogłębne zrozumienie oferty, technologii oraz warunków udostępniania usług przez potencjalnego CSP ma kluczowe znaczenie dla ograniczenia ryzyka uzależnienia od dostawcy. Nie chodzi tutaj o proste porównanie ofert. Due dilligence dostawcy powinno być wpisane w proces przygotowania do migracji. W tym celu firma powinna:
- określić swoje cele migracji do chmury (strategiczne, zakres migracji, czy aplikacje krytyczne dla biznesu, czy celem jest wzrost efektywności działania czy reedukacja kosztów itd.),
- ocenić aktualną sytuację własnej infrastruktury IT, w tym dokładny audyt bieżącej infrastruktury oraz poziomy kosztów i aktywów licencyjnych, amortyzacji, kompetencje zespołu,
- dokonać wyboru docelowego środowiska chmury – publiczna, prywatna czy hybrydowa,
- określić niezbędne komponenty chmury,
- dokonać wyboru odpowiedniego dostawcy chmury z uwzględnieniem sytuacji przedsiębiorstwa nakreślonej w poprzednich krokach.
Na tym etapie zespół planujący migrację w firmie powinien rozważyć jak najwięcej ofert CSP, nie ograniczając się do wielkiej trójki – twierdzi Marcin Zmaczyński. – Musi sprawdzić, czy odpowiadają one zdefiniowanym potrzebom, jak i ograniczeniom np. co do lokalizacji baz danych. Warto przyjrzeć się również różnym modelom cenowym, aby określić możliwe do osiągnięcia oszczędności, także wynikające z nich potencjalne koszty na przykład w związku ze zwiększonym zapotrzebowaniem na zasoby. Istotnie jest także gruntowne przeanalizowanie umów SLA pod kątem tego, co gwarantują. Wreszcie trzeba wziąć pod uwagę kwestie związane z ewentualną migracją ze środowiska, takie jak kompatybilność i ewentualne koszty. Warto też zapoznać się z case study klientów o podobnym profilu, którzy korzystają już z usług dostawcy.
2. Zaplanuj wyjście z chmury
Strategia wyjścia z chmury?! Tak, większość menedżerów reaguje na to pytanie ze szczerym zdziwieniem. Ale dojrzałe podejście do przeniesienia swoich strategicznych operacji IT pod skrzydła dostawcy usług w chmurze musi zakładać plan awaryjny, kiedy konieczna będzie – czasami w bardzo rygorystycznych ramach czasowych – zmiana dostawcy usług lub, co też się zdarza, powrót do własnego środowiska on-premise lub kolokacji. Jest to punkt, który powinien uwzględniać ochronę strategicznych zasobów firmy oraz zachowanie ciągłości działania.
Podczas planowania strategii wdrożenia należy uwzględnić plan wyjścia i potencjalne koszty jednak zaleca się planować w horyzoncie nie dalszym niż 5-7 lat. Dłuższy horyzont może to utrudnić elastyczność migracji do innego CSP w razie potrzeby.
3. Stosuj standardy dla aplikacji i danych
Jeśli chodzi o budowę czy migrację aplikacji to należy skoncentrować się na zapewnieniu elastycznej architektury i luźnym powiązaniu komponentów (loosely coupled, decoupling) co wspiera np. architektura mikrousług (microservices). Ponadto każda logika biznesowa powinna być nie tylko oddzielona od logiki aplikacji, ale powinna być przejrzyście zdefiniowana i udokumentowana, ułatwi to stosowanie reguł biznesowych w przypadku migracji do nowego CSP. Takie podejście nie tylko zabezpiecza na ewentualną koniczności zmiany CSP obniżając koszty ewentualnej przebudowy aplikacji, ale także zapewnia interoperacyjność aplikacji, która jest wymagana do szybkiej migracji między środowiskami różnych dostawców w modelu multicloud.
Stosowanie standardów i otwartych modeli danych jest również kluczowe dla zapewnienia przenośności danych pomiędzy dostawcami. Zależność od dostawcy w obszarze dostępu do danych czy wręcz „uwięzienie” danych jest prawdopodobnie najtrudniejszym ryzykiem do złagodzenia i znajduje to odzwierciedlenie w obawach przedsiębiorstw wyrażonych we wspomnianych wyżej badaniach.
Przede wszystkim należy upewnić się, że dostawca usług w chmurze zapewnia nie tylko łatwy i tani transfer danych DO chmury, ale również bezproblemowy i ekonomicznie akceptowalny transfer danych Z chmury. Aby ułatwić transfer pomiędzy dostawcami powstały inicjatywy, które zajmują się standaryzacją w tym zakresie, jak Open Data Element Framework czy Cloud Data Management Interface jednak jak do tej pory wypracowane standardy nie zawsze są zrozumiałe i akceptowane w branży.
4. Wykorzystuj potencjał wielu dostawców (muticloud)
Może to być opłacalna opcja łagodzenia ryzyka vendor lock-in, która ma tą dodatkową zaletę, że pozwala wykorzystać różnych dostawców do różnych potrzeb, związanych z analityką danych, backupem czy przetwarzaniem danych wrażliwych.
Oczywiście podejście oparte na wykorzystaniu wielu platform chmurowych ma też i wady, jak zwiększone zapotrzebowanie na kompetencje różnych dostawców, większe obciążenie zespołu IT czy też większa ekspozycja na zagrożenia. Więcej o zaletach i wadach środowisk multicloud można znaleźć tutaj.
Zdaniem Marcina Zmaczyńskiego multicloud pozwala klientowi mieć pewność, że w przypadku nieprzewidzianej utraty dostępu do danych zawsze może liczyć na drugie środowisko. – Nie zawsze konieczne jest utrzymywanie całej zduplikowanej infrastruktury w drugiej chmurze, może to na przykład być tylko usługa backupu. Przy wyborze dostawcy, czy to pierwszego czy alternatywnego, szczególną uwagę należy zwrócić na to, jakie procedury pod względem danych stosuje. Aruba Cloud jest zrzeszona w ramach CISPE, europejskiej organizacji dostawców usług chmurowych, której członkowie zobowiązują się gwarantować klientowi pełne prawo dostępu do danych, nienależnie od okoliczności. Centra danych, z których korzystają firmy należące do CISPE spełniają także najwyższe normy pod względem ochrony danych jak zgodności z RODO – konkluduje szef marketingu CEE Aruba Cloud.
5. Zaplanuj wdrożenie procesów DevOps / DevSecOps
Procesy i narzędzia DevOps są w środowiskach chmurowych coraz częściej wdrażane w celu zapewnienia przenośności kodu. Technologie takie jak kontenery czy narzędzia automatyzacji zarządzania infrastrukturą są obecnie na fali wznoszącej zastosowań. Kubernetes czy Docker pozwalają izolować oprogramowanie od jego środowiska uruchomienia i uniezależnić od dostawcy chmury. A ponieważ większość CSP obsługuje standardy kontenerów, w razie potrzeby można przenieść aplikację na inną platformę.
Ponadto narzędzia do zarządzania konfiguracją, takie jak Terraform, Ansible, Chef, Puppet, Saltstack pomagają zautomatyzować konfigurację infrastruktury, w której mają działać aplikacje. Pozwala to na redukcję czasu i kosztów osobowych nie tylko podczas migracji, ale również w codziennym zarządzaniu infrastrukturą.
– Chociaż vendor lock-in w przypadku migracji do chmury jednego CSP budzi uzasadnioną obawę, to jednak korzyści z wykorzystania chmury przewyższają ryzyko. Dla biznesu oznacza to koncentrację na wartości dla klienta, szybszym dostarczaniu i budowie bardziej elastycznych aplikacji, a ryzyka związane z uzależnieniem od dostawcy można redukować podejmując odpowiednie działania podczas migracji. Po stronie dostawców leży jednak obowiązek proponowania oferty odpowiadającej na obawy jak najbardziej dla nich korzystnej – podsumowuje Marcin Zmaczyński.
