#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?

Wiesz co, tak, natomiast jakby mi się wydaje, że te VMC jakby sensem stricte, jak tak się trochę w tym temacie rozeznawałem, to u hyperskalerów można by powiedzieć, że jest to kolokacja VMware'a, to znaczy dostajemy fizyczny sprzęt, który działa w osnowie data center danego hyperskalera. Jest zarządzany z jednej strony od strony takiej twardej infry, czyli prądów i innych tych zabezpieczeń przerośni hyperskalera, od strony softu, czyli vizfira i tej części związanej ze sieciową, ze storage'em, o czym mówiłeś, od strony VMware'a. I część już taka konsumencka, czyli konfiguracyjna jest przekazana do nas, jako użytkowników końcowych, tudzież dla klientów już takich finalnych. I co ciekawe,

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ć.

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.

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.

Jest, sporo. 80% sukcesu, 90% sukcesu, tylko jak prawo Murphy'ego mówi, kurde, no to te 10% sukcesu to będzie właśnie twoje Active Directory, ERP i bazy danych. Więc jakby tu jest też małe ryzyko, bo to też trzeba ten business continuity, to też nie chodzi o to, żeby na pałę przywalić te wszystkie dane do chmury i później się jakby cieszyć faktem, że je mamy tam, tylko mieć możliwość realnego testu tego i myślę, że to jest też fajną rzeczą, bo Bo to daje nam na pewno VMC. Teraz jak myślę sobie o use case'ach, bo o tym też chciałem pogadać, to DR jest takim bardzo fajnym use case'em, bo to jest oczywiście DR i tu trzeba zaznaczyć z pewnego rodzaju tolerancją na RTO i RPO.

Bo jeżeli zrobimy sobie, że chcemy odzyskiwać wszystko w godzinę ma działać, to ta infrastruktura VMC będzie działać non stop. Nieważne u którego operatora. Jeżeli ustawimy sobie, że nasz system ma się zacząć działać po 8 godzinach, No to wiadomo, tak jak powiedziałeś, scenariusz, w którym trzymamy wszystko na wolnym storage'u, uruchamiamy on-demand platformę VMC i wrzucamy te dane, nie? I to trwa 8 godzin, VM'ki stoją. I to moim zdaniem jest super, bo dotychczas jak budowaliśmy DR'y w środowiskach on-prem'owych, to była druga taka sama infra, nie? I wiesz, ludzie byli przyzwyczajeni na to, że dane już tam są. Generalnie serwery to by od tylu roku nic nie robiły, nawet fajnie jak coś się tam przekręcą, jakiś tam system. Natomiast w chmurze to pokazuje, że jak chcesz godzinę, to zapłacisz dużą bułę.

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.

Po dwóch godzinach, czyli jak chcesz uruchomić VMC, to ono musi zostać, no co, serwer musi zostać zainstalowany, to wszystko się dzieje od samego początku, nie? Czyli można powiedzieć, że to jest taki bare metal provisioning. I ten bare metal provisioning sprawia, że ten sprzęt, który stoi u dostawcy, on będzie gotowy dla ciebie w jakimś czasie, ale w związku z tym kompletnie cię nie interesuje kwestia związana z dwoma rzeczami. Czyli ile prądu zeżre ci ta infrastruktura versus ile tam jest tego podatku narzuconego operatora. Ja myślę, że druga rzecz jest bardzo ważna, o której się mało mówi, ale moje zielone tło trochę powinno to wskazywać. Otóż ślad węglowy. Wszyscy się z tego teraz zalewamy, ale za chwilę ktoś dowali nam podatek od śladu węglowego i będziemy musieli wszyscy to policzyć.

Wiesz co, jeszcze jedną rzecz się zastanawiam nad takimi rozwiązaniami dookoła tego wszystkiego, bo z jednej strony mamy fakt migracyjno, ewakuacyjno, zielono, tego typu sobie case'y omówiliśmy, a też jest taki fakt, ja to nazywam datagravity, to znaczy większość danych, powiedzmy, w długoletnich zakładach wciąż leży w on-premie. I przez jakiś czas tam poleży, bo przechowywanie danych w chmurze jest srogo, drogie, nie? Więc trzeba to przechowywać rozsądnie, nie? No i ta rozsądność polega na tym, że dobra, dane maszyn wirtualnych łatwo przenieść na VMC, no bo to tak, jakby gdzieś wstawiasz HCX-a, robisz vMotion, dane przeskakują grzecznie z jednej serwerowni w on-premie do serwerowni w chmurze.

W twojej kolokacji, na przykład w Azure. Swoją drogą, wiesz, jak się nazywa usługa AWS-owa w Azure? To jest najbardziej rozkoszna nazwa, to się nazywa AVS. Nie wiem, gość od marketingu chyba oszalał, bo za każdym razem rozmawiając o tych projektach mówimy AWS, a AVS i to jest taki ciężki brainfuck, nie? Natomiast AVS na przykład stawia to na AVS i co to mu daje? Daje mu to, że na przykład ma później te dane przetworzyć i na przykład używa do tego, no nie wiem, prezentuje za pomocą Power BI. Czyli nie musi pompować tych danych do chmury jeszcze raz, Tylko on je ma dość blisko, bo siedzą na tych VM-kach, które dostały je powiedzmy z serwerowni edge'owych, w swoich fabrykach dostał dane produkcyjne, one trafiły do serwerowni edge'owych i następnie zostały wysłane, już takie trochę przetworzone do maszyn wirtualnych na AWS, czyli VMC on Azure.

I jeszcze tak na koniec naszego dzisiejszego spotkania, bo myślę, że te case, które poruszyliśmy, były bardzo ciekawe. A jakie największej widzisz tych projektów, widzicie jako VMware, projektów typu VMC, W których sektorach rynku? Powiem Ci, że w bankowości, oczywiście w finansach, w retailu, bo tam retail potrzebuje coraz więcej zaawansowanych usług też związanych ze sztuczną inteligencją, bo zarządzanie z logistyką, bo cały łańcuch dostaw, żeby przeanalizować i optymalizować, tam jest głównie biznes, to potrzeba nowoczesnych usług. No i też odpowiedniej pojemności, więc tu też ten reliter myślę, że dobrze się odnajdzie w tych usługach.