Uzależnienie od dostawcy (vendor lock-in), to pojęcie nad wyraz często łączone z branżą IT, a w ostatnich latach szczególnie z chmurą obliczeniową, chociaż zdecydowanie nie jest z nimi nierozerwalnie związane. Przez ekonomistów rozpatrywane było w szerszym kontekście na długo przed tym, kiedy świat po raz pierwszy usłyszał o AWS czy Azure. Z perspektywy klienta oraz użytkownika, zazwyczaj bywa postrzegane w negatywnym świetle, niejednokrotnie wywołując niechęć i strach przed skorzystaniem z danej usługi lub produktu.
Na pierwszy rzut oka wydaje się, że w obszarze chmury publicznej problem nie jest błahy. Nawet główni beneficjenci zjawiska, czyli najwięksi dostawcy usług chmurowych, zdecydowali się poruszyć to zagadnienie na swoich oficjalnych stronach internetowych, więc najwyraźniej coś musi być na rzeczy…
A czy faktycznie jest, sprawdzimy w tym artykule. Przyjrzymy się ryzykom, jakie niesie za sobą vendor lock-in dla organizacji planujących adopcję chmury. Zastanowimy się również, czy skorzystanie z usług kilku dostawców (multi-cloud) jednocześnie może być dobrą receptą na poprawę sytuacji. Ponadto, weźmiemy pod lupę chmurę hybrydową.
Migracja do chmury i wybór dostawcy
Rozważmy pokrótce przykładowy scenariusz migracji lokalnej infrastruktury IT pewnego przedsiębiorstwa do chmury. Pierwszy etap prac obejmuje różnego rodzaju analizy oraz planowanie. Ustalane są wymagania biznesowe i technologiczne, a także oczekiwane rezultaty całego przedsięwzięcia (KPI). Przeglądane są wszystkie wykorzystywane w organizacji systemy informatyczne oraz powiązane z nimi zasoby sprzętowe, po czym stopniowo budowana jest optymalna strategia przeniesienia ich w nowe miejsce.
Zespół rozpatruje oferty różnych dostawców usług chmurowych, z uwzględnieniem takich czynników jak:
- szacunkowe koszty,
- niezawodność działania,
- poziom bezpieczeństwa,
- jakość wsparcia technicznego.
Brana jest również pod uwagę dostępność na rynku specjalistów z odpowiednimi umiejętnościami i doświadczeniem w pracy z daną platformą chmurową, bez których powodzenie całej migracji byłoby poważnie zagrożone, a wręcz niemożliwe.
Gdy zapada ostateczna decyzja o wyborze dostawcy, rozpoczyna się ściśle techniczna część procesu. Powstaje szczegółowy projekt architektury. Do pracy wkraczają programiści i administratorzy, a później również testerzy. Wreszcie, po wielu tygodniach bądź miesiącach pracy (w zależności od skali przedsięwzięcia), wszystkie przeznaczone do przeniesienia aplikacje oraz dane znajdują się w nowym miejscu, w chmurze. Uprzednio zdefiniowane cele zostają osiągnięte i firma zaczyna czerpać korzyści z migracji do chmury.
Mija kilka lat. W związku z rozwojem firmy, zarząd podejmuje decyzję o rozszerzeniu oferty oraz wejściu na nowe rynki. Pociąga to za sobą konieczność dodania nowych komponentów do istniejących systemów informatycznych. Niezbędne staje się rozbudowanie stworzonej wcześniej infrastruktury w chmurze.
Ponownie rozpoczyna się analiza aktualnej sytuacji na rynku chmury obliczeniowej. W jej toku okazuje się, że oferta konkurencyjnego dostawcy usług chmurowych lepiej odpowiada potrzebom firmy niż oferta aktualnego dostawcy. Wyróżnia się ona korzystniejszym modelem cenowym, a ponadto jest bardziej innowacyjna technologicznie, pozwalając osiągnąć założony cel mniejszym nakładem pracy. Rozważana jest zatem możliwość przeprowadzenia migracji do innej chmury. Jednak wkrótce staje się jasne, że szacunkowe koszty takiej operacji dość istotnie przewyższają potencjalne zyski…
Przyczyny i symptomy vendor lock-in
I oto następuje zderzenie z vendor lock-in, w pełnej okazałości. Jak tłumaczy podręcznikowa definicja tego zjawiska, klient staje się wtedy zależny od danego produktu, usługi lub technologii do tego stopnia, że skorzystanie z dostępnych na rynku alternatyw jest utrudnione. W opisywanej sytuacji, firma jest zależna od wybranej platformy chmurowej, ponieważ bez niej nie mogłyby działać systemy informatyczne, niezbędne do prawidłowego funkcjonowania całego przedsiębiorstwa.
Dlaczego jednak przeniesienie systemów, infrastruktury oraz danych do konkurencyjnej chmury może być trudne?
Sedno problemu tkwi na poziomie technicznym. Może się wydawać, że aplikacje napisane choćby w Javie czy Pythonie da się uruchomić w wielu różnych środowiskach bez konieczności wprowadzania większych zmian w kodzie. Takie przypuszczenie często jest zgodne z prawdą, jednak trudności pojawiają się w sytuacji, kiedy aplikacje te korzystają z natywnych komponentów wybranej platformy chmurowej, niedostępnych nigdzie poza nią.
Jako przykład takiego komponentu można przytoczyć Amazon EventBridge, czyli usługę dostępną wyłącznie w ramach chmury Amazon Web Services, często stanowiącą rdzeń aplikacji w architekturze sterowanej zdarzeniami. Choć alternatywne chmury również posiadają w swojej ofercie usługi o podobnym przeznaczeniu, to różnice pomiędzy udostępnianymi przez nie interfejsami są znaczne i uniemożliwiają łatwe zastąpienie EventBridge inną, konkurencyjną usługą. Innymi słowy, fragmenty kodu aplikacji odpowiedzialne za komunikację z Amazon EventBridge nie będą współpracować z Azure Event Grid czy Google Cloud Eventarc, i vice versa.
Jednak co w sytuacji, gdy firma posiada system informatyczny działający w chmurze, który nie korzysta z jej natywnych komponentów?
Przykładowo, może się on składać z kilku podsieci, kilkunastu maszyn wirtualnych z systemem operacyjnym Linux, klastra bazodanowego PostgreSQL, load balancera oraz jeszcze kilku pomniejszych elementów. Całość jest oparta o standardowe technologie i protokoły komunikacyjne, znane w branży na długo przed nadejściem ery cloud. Czy migracja tak skonstruowanej infrastruktury może być równie problematycznym przedsięwzięciem?
Niestety, często tak właśnie będzie, pomimo faktu, że wyżej wymienione rodzaje zasobów są dostępne we wszystkich popularnych chmurach. Ponownie ujawniają się tutaj istotne różnice pomiędzy interfejsami poszczególnych dostawców. Choć zwykła maszyna wirtualna jest zasobem o identycznym przeznaczeniu zarówno w AWS, jak i w Azure, to jednak sposób jej tworzenia i konfiguracji (na poziomie infrastruktury, nie systemu operacyjnego) będzie inny.
Różnice i niezgodności pomiędzy platformami mogą dotyczyć wielu technicznych niuansów, a już nawet dwa wyżej przytoczone implikują istotne trudności w migracji do innej chmury. Taka operacja oczywiście jest możliwa, jednak poziom jej złożoności i czasochłonność często są wysokie i generują niemałe koszty.
Do tego dochodzi aspekt kadrowy, gdyż obecny zespół może nie posiadać wystarczającego doświadczenia w pracy z nową chmurą. Z punktu widzenia osób decyzyjnych w przedsiębiorstwie, można wskazać wiele powodów do porzucenia planów takiej migracji. Rozbudowanie istniejącego systemu informatycznego w ramach dotychczas używanej chmury może się ostatecznie okazać korzystniejszym rozwiązaniem. Jednak czy na pewno nie istnieją jeszcze inne opcje?
Multi-cloud. Co dwie chmury to nie jedna?
Dotychczas zakładaliśmy, że w opisywanej sytuacji istnieją tylko dwie możliwości:
- kontynuacja współpracy z aktualnym dostawcą usług chmurowych,
- kompletna migracja całości systemu, wraz z infrastrukturą i danymi, do innego dostawcy.
Tymczasem w toku rozważań może nasunąć się słuszne pytanie o możliwość połączenia obu tych wariantów, tak aby w jak największym stopniu wykorzystać zalety innej chmury, ale jednocześnie uniknąć rozstania z tą obecnie używaną. Zatem czy nie dałoby się wybrać pewnych elementów z różnych chmur i połączyć ich ze sobą w jeden spójny, dobrze działający system? Okazuje się, że w wielu przypadkach jest to osiągalne.
Takie podejście nosi nazwę multi-cloud.
Część źródeł, w tym firma Oracle podaje, że w wybranych regionach świata ponad 90% dużych przedsiębiorstw korzysta lub planuje skorzystać z oferty więcej niż jednego dostawcy usług chmurowych jednocześnie. Bez trudu da się znaleźć firmy, które używają trzech, czterech, a nawet jeszcze większej liczby chmur. Górne ograniczenie właściwie w tym przypadku nie istnieje.
Strategia multi-cloud nie jest zatem żadnym ekwilibrystycznym, niepewnym eksperymentem, tylko sprawdzonym rozwiązaniem, przynoszącym organizacjom liczne korzyści. Pozwala osiągnąć dywersyfikację i uniezależnić się od jednego dostawcy. Można tu wskazać pewną analogię do dobrze zdywersyfikowanego portfela inwestycyjnego, który ogranicza ryzyko związane ze spadkiem wartości jednego lub kilku aktywów składowych. Podobnie, przemyślane rozdystrybuowanie komponentów systemu pomiędzy różne platformy chmurowe zmniejsza ryzyko związane z czasową bądź trwałą niedostępnością jednej z tych platform. Nie można zapomnieć, że awarie oraz rozmaite problemy techniczne niestety są nieuniknione również w świecie chmury, a rolą użytkownika i dobrą praktyką jest zaprojektowanie infrastruktury w taki sposób, aby była jak najbardziej odporna na tego typu zdarzenia.
Powróćmy do rozważanego wcześniej przykładu. Wydaje się, że w przedstawionym scenariuszu użycie podejścia multi-cloud byłoby optymalnym rozwiązaniem. Pozwoliłoby rozbudować istniejący system informatyczny bez konieczności całkowitej migracji do innej chmury. Nowe komponenty, które muszą zostać dodane, korzystałyby z bardziej zaawansowanych technologicznie, a jednocześnie korzystniejszych cenowo usług dostępnych u nowego dostawcy.
Firma zyskałaby zatem:
- większe możliwości optymalizacji kosztów;
- wyższą niezawodność pracy systemu;
- technologię dopasowaną do realizowanego projektu oraz wymagań;
- uniezależnienie od jednego dostawcy (uniknięcie zjawiska vendor lock-in).
Czy strategia multi-cloud to magiczne remedium na problemy z adopcją chmury?
Niestety, nie zawsze. Choć posiada szereg zalet, to wiążą się z nią również określone wyzwania, o których należy pamiętać. Przede wszystkim, w środowisku wielochmurowym złożoność wdrożeń jest większa niż w przypadku pojedynczej chmury. Usługi dostępne w obrębie konkretnej platformy zwykle da się zintegrować ze sobą w prosty sposób, ponieważ zadbał o to dostawca. Można powiedzieć, że pasują do siebie niczym klocki w układance, razem tworząc spójną całość. Dane zazwyczaj przesyłane są za pośrednictwem wewnętrznej sieci dostawcy, co przekłada się na:
- wysoki poziom bezpieczeństwa,
- dużą prędkość
- oraz niskie koszty transferu.
Jednak zdecydowanie trudniejsze jest łączenie ze sobą usług z kilku różnych chmur, bowiem są one jak klocki z zupełnie innych układanek. Zapewnienie odpowiedniego poziomu bezpieczeństwa wymaga wtedy większego wysiłku, a koszty przesyłania danych rosną. Dlatego niezwykle istotne jest zaprojektowanie rozszerzalnej architektury i wykorzystanie odpowiednich wzorców integracyjnych. Dzięki temu stosunkowo proste stanie się dodawanie do systemu nowych komponentów działających w niemal dowolnej chmurze, które będą współpracować ze sobą w sposób bezpieczny i wydajny. W idealnej sytuacji powinno to być możliwe bez naruszania już istniejących obszarów infrastruktury oraz aplikacji.
A może chmura hybrydowa, a nie tylko publiczna?
Poruszając temat środowisk wielochmurowych, warto wspomnieć również o chmurze hybrydowej (hybrid cloud). Pojęcie hybrydy występuje w wielu dziedzinach życia i zwykle oznacza połączenie różnych, niepasujących do siebie elementów. W biologii oznacza osobnika powstałego w wyniku skrzyżowania dwóch różnych gatunków. W motoryzacji zwykle odnosi się do połączenia napędu spalinowego oraz elektrycznego. Natomiast w świecie chmury obliczeniowej, hybryda rozumiana jest jako połączenie dwóch rodzajów chmur – publicznej oraz prywatnej.
Chmura publiczna, jak sama nazwa wskazuje, dostępna jest dla wszystkich zainteresowanych klientów za pośrednictwem Internetu. Użytkownicy korzystają w tym przypadku z zasobów obliczeniowych, które są umieszczone w serwerowni należącej do dostawcy usług i mogą być częściowo współdzielone przez różnych klientów. To właśnie ten rodzaj chmury dotychczas brany był pod uwagę w niniejszym artykule. Przykładami największych na rynku chmur publicznych są: Amazon Web Services, Microsoft Azure oraz Google Cloud.
Jednak niektóre organizacje z rozmaitych powodów nie mogą lub nie chcą korzystać ze współdzielonych zasobów w chmurze publicznej. W odpowiedzi na ten problem powstała koncepcja chmury prywatnej, która każdorazowo wdrażana jest na potrzeby jednego klienta (a niekiedy małej grupy klientów) i dostępna wyłącznie dla niego. Zamawiający korzysta z infrastruktury obliczeniowej umieszczonej w jego własnej serwerowni lub w serwerowni zewnętrznego dostawcy, który jednak nie udostępnia tych konkretnych zasobów żadnym innym podmiotom.
Umieszczając niektóre komponenty systemu w chmurze prywatnej, a inne w jednej lub kilku chmurach publicznych, w rezultacie otrzymujemy system hybrydowy. Z takim rozwiązaniem wiążą się podobne wyzwania oraz profity jak w przypadku wcześniej opisywanej strategii multi- cloud, której częścią jest chmura hybrydowa.
Jednak w odróżnieniu od wdrożeń z wykorzystaniem samych tylko chmur publicznych, rozwiązania hybrydowe przynoszą organizacjom dodatkowe korzyści wynikające z obecności chmury prywatnej. Wśród najważniejszych można wskazać pełną kontrolę nad lokalizacją i zabezpieczeniem danych, co ma szczególne znaczenie w niektórych branżach, gdzie konieczne jest spełnienie restrykcyjnych regulacji prawnych w tym zakresie. Inną zaletą są rozbudowane możliwości dostosowania prywatnej infrastruktury do własnych potrzeb, co pozwala osiągnąć optymalną wydajność przy jednoczesnej minimalizacji kosztów.
Podsumowanie: jaką chmurę wybrać?
Decyzja o wyborze rodzaju chmury (publicznej, prywatnej czy hybrydowej) powinna zostać podjęta w wyniku szczegółowych analiz potrzeb i wymagań danej organizacji. Jeśli perspektywa uzależnienia od wybranego dostawcy wydaje się niepokojąca, warto rozważyć wariant multi-cloud, czyli wielochmurowy. Rozproszenie komponentów systemu pomiędzy różne platformy oraz – opcjonalnie – własną, lokalną serwerownię, pozwoli do pewnego stopnia ograniczyć ryzyko związane ze zjawiskiem vendor lock-in, ponieważ organizacja nie będzie polegać na usługach tylko jednego, zewnętrznego podmiotu. Warto skonsultować planowaną strategię adopcji chmury z doświadczonymi specjalistami, którzy pomogą przygotować się na możliwe konsekwencje określonych wyborów.
Z drugiej strony, trzeba mieć świadomość, że uzależnienie od jednego dostawcy (vendor lock-in) nie w każdym przypadku musi przynieść negatywne następstwa. Szczególnie małe oraz średnie firmy, które nie potrzebują rozbudowanej infrastruktury IT, są w stanie korzystać tylko z jednej chmury publicznej przez wiele lat, nie doświadczając przy tym żadnych poważniejszych problemów.
Amazon, Microsoft, Google oraz inni gracze na rynku chmury są świadomi obaw swoich klientów i wyraźnie odchodzą od praktyk mających na celu utrudnienie im migracji do innych chmur, a wręcz starają się taki proces ułatwić w razie potrzeby. A o to chociażby jeden z przykładów, w jaki sposób robi to Amazon: How the AWS Cloud helps to eliminate lock-in.
