Czas do wygaśnięcia licencji VMware warto wykorzystać na poszukiwanie alternatyw

Z Sebastianem Szewczykiem, Senior Solution Architect i Rafałem Rasińskim, Senior Solution Architect w firmie Averbit rozmawiam o:

• znaczeniu wirtualizacji w dzisiejszych środowiskach IT,
• praktycznych skutkach przejęcia VMware przez koncern Broadcom,
• potrzebie dywersyfikacji i modernizacji istniejących środowisk oraz niezbędnych do tego przygotowaniach,
• możliwościach rozwiązań, takich jak Red Hat OpenShift Virtualization oraz Red Hat Ansible Automation Platform.

Pierwsza platforma wirtualizacyjna – WMware Workstation – ma już ponad ćwierć wieku. Dlaczego wirtualizacja nadal ma tak szerokie zastosowanie?

Sebastian Szewczyk (S.Sz.): Wirtualizacja jest dziś praktycznie wszędzie – zarówno w małych, jak i bardzo dużych organizacjach. Jej podstawową zaletą pozostaje konsolidacja zasobów. Zamiast utrzymywać osobne serwery fizyczne dla kolejnych aplikacji, możemy wykorzystać je w bardziej efektywny sposób, uruchamiając na nich wiele maszyn wirtualnych jednocześnie.

W praktyce oznacza to lepszą utylizację infrastruktury, niższe koszty oraz większą elastyczność. Ważny jest również time to market. Postawienie serwera fizycznego wymaga zakupu sprzętu, jego dostawy, instalacji, okablowania i konfiguracji. Maszynę wirtualną można przygotować znacznie szybciej, zwłaszcza gdy proces jest zautomatyzowany.

Rafał Rasiński (R.R.): Wirtualizacja przyniosła przede wszystkim konsolidację i optymalizację kosztów. Trzeba jednak pamiętać, że stworzyła też dodatkową warstwę technologii, którą należy rozumieć i umieć nią zarządzać. W tym sensie wymusiła rozwój kompetencji IT. Dzisiaj obserwujemy kolejny etap tej zmiany: coraz większą rolę odgrywają konteneryzacja i automatyzacja. Nie oznacza to jednak końca wirtualizacji, a raczej rozszerzenie zestawu narzędzi dostępnych dla zespołów IT.

Niebawem miną 3 lata, odkąd firma VMware stała się własnością koncernu Broadcom. W jaki sposób ta transakcja zmieniła realia związane z wykorzystaniem technologii VMware?

R.R: Najbardziej odczuwalna dla klientów jest zmiana modelu licencyjnego i subskrypcyjnego. Wiele organizacji korzystało z ograniczonego zakresu funkcji VMware, a obecnie musi rozważać ofertę obejmującą szersze pakiety, których potencjału niekoniecznie potrzebuje.

Duże przedsiębiorstwa często nadal pozostają przy rozwiązaniach VMware. Takie organizacje mają zwykle bardzo rozbudowane i współzależne środowiska, w których zmiana tak istotnego elementu jak platforma wirtualizacyjna jest po prostu bardzo trudna. Poza tym, duże firmy często dysponują możliwościami kompetencyjnymi i budżetowymi, aby pozostać przy technologiach tego producenta. Oczywiście zazwyczaj odczuwają również presję kosztową i potrzebę dywersyfikacji rozwiązań wirtualizacyjnych.

Natomiast dla firm ze średniego segmentu rynku nowe zasady licencjonowania technologii VMware stały się
zdecydowanie bardziej problematyczne, zwłaszcza gdy koszt licencji okazuje się nieproporcjonalny do realnych potrzeb.

S.Sz.: Broadcom podszedł do sprawy w sposób biznesowy i skoncentrował się na największych klientach. Nie ma w tym nic zaskakującego, ale dla wielu mniejszych i średnich organizacji zmiany w licencjonowaniu technologii VMware oznaczają konieczność rozglądania się za alternatywami. Działania nowego właściciela VMware dobitnie pokazały też jak istotna dla dojrzałych środowisk IT jest dywersyfikacja technologiczna.

Największą barierą na drodze do takiej dywersyfikacji nie jest jednak sama cena. Często chodzi o czas, skalę ewentualnej migracji na inny wirtualizator oraz kompetencje. Jeśli duży bank albo przedsiębiorstwo posiada środowisko mocno osadzone na rozwiązaniach VMware, to taka migracja nie przypomina prostej, ale wymagającej zmiany przyzwyczajeń. To wieloletni projekt, na który składają się m.in. zmiany w architekturze środowiska, aplikacjach, procesach operacyjnych, licencjach oraz kompetencjach zespołu.

Jak dobrze przygotować się do zmiany platformy wirtualizacyjnej?

S.Sz.: Nie namawiamy klientów do gwałtownego porzucenia dotychczasowej platformy. Warto uruchomić małe środowisko testowe – sandbox, zrealizować projekt pilotażowy albo Proof of Concept i sprawdzić, jak alternatywne rozwiązanie działa w konkretnym środowisku. Najważniejsze jest jednak to, aby nie odkładać takiej analizy do momentu, gdy organizacji kończy się posiadana subskrypcja dotychczasowej platformy albo, co gorsza, następuje nagły wzrost kosztów. Organizacja, która ma dwa czy trzy lata na przygotowanie, powinna wykorzystać ten czas na budowanie kompetencji, testowanie migracji i identyfikowanie obciążeń, które w pierwszej kolejności można przenieść do alternatywnej platformy wirtualizacyjnej.

Przykładowo, niektóre aplikacje linuksowe i klastry Kubernetes mogą zostać przeniesione na platformę opartą na OpenShift Virtualization, podczas gdy systemy Windows lub aplikacje o specyficznych wymaganiach licencyjnych mogą pozostać na dotychczasowej platformie. Nie chodzi o migrację dla samej migracji, lecz o świadome obniżanie ryzyka i kosztów.

R.R.: Zmiana platformy wymaga również zmiany podejścia do obsługi i utrzymania infrastruktury. OpenShift Virtualization i VMware nie są rozwiązaniami identycznymi, więc nie można oczekiwać migracji jeden do jednego bez dostosowania procesów operacyjnych czy zmian w samych maszynach wirtualnych. Istnieją oczywiście narzędzia ułatwiające i automatyzujące m.in. przenoszenie maszyn wirtualnych z platformy VMware do OpenShift, ale takie projekty nie dotyczą jedynie kwestii technicznych.

W praktyce projekty migracyjne łączą świat infrastruktury i aplikacji. W wielu firmach są to nadal dwa silnie rozdzielone obszary. Dlatego modernizacja warstwy wirtualizacyjnej wymaga współpracy administratorów, zespołów aplikacyjnych, architektów i bezpieczeństwa. To z kolei wiąże się z przygotowaniem organizacyjnym i technologicznym.

Wspomnieliście też o konteneryzacji. Czym kontenery różnią się od maszyn wirtualnych?

R.R.: Najważniejsza różnica dotyczy modelu działania. Maszyna wirtualna odwzorowuje kompletne środowisko: ma własny system operacyjny, zasoby i pełny stos potrzebny do działania aplikacji. Kontener jest lżejszy – opakowuje aplikację wraz z jej zależnościami, ale współdzieli część warstwy systemowej z hostem. Oznacza to szybsze uruchamianie, lepszą gęstość wykorzystania zasobów oraz łatwiejsze skalowanie aplikacji niż w przypadku wirtualizacji. Wszystko to sprawia, że kontenery dobrze sprawdzają się tam, gdzie liczą się dynamika, szybkie dostarczanie zmian i powtarzalność środowisk.

S.Sz.: W modelu kontenerowym można przygotować lekkie obrazy aplikacji z właściwymi elementami środowiska aplikacyjnego oraz zależnościami i uruchamiać je w obrębie wspólnego klastra. Pod względem efektywności wykorzystania zasobów jest to przepaść w porównaniu z wirtualizacją, nie wspominając nawet o podejściu bare metal. W tym ujęciu konteneryzacja stanowi więc kolejny poziom konsolidacji infrastruktury IT – szczególnie wartościowy tam, gdzie mamy szybki wzrost ilości wdrażanych aplikacji.

Konteneryzacja wymaga jednak dojrzałości. Początkowy próg wejścia może być wysoki, ale dobrze przygotowane mechanizmy CI/CD, wykorzystanie koncepcji Infrastructure as Code i automatyzacja znacząco upraszczają późniejsze wdrażanie oraz utrzymanie aplikacji.

Czy w praktyce model kontenerowy może stać się alternatywą dla wirtualizacji?

R.R.: Nie. Kontenery nie są rozwiązaniem idealnym dla każdego systemu i każdego typu danych. Ich podstawowym założeniem jest możliwie bezstanowy charakter. Dane trwałe powinny być utrzymywane poza kontenerem – w bazie danych, systemie storage’owym lub wyspecjalizowanej usłudze. Chodzi o to, aby kontener był skalowalny, łatwy do wygaszenia i uruchomienia.

Rozważania dotyczące ewentualnego przeniesienia obciążeń ze środowisk zwirtualizowanych do modelu kontenerowego wymaga odpowiedzi na wiele pytań. Jedno z najistotniejszych dotyczy charakteru wykonywanych przez aplikację operacji na danych, a więc tego, jak dana aplikacja korzysta z danych, gdzie utrzymuje stan i czy jej architektura pozwala na taki model działania zgodny z istotą kontenerów. W części przypadków lepszym rozwiązaniem będą maszyna wirtualna, środowisko fizyczne albo inny model wdrożenia aplikacji.

S.Sz: Próba przeniesienia wszystkiego do kontenerów jest błędem. Konteneryzacja powinna być świadomym
wyborem architektonicznym, a nie celem samym w sobie. W każdej organizacji znajdą się systemy legacy, aplikacje o krytycznym znaczeniu albo rozwiązania, których przebudowa byłaby nieopłacalna. Najlepszy model to często hybryda: wirtualizacja dla części obciążeń, kontenery dla aplikacji rozwijanych dynamicznie, wyspecjalizowane systemy dla danych oraz automatyzacja, która spina te elementy. Liczy się dopasowanie technologii do konkretnego przypadku biznesowego, technicznego i licencyjnego.

Kiedy warto rozpocząć modernizację środowisk zwirtualizowanych?

S.Sz.: Idealny moment jest wtedy, gdy organizacja zaczyna dostrzegać ograniczenia obecnego modelu: rosnące koszty, zbyt długi czas dostarczania zmian, trudności ze skalowaniem albo brak elastyczności w rozwoju aplikacji. Nie należy czekać na kryzys.

Trzeba też pamiętać, że projekty tego typu nie należą do łatwych. Dobry projekt zaczyna się od poznania środowiska i potrzeb klienta. Następnie warto zrealizować analizę, projekt Proof of Concept oparty na konkretnych scenariuszach biznesowych. Dopiero po jego zakończeniu można przygotować architekturę docelową, sizing oraz analizę finansową. W praktyce dobrze przygotowany PoC odpowiada na istotną część potrzeb firmy, pozwala zespołowi dotknąć technologii i zmniejsza ryzyko podjęcia błędnej decyzji. Pozwala też sprawdzić, jak platforma zachowuje się w rzeczywistych warunkach.

W jaki sposób zespół firmy Averbit wspiera klientów w takich projektach?

S.Sz.: Pomagamy klientom sprawnie przejść przez niezbędne zmiany. Nie tylko zapewniamy potrzebne rozwiązania, ale też podpowiadamy, w jaki sposób optymalizować i przebudowywać środowiska wirtualne tak, aby były nie tylko efektywne technicznie i operacyjnie, lecz także opłacalne kosztowo.

To ważne, bo modernizacja środowisk IT – zwłaszcza tych mocno eksploatujących technologie VMware – obejmuje nie tylko kwestie dotyczące wyboru lub integracji tej czy innej technologii. Najczęściej są to również decyzje biznesowe i procesowe, dotyczące choćby sposobu tworzenia i wdrażania aplikacji. W praktyce, projekty takie są też mocno powiązane z modelem chmury obliczeniowej – lokalnej, publicznej lub hybrydowej. Mamy w tym zakresie wiele doświadczeń, zarówno jako firma Averbit, jak i osobiście, jako zespół inżynierów.

R.R.: Często trafiamy do firm, w których pewne decyzje architektoniczne już zapadły, a środowisko zostało częściowo zbudowane. Wtedy naszym zadaniem jest ocena, czy takie rozwiązanie można zoptymalizować, przeprojektować lub rozbudować zgodnie z dobrymi praktykami. Oznacza to, że im wcześniej organizacja rozpocznie rozmowę o architekturze i modelu operacyjnym, tym większa jest szansa na ograniczenie późniejszych kosztów i wyeliminowanie długu technologicznego.

Firma Averbit od nieco ponad roku posiada najwyższy status partnerstwa z Red Hat. Co w praktyce oznacza status Red Hat Premier Business Partner?

S.Sz.: Przede wszystkim jest to status potwierdzający kompetencje i doświadczenie zespołu partnera firmy Red Hat. Tytułu Red Hat Premier Business Partner nie da się uzyskać wyłącznie na podstawie deklaracji lub wyników biznesowych. Partner o tak wysokim statusie musi dysponować odpowiednio certyfikowanymi inżynierami, realizować projekty, prowadzić działania sprzedażowe i techniczne oraz wykazywać aktywność w pracy z klientami. Kluczowe znaczenie mają tu jednak kompetencje techniczne.

R.R.: Dla klienta oznacza to możliwość pracy z partnerem, który potrafi przejść od analizy potrzeb, przez Proof of Concept i architekturę, aż po wdrożenie oraz rozwój rozwiązania. Status partnerski ma wartość wtedy, gdy stoi za nim realne doświadczenie projektowe.

S.Sz.: Oczywiście bardzo się cieszymy z takiego wyróżnienia. Dziękujemy też pozostałym członkom zespołu Averbit, bo bez ich zaangażowania nie moglibyśmy tak sprawnie dołączyć do grona najlepszych partnerów Red Hat. Poziom naszego partnerstwa z firmą Red Hat pokazuje też jak dobrze funkcjonuje nasza organizacja. Mimo stosunkowo niedużej liczebności mamy bardzo dobrą skuteczność.

Istotnym elementem oferty Red Hat jest również platforma Ansible. W jaki sposób to rozwiązanie zmienia charakter codziennej pracy w IT?

R.R.: Red Hat Ansible Automation Platform, bo taka jest pełna nazwa tego rozwiązania, to najpopularniejsze obecnie narzędzie do automatyzacji i zarządzania konfiguracją szeroko rozumianej infrastruktury IT. Tak naprawdę jest to dziś światowy standard. Bardzo dużo firm automatyzuje obsługę swoich produktów właśnie w ramach narzędzia Ansible. Co więcej, dedykowane dla tej platformy wtyczki oferują dziś praktycznie wszyscy wiodący dostawcy sprzętu i oprogramowania. Widoczna jest tu także idea open source, która wspiera dzielenie się oraz rozwój playbooków i integracji. To naprawdę ułatwia i przyspiesza pracę zespołów IT. Na tym nie koniec. Platforma Ansible może być z powodzeniem wykorzystana też pod kątem obsługi powtarzalnych operacji wymaganych przez regulacje, takie jak NIS2 czy DORA.

S.Sz.: Automatyzacja pozwala skrócić czas realizacji powtarzalnych zadań z dni do godzin. Ansible sprawdzi się m.in. w organizacjach, w których potrzebne są cykliczne zmiany konfiguracji infrastruktury, uruchamiania nowych serwerów, tworzenia maszyn wirtualnych czy aktualizacji wielu urządzeń. Dobrze przygotowane playbooki Ansible mogą wykonać te czynności powtarzalnie i zgodnie z ustalonym standardem.

Czy zautomatyzowanie procesów z obszaru IT przekłada się na nowe możliwości biznesowe?

S.Sz.: Oczywiście! Przykładowo, kompleksowe wdrożenie zwirtualizowanej infrastruktury w nowej lokalizacji – biurze czy sklepie – może potrwać nawet kilka dni. Odpowiednio przygotowana automatyzacja pozwala wykonać ten proces znacznie szybciej, bo w ciągu godzin. To zaś oznacza konkretne korzyści biznesowe, lepsze wykorzystanie zasobów, szybszy Time-To-Market, a także większą elastyczność procesów. To samo dotyczy również działań związanych z bezpieczeństwem czy zapewnieniem zgodności regulacyjnej – tym bardziej że automatyzacja może być uruchamiana w odpowiedzi na konkretne zdarzenia. Oczywiście wymaga to początkowego nakładu pracy, ale później przynosi wymierne korzyści.

R.R.: Ansible jest narzędziem do automatyzacji i zarządzania konfiguracją. Szczególnie dobrze sprawdza się w zadaniach wykonywanych cyklicznie: zarządzaniu aktualizacjami, konfiguracją serwerów, środowiskami wirtualnymi, urządzeniami sieciowymi czy procesami bezpieczeństwa. W praktyce automatyzacja nie eliminuje potrzeby zatrudniania administratorów i inżynierów. Przenosi ich pracę z ręcznego wykonywania powtarzalnych czynności na projektowanie procesów, rozwój platform oraz rozwiązywanie problemów o większej wartości dla biznesu.

Automatyzacja może być zaś pierwszym krokiem do modernizacji środowisk wirtualnych – pozwala uporządkować środowisko, zmniejszyć liczbę błędów ręcznych i odzyskać czas zespołów technicznych, a może być wdrożona w sposób niewymagający rezygnacji z obecnej platformy wirtualizacyjnej. Jest to zatem świetny punkt wyjścia do stopniowej modernizacji środowiska i dywersyfikacji technologii poprzez stopniowe wdrażanie kolejnych rozwiązań z portfolio firmy Red Hat.