#22 VMware Cloud on X (AWS, Azure, GCP, Ovh Cloud, Alibaba)

Myślę, że warto by było zacząć od tego, że to jest dwudziesty drugi już podcast. Ojej. No jeszcze dwa słuchaj, to tak bez przyczyny, to już troszeczkę czasu minęło. Ja nazywam się Maciej Lelusz, no i od tych 22 razy jestem szczęśliwym prowadzącym tego wykwintnego podcastu. Ze mną dzisiaj Andrzej Szymczak. W VMware będziemy sobie rozmawiać o takim produkcie, który ma wiele twarzy i o tym zaraz, a generalnie nasz tytuł podcastu jest VMware Cloud on X, czyli VMC on X. I bynajmniej proszę nie myśleć o tym jako o jakichś ciężkich firmach dorosłych. Bardziej chodzi o to, że będą to różne platformy. No i jakbyś powiedział chwilkę, Andrzeju, w ogóle co to za platformy? O co chodzi?

Ta przygoda rozpoczęła się w AWS. No i była to taka pierwsza nasza chmura. No i później pokazali się na horyzoncie też inni cloud operatorzy, ci duży tak zwani hyperscalerzy. Czyli IBM Soft Layer później doszło. Następnie weszliśmy w to rozwiązanie z Microsoft Azure, z Googlem. Więc w każdej tej chmurze, nazywa się to troszeczkę inaczej, ale jest zawsze ten sam zestaw oprogramowania, czyli Vis, Libisan i MSX. No też w Oracle można to kupić, nasze rozwiązanie. No i dodatkowo też mamy takich lokalnych cloud operatorów, czyli ty Maciek, jakbyś się chciał stać takim lokalnym cloud operatorem VMware'a, no to też możesz taką chmurkę klientom dostarczać.

Jeszcze jeden jest dostawca hyperskalerowy, który może w Polsce nie jest tak bardzo popularny, ale też warto o nim powiedzieć, to jest Alibaba. Zatem można by powiedzieć, że VMC buduje pewnego rodzaju strukturę VMware'ową poprzez różne chmury. Czyli jeżeli masz np. backend, jakieś nowe aplikacje cloud native stawiane w chmurze AWS'owej albo Azure'owej, któregokolwiek jest hyperskalera, I one działają już powiedzmy na nowe, to możesz ten zestaw VM-ek, na który twoja firma się opiera, który dotychczas był w serwerowni, w gruncie rzeczy przenieść do chmury, żeby było dość niedaleko aplikacji, które tam działają. No bo sami doskonale wiemy, że to nie jest tak, że jak robisz Cloud Migration, to i sześć tysięcy VM-ek migrujesz do chmury.

Jak tak robisz, to zazwyczaj się to kończy rozpoczęciem kariery w innej firmie. W tym roku, na początku tego roku, na przełomie lutego i kwietnia, mieliśmy taką sytuację, gdy nasz klient, akurat z Ukrainy, przeniósł do naszej chmury w AWS ponad 5000 maszyn wirtualnych. Ale na VMC właśnie. Nie zrobił czegoś takiego, że konwertował tego do EC2 i później próbował Doznać objawienia cloudowego, które w jego przypadku mogłyby być ostateczne. Właśnie dlatego mówię, to taka ciekawa forma onboardingu na rozwiązanie cloudowe, rozwiązań typowo VM-kowych, które lepiej lub gorzej się konwertują do rozwiązań cloud native, a czasami w ogóle ich nie da się zrobić.

Weźmy sobie jakiś soft na Delphi. Jeszcze myślę, że warto powiedzieć o danych, tak, no bo same wirtualne maszyny, czy też Kubernetes po stronie Cloud Operatora, to niektórzy mi mówią, no tak, ale możemy sobie postawić u dowolnego dostawcy, wybrać właśnie to, co mówisz, EC2, czy jakąś inną formę, wirtualną maszynę i zrobić tam jakiś automat, który będzie coś tam instalował na tej wirtualnej maszynie. No i może to instalować na tej dowolnej maszynie w dowolnej chmurze. No i owszem, zgadza się, można tak zrobić, tak. Ale to tylko dotyczy maszyn wirtualnych, na których nie zapisujemy żadnych danych, czyli w serwerach webowych czy serwerach aplikacyjnych, które nie przechowują dane. No bo jeżeli już mamy dane, no to później jeszcze musimy te dane jak chcemy umieścić na chmurze, to musimy później je jakoś wyciągnąć i przeważnie koszt wyciągnięcia też jest jakiś z tej chmury.

Więc tutaj o tym nie rozmawialiśmy jeszcze, ale mamy taki komponent, który łączy chmurę naszą w AWSie na przykład z chmurą prywatną HCX, który rozciąga sieć w warstwie drugi pomiędzy cloud operatora a nas, no i tą maszynę wirtualną online'owo można migrować z jednej strony na drugą, czyli te dane podążają praktycznie biorąc za operatorem, który sobie mówi, no dobra, ja chcę te 3000 maszyn wirtualnych mieć dzisiaj we Frankfurcie, A jutro chcę mieć gdzieś w Ameryce, tak. No i z naszej perspektywy tutaj polskiej, kiedyś mi się wydawało, że takie migrowanie na odległości danych z całą konfiguracją, z bezpieczeństwem, no to cały komplet idzie, tak, no bo sieć jest za każdym razem powtarzalna.

W Polsce będzie ten newscast taki mało popularny, a ostatnio podbija serce naszych Tutaj klientów ze względu na właśnie tą dużą mobilność i możliwość szybkiej relakowania nie dość, że całych aplikacji, no to jeszcze danych, które podążają za tą aplikacją. Także to jest taka unikatowa rzecz. Jeszcze warto wspomnieć o tych elementach związanych z nauką. Większość korporacji w Polsce i firmy średniego zasięgu ma VMware'a i się na nim znają administratorzy. W związku z tym u takiego cloud operatora niedużo czasu zajmuje, żeby opanować i wdrożyć takie rozwiązanie i je konsumować, no bo dostajemy wszystko na tacy, gotowe rozwiązanie.

Jeżeli w konsoli u Cloud Operatora. Wyklikamy, że chcemy mieć 10 serwerów fizycznych z tym naszym całym stackiem. No to myślę, że po około 2 godzinach u każdego Cloud Operatora będzie ta infrastruktura gotowa, czekała na nas. Po naszej stronie w ciągu godziny możemy doinstalować HCXa. Zostawić tunel pomiędzy chmurą prywatą a publiczną i mieć gotowe rozwiązanie i cieszyć się tą mobilnością. Z jednej strony mobilność, ale też z drugiej strony readiness, bo mamy taką sytuację, w której nowy stos technologiczny wymaga nowej nauki. Jeżeli przebijamy się przez hyperskalerów, powiedzmy trzech, to wskaż mi takiego kozaka, który w każdym z trzech operatorów, jeszcze w on-premie,

I to jest chyba ważne, że mogą. Czyli jest czas na to, żeby spokojnie przeanalizować, sprawdzić, które elementy przenieść w Cloud Native, które robić refactoring, które po prostu usunąć. Na te wszystkie rzeczy trzeba czasu, a jeżeli my będziemy gonić tego króliczka non stop i kształcić się w kolejnych stosach technologicznych skrajnie skomplikowanych, no to stajemy się generalistami. Trudno powiedzieć, że jesteśmy już specjalistami. Na świat potrzebuje specjalistów, jakby na to nie patrzeć. A jeszcze do twojej historii dodałbym część związaną z bezpieczeństwem. Jakże różne bezpieczeństwo jest i różnie realizowane u każdego cloud operatora i to stanowi też duży problem, no bo z jednej strony musimy wyszkolić kogoś, kto się zna na tych różnych cloud operatorach, co tam, jak skonfigurować daną aplikację.

Począwszy od developerów, a skończywszy na obsłudze, czyli na operatorach i administratorach, no ale później też mamy dział bezpieczeństwa, który musi No i tutaj też zaczynają się pewne schody, no bo bezpieczeństwo jak sobie myśli, że ma u siebie w datacenter ileś tam rzeczy, no i myśli o tym pudełkach fizycznych, że ma te pudełka fizyczne i nagle sobie wyobraża, no ale jak ja te pudełka fizyczne wstawię tam do tego cloud operatora, tak? I to u każdego inaczej. No i tu zaczynają się pewne trudności po stronie bezpieczeństwa i też tych specjalistów na rynku jest niedużo na ten moment. No tak, i jeszcze wiesz, dodatkowo poza tym, że jest ich niedużo, to jeszcze dochodzi do tego fakt, że ci specjaliści porzucają to, z czego wyszli.

To znaczy, jeżeli przechodzą w chmurę prywatną, publiczną, przepraszam, któregoś konkretnego vendora, to Odcinają sobie tę pępowinę, z której przyszli, nie? I często te środowiska później on-premowe stoją w pewnego rodzaju, no, zostają porzucane. Jak widzę dużych klientów, których, wiesz, wszyscy chcą być devopsami Kubernetes, madafaka, slash cloud, nie? Ale kiedy im powiesz, że trzeba by walnąć fabrykę w cek, gdzieś tam lekko przekonfigurować, nie? To doznają pewnego rodzaju obrzydzenia, nie? Och, te zmurszałe infrastruktury, nie? I to też jest ciekawe, bo Bo to jest pewnego rodzaju wyjście z tego impasu. Z jednej strony pozwalasz ludziom się rozwijać tam, gdzie chcą, więc zostają z twoją firmą, z twoją instytucją, a z drugiej strony nie zabijasz infrastruktury na siłę, która przynosi ci kasę.

Przyjmijmy sobie, że jeżeli przez ostatnie 20 lat budowałeś aplikację w on-premie i one są zbudowane tam, czyli tam będą najlepiej działać, zwyczajnie w świecie, po prostu to tam zostało zrobione. Chcesz to wykonać w formie transplantacji mózgu do innego organizmu gdzieś. Generalnie ja nie słyszałem o jakiejś bardzo dobrze udanej transplantacji mózgu na warstwie medycznej i nie sądzę, żeby to się wydarzyło w IT, więc przenoszenie tego na pałę do innego środowiska jest błędne, ale trzeba to zrobić. Wydaje mi się, że te VMC w sumie na dowolnej chmurze, bo jak nie popatrzysz sobie, to ci najwięksi dostawcy AWS, Azure, Ovh, wszyscy dają ci możliwości instalacji środowisk dwiemorowych. Nie ma czegoś takiego, że jest to coś innego, coś niedobrego.

Tak mi się wydaje przynajmniej. Powiem Tobie też, że są takie wyróżniki, które klienci lubią. Na pytanie działu bezpieczeństwa, no dobrze, kupimy sobie w chmurze natywnej tysiąc maszyn wirtualnych, Czy te maszyny wirtualne będą na sprzęcie share'owanym z innymi klientami? Czy ta sieć będzie share'owana z innymi klientami? Jaką mamy pewność? No i tutaj jak dostajemy u cloud operatora w tym AWS czy Google czy w Azure fizyczne serwery, które wiemy, że są dedykowane i tylko na tych fizycznych serwerach działa oprogramowanie, można to zaszyfrować swoim Oczywiście klucze na poziomie e-visana, czyli storage'u, czy też jeżeli chcemy całe maszyny wirtualne szyfrować, to szyfrujemy.

Mamy dedykowany sprzęt i ten dedykowany sprzęt jest podłączony dedykowaną siecią. Oczywiście tą sieć jak chcemy możemy udostępnić do natywnej sieci takiego cloud operatora, ale to daje, że tak powiem, taki nasz pierwiastek. Taką wyspę cloud operatora, którą dokładnie wiemy, że tam są przetwarzane nasze dane. To nie jest tak, że nie wiemy, co się dzieje. Odpowiedź na pytanie przy maszynach wirtualnych cloud operatorów. No dobrze, a czy mamy pewność, że jak bierzemy maszynę, która ma 3 GHz, dwa procesory po 3 GHz, to czy rzeczywiście te 3 GHz są dla nas tylko, czy to jest share'owane z jakimiś innymi użytkownikami? Jaką mamy pewność? No nie mamy, tak? Tutaj w tym przypadku mamy ten sprzęt. No i my dokładnie wiemy, że cała moc obliczeniowa, którą kupujemy tego sprzętu, jest dedykowana dla nas.

I to my sami decydujemy, czy na tym sprzęcie chcemy postawić tysiąc maszyn wirtualnych i będzie poziom wirtualizacji procesorów, dajmy na to, 4 do 1, czy 8 do 1, czy 2 do 1, czy 1 do 1. Sami o tym decydujemy w zależności od naszych potrzeb. Tam też jest jeszcze taka kwestia, że z jednej strony to jest zarządzanie pojemnością, ale z drugiej strony też jest kwestia kosztów. No bo wiele firm się boi Clouda pod tym względem. Matko Bosko, przeniosę ten mój cały burdel, który mam u siebie w on-premie, do chmury i wtedy się naprawdę okaże, ile to żre. Bo nikt tego nie potrafi zwierzyć, nie? No i tak jest zazwyczaj, nie? To znaczy, przy przenoszeniu do chmury należy posprzątać, może przed, nie? Przy przenoszeniu do chmury należy posprzątać. No ale też nie wszystko jest takie trace'owalne, to znaczy nie do końca wiadomo, ile wszystko będzie żarło, nie?

Można sobie odinstalować softy do mierzenia tego ważenia, no ale to zawsze może być niespodzianka na końcu, nie? To też ważne przy VMC. Myślę, że warto powiedzieć, że struktura tego jest taka, że po prostu masz trzy hosty, tak jakbyś miał trzy hosty w serwerowni. Wyżej trzech hostów nie podskoczysz. Jeżeli chcesz, to musisz kupić kolejny, więc taka kontrola kosztów jest po staremu. Znaczy możesz płacić za te hosty codziennie i to będzie po prostu więcej, albo możesz je na trzy lata z góry kupić. Czyli w sumie tak, jakbyś kupował złom do swojej serwerowni. W sumie to są, jeżeli chodzi o koszty, to są dwa modele, z których klienci korzystają, a może nawet i więcej niż dwa modele. Bo to jest jeden taki, że kupujemy sobie trzy hosty lub więcej lub 100 hostów lub 1000 hostów, w zależności od tego, jakie mamy potrzeby, na określony czas, gdzie mamy ten koszt tańszy, czyli powiedzmy od roku do trzech lat i dłużej, no to Cloud Operator, ponieważ wie, ile mniej więcej skonsumujemy, no to ten koszt jest mniejszy.

Innym modem to jest taki, i też mamy takich klientów, który mówi, no ja tę infrastrukturę potrzebuję od dziewiątej do siedemnastej. No i to jakiś automat rano o ósmej czy tam o siódmej naciska przycisk i to wszystko startuje. Później z jakiegoś worka cloudowego, gdzie migruje na storage, wisa nowy, maszyny wirtualne, uruchamia na dziewiątą, już użytkownicy korzystają. O godzinie siedemnastej wyłącza to całe środowisko, no i płaci tylko od dziewiątej do siedemnastej Episode 22 VMware Cloud on X AWS, Azure, GCP, Ovh Cloud, Alibaba.

Episode 22 VMware Cloud on X AWS, Azure, GCP, Ovh Cloud, Alibaba. Wciskamy przycisk, po godzinie buduje nam się środowisko na serwerach fizycznych ze storage'em. Z tego właśnie storage'u, gdzie żeśmy przekopiowali, albo bezpośrednio robimy storage migration, albo na początku migrujemy z tego wolniejszego storage'a na ten No i po dwóch, trzech godzinach mamy odtworzenie się. Mieliśmy problem przez tydzień, zapłaciliśmy za tydzień za tych serwerów, zwijamy się. Jeżeli tak popatrzymy na koszty i stworzenie takiego disaster recovery w chmurze, To jest niski koszt.

A jak chcesz mniej, to mniej czasu jesteś gotowy na to, żeby twój biznes stał po sześciu, ośmiu, siedmiu godzinach, no to będziesz płacił za tego DR-a o wiele mniej. I to jest, myślę, fajny use case. Jakie jeszcze use case widzisz takiego VMC na sensu stricte? Jeszcze do tego scenariusza disaster recovery, ja bym jeszcze jedną rzecz ważną zarzucił, czyli sieć i adresacje tych maszyn wirtualnych, bo jak mówiłeś, że konwertujemy z jednej strony do drugiej, to przeważnie u Cloud Operatora mamy inną adresację. Zdarza się, że Maszyny wirtualne z aplikacją działają na zaszczytych adresach IP, no i to wiem na podstawie rozmów z klientami, że jeszcze się tak zdarza, że jakaś jest stara aplikacja, no i nie możemy jej zmienić adresu IP i z tym, z kim ona się komunikuje.

No to tutaj mamy pewność, że możemy odwzorować adresację u cloud operatora na No inne scenariusze, które ja bardzo lubię, zresztą też 10 lat temu Promowałem polskie firmy, w których pracowałem. Niestety nie byli oni jeszcze wtedy gotowi na taki scenariusz. A ten scenariusz to się nazywa capacity on demand albo pojemność na żądanie. Czyli mamy jakieś piki przetwarzania i chcemy się szybko wyskalować.

No a tutaj, żeby się wcześniej przygotować, te serwery sobie tam zamówić, jeżeli mamy aplikację monitorowaną, Przez, dajmy na to, VMware Operation Manager, no bo też trzeba o tym powiedzieć, że ta nasza warstwa do zarządzania możemy zarządzać, monitorować i zarządzać pojemnością w on-premise'owym środowisku, jak i u dowolnego cloud operatora, powoduje, że nasz system może mierzyć i patrzeć o ilość użytkowników osiągnęła 9 tysięcy. Wiemy, że nasza infrastruktura on-premise wytrzyma próg 11 tysięcy. Dobra, to startujmy już serwery w cloudzie. Wystartuj tam serwery aplikacyjne z automatu. Dołącz do load balancera. Bezpieczeństwo jest na NSX, więc za pomocą tagów udostępniamy ruch.

No i rozumiesz mój tok myślowy, że tutaj wydaje mi się, że idziemy czasami taką ślepą uliczkę. To znaczy, kiedyś tak trzeba było robić, bo nie było innych rozwiązań. No tak, tak, właśnie do tego dążę, że niektórzy nasi klienci nie są świadomi takiego rozwiązania, jak proponujemy u cloud operatorów i nie są świadomi, że ci cloud operatorzy będą zasilani, no bo mają energię niedyscyplinowaną centralnie, w związku z tym ten problem Jest automatycznie rozwiązywane. Mają ugrane umowy na agregaty, bo to jest generalnie ich praca. Ich pracą jest zapewnienie ciągłości działania klientów, którzy się u nich produkują. To jest ich główny biznes. To jest ich główny biznes. A my produkujemy gwoździe, a typy zapewniają infrastrukturę.

No i tam, starą metodą, którą robił to przez setki lat na SQL-u, to sobie tam przetwarzał. A później może to bez problemu wysłać do Power BI, tu już nie ma jakichś Cloud Gateway, cudów na kiju, tylko naprawdę wszystko wydarza się w obrębie jego prawie rzytynanta. Ja myślę o tym, że korzystanie z usług pasowych, SaaSowych u dostawców Clouda, czy też w jakimś tam szerzej rozumianym multicloudzie, staje się łatwiejsza, bo nie musisz tego wszystkiego ciągnąć obrzydliwie drogimi łączami, za obrzydliwie duże pieniądze za transfer, To jest taki krok pośredni związany z szybszą adopcją usług w murze publicznej.

I dodam jeszcze taką jedną ciekawą rzecz o kosztach związanych, no bo wiadomo, pompowywanie danych do chmury publicznej Jest bezkosztowe, ale wypompowywanie kosztuje. No i u jednego z cloud operatorów, wiem na pewno, że u jednego z cloud operatorów, jeżeli maszynę wirtualną postawimy na rozwiązaniu VMware'owym, to ta maszyna VMware'owa, ta wirtualna maszyna może dostać adres IP publiczny, no i wychodzić do internetu, tak? No i ten koszt wyjścia do internetu, tego całego naszego środowiska, tych wszystkich maszyn, dajmy na tysiąc maszyn wirtualnych i one mają interfejs wystawiony do internetu, dostają tam adres IP za darmo itd. To my możemy za pomocą tych maszyn wirtualnych transferować do siebie z chmury publicznej dane nie ponosząc żadnej opłaty.

Czyli jakby VMware traci taką zaletę, którą miał od wielu lat, że ma jeden z największych install base'ów w on-premie, gdzie jest najwięcej na razie jednak infrastruktury. Bo odejdziesz to wszystko do Azure, albo AWS, albo Ovh, a klient nagle się orientuje, no to w sumie po co mi ten VMware, nie? In the long term, jak to się mówi, nie? No to może się już wszystko przełączę do tego wybranego dostawcy cloudowego. Czy widzisz tutaj jakieś takie zagrożenie? Czy jakoś to adresujecie wewnętrznie? To byli nasi sprzedawcy, niektórzy się denerwują z tego powodu, bo nie znają wszystkich zalet naszego rozwiązania. Mamy tutaj jednego w Polsce takiego klienta, który na początku korzystał hybrydowo, czyli miał rozwiązanie VMware u siebie w datacenter, u cloud operatora jednego i drugiego, czyli miał takie trzy nogi, wszystko ze sobą było powiązane, a później to rozwiązanie VMware w cloudzie tak dobrze działało, że stwierdził,