Czy 5G zmieni sposób, w jaki piszemy aplikacje? Dyrektor Vmware: „tak, choć nie tylko 5G”

Vmworld 2019 okazał się doskonałą okazją do spotkania i odbycia ciekawych rozmów z jednymi z najbardziej utalentowanych osób w branży dużego IT. Jedno z takich spotkań udało mi się odbyć z Edem Hoppittem, dyrektorem działu ds. rozwoju aplikacji natywnie chmurowych w regionie EMEA.

Ed Hoppitt jest też doświadczonym strategiem i konsultantem biznesowym. Spotkanie z nim było okazją do rozmowy między innymi o przyszłości aplikacji konsumenckich, w tym transakcyjnych, zakupowych, skanujących i podobnych. Streszczenie tej długiej pogawędki znajdziecie poniżej. Z rozmowy dowiecie się, czemu usługodawcy chmurowi powinni kibicować swojej bezpośredniej konkurencji, że multi-cloud można traktować jako pojedynczą platformę i poznacie receptę za nadążeniem za szaleńczym tempem innowacji.

Maciej Gajewski, Spider’s Web: Tematem przewodnim tegorocznego VMworld wydawały się być Kubernetes i sieć 5G. Mnie bardziej interesuje to drugie. Czy faktycznie 5G wymaga zupełnie nowego podejścia do budowania i wdrażania aplikacji.

Ed Hoppitt, Vmware, dyrektor działu ds. rozwoju aplikacji natywnie chmurowych w regionie EMEA: Nie wydaje mi się, że chodzi tu konkretnie o 5G w kontekście budowania aplikacji. Bądźmy precyzyjni. Tu chodzi o popyt konsumentów na nowe usługi, które 5G umożliwi.

No tak, właściwie o to pytam.

To tak, oczywiście. Tradycyjne aplikacje są budowane tak, by były stabilne – a nie by co chwila były zmieniane. W świecie, w którym ludzie oczekują błyskawicznych innowacji, stałego dodawania nowych funkcji i możliwości i w którym ludzie wybierają nawet banki na bazie tego jaką mają apkę na telefon staje się jasne, że aplikacje trzeba zacząć budować w inny sposób. W taki, który pozwala na szybkie wprowadzanie innowacji.

Jedynym sposobem na zwiększenie tempa innowacji to zmniejszanie ryzyka kosztowego i rozmiaru zmian. Ta transformacja polega więc między innymi na tym, że duże aplikacje są rozbijane na liczne mikroserwisy. Nie ma od tego odwrotu, to musi się wydarzyć, by zaspokoić popyt na tempo innowacji. Więc to nie do końca istotne co dokładnie jest motorem zmian – 5G, szybkie Wi-Fi – a sama zmiana tempa. Właśnie to wymusza zmianę podejścia do budowy aplikacji.

Wspomina pan o mniejszym ryzyku kosztowym. Ale przecież transformacja w jakiejś większej firmie nie jest łatwa. Administratorzy niechętnie porzucają znane im, dojrzałe i funkcjonujące doskonale od lat produkty. A są też i zaszłości historyczne, takie jak niekompatybilne ze sobą silosy danych. Może jednak należałoby znaleźć jakiś złoty środek w utrzymaniu tego tempa?

Tak, te silosy są faktycznie wyzwaniem godnym wskazania. Bo wraz z budową każdej nowej aplikacji czy usługi ryzykujemy stworzenie kolejnego silosa. Będą więc silosy na których budowane są maszyny wirtualne, a później nowe silosy na których budowane będą kontenery i Kubernetes. My jako Vmware uznaliśmy, że to niewłaściwe podejście.

Rozwiązaliśmy przecież już problem wirtualizacji sieci obliczeniowej i magazynów danych. Przez vSphere, vSAN i NSX – punkty na liście odznaczone. A Kubernetes przecież w zasadzie służy jako pośrednik pomiędzy tymi rozwiązaniami a aplikacją, po prostu robi to w inny sposób, dlatego nazywamy go kontenerem. To jednostka konsumpcji mocy obliczeniowej w zasadzie.

Świat Kubernetesa przypomina nieco świat wirtualizacji sprzed 15 lat. Niemal każdy ma jakiś swój własny projekt open-source z tym związany. Jest mnóstwo firm, każda rozwiązuje jakiś pojedynczy problem. Świat wirtualizacji przez te 15 lat się skonsolidował, bo klienci wolą gotowe pakiety kompletnych rozwiązań. Raczej decydują się na zestaw narzędzi od jednego dostawcy: Vmware, Microsoftu czy kogoś tam. Liczy się efektywność, bo klienci naszych klientów i tak o to nie dbają. Tak jak żaden hotel nie promuje firmy, która zajęła się budową jego kanalizacji.

Dlatego Vmware zdecydował się na ujarzmienie Kubernetesa, by był tak łatwy w uruchomieniu i użytkowaniu, co maszyny wirtualne. Pomysł budowaliśmy na bazie świetnych pomysłów społeczności skupionej wokół Kubernetesa w kontekście orkiestracji chmury i jej skalowania. Na tym polega nasz Project Pacific, czyli wstawienie Kubernetesa do hyperwizora. Tym samym staje się on rdzeniem vSphere. Nie było to łatwe, bo vSphere to rozwiązanie typu mission-critical, polegają na nim tak wrażliwe instytucje, jak elektrownie czy lotniskowce. Kubernetes w hyperwizorze znacząco upraszcza wszystko.

Myślę że rynek pójdzie za tym przykładem. Upraszczając narzędzia i upraszczając ofertę – w sposób przyjazny dla twórców aplikacji i gotowy na przyszłą rozbudowę.

A kiedy będziemy mogli testować Project Pacific?

Na razie nie mogę powiedzieć.

Raczej lata czy miesiące?

Nie mogę powiedzieć. Podpowiem tylko, że rynek rozwija się i zmienia bardzo szybko.

A co z problemem interoperacyjności? Duże firmy, całkiem rozsądnie, stosują multicloudową strategię. A więc budują część infrastruktury na AWS, część na Azure i tak dalej. Jak im pomóc?

My naszych klientów uczymy, że chmura to platforma, a nie miejsce. Chmura to nie Azure. To nie Google Cloud. W rozumowaniu jakie przedstawiamy klientom, chmura to platforma. Jesteśmy w stanie przenieść lub powielić infrastrukturę z – na przykład – Amazona do Microsoftu bez jej naruszenia. Tyczy się to również Oracle’a, Alibaby, niemal dowolnej znanej publiczne chmury. W środowisku naszych narzędzi poszczególne chmury są traktowane po prostu jako klastry. Vmware NSX widzi jedną sieć.

To oznacza, że aplikacje i maszyny wirtualne jakie zbudowałem mogą działać wszędzie. A to oznacza, że mogę swobodnie wybierać pomiędzy chmurami. Uwielbiam Lambdę. I super. Moje aplikacje wykorzystujące Lambdę mogę umieścić w wirtualnej maszynie na AWS i połączyć je z Lambdą. Moje Oracle API? Super. Stworzę maszyny wirtualne narzędziami Vmware i mogę z nich korzystać. Mogę korzystać z dowolnych API i usług na dowolnej chmurze. Rozwiązaniem jesteśmy my, zapewniający pełną przenośność.

Jak w takim razie patrzą na was chmurowi partnerzy? Amazon i jemu podobni robią co mogą, by nie ułatwiać migracji do konkurencji. Wy ją ułatwiacie. Dostrzegam konflikt interesów.

Współpracują z nami, bo wiedzą, że jednak mimo wszystko tego oczekują od nich klienci. Ja wiem, że pewnie każdy menadżer panu to mówi o swojej firmie, ale serio: nasi klienci nas kochają, bo potrafimy ich słuchać. A nasi klienci to niemal zawsze również klienci Microsoftu, Google’a czy Amazona. Oni wywierając na nas presję wywierają presję również i na dostawcach chmur.

Zwłaszcza że ci dostawcy znają Paradoks Jevonsa. Stenley Jevons był brytyjskim myślicielem w czasach rewolucji przemysłowej. To były czasy dużych problemów dla Wielkiej Brytanii – jeszcze większych niż Brexit. Największym był zbyt duży import węgla, Brytania za bardzo na nim polegała. Cała brytyjska rewolucja przemysłowa napędzana była wyłącznie węglem importowanym z kolonii.

Rząd zainwestował więc duże środki w rozwój maszyn parowych, by te stały się jeszcze wydajniejsze. Bo przecież wydajniejsze maszyny zużyją mniej węgla, a więc import będzie niższy, a kraj będzie bardziej samowystarczalny. Jevons wskazał błąd w tym rozumowaniu. Wydajniejsze maszyny parowe będą zużywać jeszcze więcej węgla, bo ludzie będą mogli je wykorzystywać do większej liczby zadań za mniej pieniędzy. I miał rację.

W interesie chmurowych usługodawców jest wzrost całego rynku i przyrost konsumpcji chmury. Im wygodniejsza i tańsza chmura, tym więcej osób będzie jej używać. Przecież to udowodnił Uber. Odkąd się pojawił, więcej osób korzysta z taksówek.

No dobrze, ale na rynku chmurowym – czyli de facto przetwarzania danych – mamy jeszcze jedną fragmentację. Prawną. Nie tylko poszczególne chmury różnią się od siebie, ale i poszczególne prawa w różnych krajach…

…i na to również zapewniamy automatykę. Mogę zdefiniować różne polityki dla tych samych aplikacji czy VM-ów i dowolnie je stosować. Tak, rozwiązaliśmy to, to część Vmware Mission Control.

Czyli rozwiązaliście już wszystkie problemy i zamierzacie się nudzić?

No nie. Nadal mamy dużo do zrobienia w kwestii unifikacji zarządzania aplikacjami i maszynami wirtualnymi. Proszę obserwować rozwój Tanzu Mission Control, to tam będziemy teraz wprowadzać najwięcej innowacji mających na celu jeszcze większe ułatwienia dla heterogenicznych środowisk. Będziemy burzyć kolejne silosy.

Trzymam za słowo.

Przekona się pan na pewno za rok na kolejnym Vmworld.