#27 Multicloud: czy warto bujać w wielu chmurach?

Moja przygoda z chmurami zaczęła się w 2016 roku. Miałem pomysł z kolegą rozpocząć startup i bardzo szybko żeśmy sprawdzili, że po prostu nas nie stać na to, żeby uruchomić serwery. My w dwójkę mieliśmy background Java Enterprise, więc taki barokowy i również cennik był dosyć barokowy jak na coś, co chcieliśmy robić z boku, jak dodatkowy interes. I to spowodowało, że bardzo szybko zacząłem szukać taniej alternatywy i w ten sposób poznałem Serverless. Idąc dalej do przodu ze startupu nic nie wyszło, ale ja się nauczyłem Serverless, znaczy nauczyłem, no wciąż się go uczę, więc poznałem trochę ten Serverless i stwierdziłem, że to jest świetna technologia i świetna architektura właśnie dla wszystkich, którzy szukają taniej i również szybkiej alternatywy.

Tutaj zareklamuję, to jest taki myślę, że największy polski. Największe polskie centrum serverless, no z racji tego, że ja podobnie jak ty jesteśmy związani z AWS-em, no to on jest skierowany dla osób, które też z AWS-em pracują, działa od 2018 roku. Słuchaj, no, przede wszystkim gratulacje. Mieliśmy okazję pogadać i poświętować ten wspólne osiągnięcie. Tak jak ja się śmieję, że wspólne, bo ja od jakiegoś czasu zajmuję się społecznością od strony AWS Hero. I powiem Ci szczerze, że to jest zajebista sprawa, bo faktycznie, tak jak mówisz, jeżeli robiłeś coś dobrze, to to niewiele zmienia, a z drugiej strony dodaje trochę takiego stresa, moim zdaniem, że gdzieś tam coś w więcej oczu na Ciebie patrzy i trzeba jakoś dalej, to wiesz, chciałbym mieć ten wózek.

Więc gratulacje. Ja mam dzisiaj ten temat, który poruszamy, czyli Multicloud, on jest poza strefą trochę, według mnie, naszego wspólnego komfortu. To znaczy, dlaczego ja go chciałem poruszyć z Tobą, bo Jakkolwiek serverless, dla wielu kojarzy się z takimi szczami, o których pewnie zaraz będziemy w detalach dyskutować, ale niekoniecznie kojarzy się z czymś, co jest transportowalne pomiędzy wieloma chmurami. Zaraz sobie o tym pogadamy. A z drugiej strony projektury związania VM-kowe, konteneryzacyjne, infrastruktury sieciowe i dla mnie Multicloud po prostu jest. Tacy są klienci. I niektóre rzeczy są urodzone, moim zdaniem, żeby egzystować w pewnych vendorów, a niektóre rzeczy są urodzone, żeby egzystować pomiędzy vendorami.

A Ty z perspektywy człowieka, który siedzi w serverless, czyli technologii, może też dla tych, którzy tak do końca nie czają bardzo, o co chodzi, jak tu nie ma serwerów, nie? Generalnie, jakbyś też parę słów powiedział o tym u rdzenia, W rdzeniu, co to jest serverless dla ludzi, którzy mogą nie do końca wieszczalić bazę, nie? Tak w paru żołnierskich słowach, a później przejdziemy do tego, o czym mówiłem. Jak postrzegasz serverless w kontekście multicloudu? Bardzo chętnie, ale od razu odbiję piłeczkę. Później oczekuję, żebyś ty zdefiniował multicloud, bo to też jest dosyć ciekawe, o czym będziemy dokładnie rozmawiali, twoim zdaniem. W kilku zdaniach. Serverless, nazwa jest taka trochę myląca, Ponieważ mówi o tym, że niby nie ma serwerów.

Te serwery gdzieś tam są, tylko Ty jako klient nie musisz się o nie martwić. Czyli to jest jakby najwyższy poziom abstrakcji usługi managed, która od strony infrastruktury jest zarządzana przez AWS, a dla Ciebie są same benefity. W teorii musisz się skupić tylko i wyłącznie na logice biznesowej i na działaniu swojej aplikacji, Co nie do końca jest prawdą, bo musisz też przemyśleć architekturę, ale głównym wyznacznikiem, co też niestety się troszkę zmienia, jest to, że w momencie, kiedy nie używasz aplikacji serverless, nie masz na przykład klientów w swoim systemie, którzy z niego korzystają, ty nie ponosisz kosztów związanych z działaniem tej aplikacji.

W serverlessie to widać, bo tam widać szybko koszty. To jest zajebista sprawa. I multicloud w tym stosunku będzie czymś, że na przykład będziesz miał taki serverless w AWS, w Google, w czymś tam. Ja tak to interpretuję, jak ty byś zinterpretował multicloud? Czy w ogóle w kontekście serverlessa można myśleć o rozwiązaniach multicloudowych? Mówię o control plane na razie, nie data plane. To są takie dwie kwestie dla mnie, bo zanim przejdziemy do serverless, to co powiedziałeś jest dla mnie ciekawe. Ja mam z kolei trochę inną definicję tego. Tak więc dla mnie hybrydowa chmura to jest oczywiście jakaś organizacja, która ma powiedzmy swoje własne data center albo je wynajmuje i też korzysta z usług jakiegoś dostawcy chmury publicznej.

To znaczy do niego trzeba faktycznie mieć jakiś sensowny use case. Czyli na przykład być instytucją dbającą o życie ludzkie. Ja nie wiem. Zestawem elektrowni atomowych, które generalnie wypadałoby, żeby się naprawdę replikowały w różne miejsca i miały dużo kopii swojego środowiska po to, że ich SLA znaczy coś. To jest według mnie dobry use case. Dość trudny do znalezienia na rynku. Ale większość firm jest już w Multicloudzie. Popatrzmy na Office 365. I AWS. To jest dość popularny zestaw. Masz kawał ażura, w gruncie rzeczy ciągniesz tam z tym Office 365 kawał ażurowego środowiska, bo masz ażura D, coś tam, coś tam, coś tam.

I oni od lat prowadzą Statystyki związane z użyciem chmury w Europie, w krajach europejskich. One są opublikowane, bo my tutaj z Maćkiem dwójkę wydajemy swoje podatki na to, że wszyscy mogli korzystać z tego. I tam jest fajna dosyć klasyfikacja, bo jest kilkanaście poziomów tego, jak bardzo korzystać z chmury. I powiedzmy takim najbardziej prymitywnym poziomem korzystania z chmury to jest korzystanie z maila. Przechowywanie plików w chmurze. I to są chyba rzeczy, które we wszystkich krajach w Unii Europejskiej są najbardziej popularne. Te statystyki dotyczą firm, które zatrudniają powyżej 10 osób. Ale jak już się wybierze takie bardziej zaawansowane rzeczy, jak te, które są dla nas bliskie, czyli np. czy firma

Nie wiem dlaczego, ale wybierają taką drogę. To już nie komentuję tutaj, po prostu tak jest. Gdzieś tam ogromną ilość rzeczy machine learningowych robią, tam robią też to w AWS. I dopiero te przetworzone dane gdzieś tam trafiają do aplikacji, które publikujesz w różny sposób. Jedni w kontenerach, bo takim wygodniej, inni w zjemkach, bo się przyzwyczaili z on-premu. No a coraz większe grono, ale tak jak mówisz, ten procent jest zasadniczo niewielki wciąż, idzie w stronę właśnie function as a service. Wiesz co, to tutaj też o tym serverless musimy porozmawiać. No bo z jednej strony jest funkcja lambda, Którą prawie wszyscy o niej słyszeli. Dla tych z was, którzy nie słyszeli, no to funkcja

A function, a service, o czym Maciek przed chwilą powiedział, to jest to pewnego rodzaju usługa typu Cloud Nightly, która polega na tym, że my dostarczamy tylko i wyłącznie kod źródłowy do naszego dostawcy, a w momencie, kiedy następuje jakieś zdarzenie, czyli np. wywołanie przez endpoint restowy albo ktoś zaploadował plik, ten kod jest uruchamiany i on zwykle trwa od Kilkuset milisekund do maksymalnie 15 minut w przypadku Lambdy i się wtedy kończy i znika. I to jest takie nowe podejście, dla wielu jeszcze bardzo niekomfortowe, ponieważ my nie mamy swoich serwerów, kontenerów, nie ma gdzie się zalogować, nie ma jak tam coś pomieszać w środku, bo to jest totalnie odseparowane.

Więc to jest jednego rodzaju Usługa serverlessowa, najbardziej znana i powszechnie stosowana, ale jest cała gama usług serverlessowych, które nie są funkcjami. I to jest chociażby do przetwarzania danych, dajmy na to Athena. Athena pozwala nam odpytywać pliki, czy to będą jsony albo comma-separated-value-files na bucketach S3, zwykłym SQL-em. Więc to jest super przykład. Ona się skaluje dla nas. Ona generalnie jest, my za nią płacimy, tylko i wyłącznie za ilość danych, które przetworzy dane zapytanie.

I to jest właśnie ten moment, w którym ja... Powiem Ci, dlaczego chciałem zapauzować. Bo to jest ważna chwila decyzyjna. Zebraliśmy się tu w takim gronie, też szeroko uznawanym za hejterskie, z moją i z twoją osobą w roli głównej, na temat tematu, którym nie czujemy się do końca pewni, że jest dobrym pomysłem. Bo to też ważne, że trzeba mówić o tematach dla siebie niekomfortowych, moim zdaniem, bo to człowiek trochę rozszerza sobie jaźń. Ja też tak uważam, to znaczy, że jeżeli siedzisz w jednym kontrolplanie, Jaki on by tam nie był, czy to będzie Azure, czy AWS, czy Google, czy Alibaba, nie? To nie ma większego znaczenia, ale jesteś z niego przyzwyczajony, on spełnia twoje wymagania biznesowe, to musisz mieć na zwykle intensywny impuls.

Czyli niekoniecznie się skupiali na tym, żeby robić jakąś wybitnie zaawansowaną, nową technologię, tylko generalnie dużo pieniędzy zarabiać, jak to tak mówi się. Czyli taka kadra kierownicza wynikająca z biznesu i oni rozpatrują Multicloud jako opcję do dywersyfikacji ryzyka. Perspektywa jest taka, że technologia w ogóle nie ma znaczenia na pewnym poziomie zarządczym. Wszystko jest robialne. Jak zbudowali na środku pustyni Burcz Kalifa w trzy lata, to znaczy, że się wszystko da zrobić. Taka jest percepcja. Odpowiednio dużo pieniędzy, czasu i wykorzystania siły roboczej. Dla się osiągnąć wszystko. Natomiast drugi aspekt to jest zarząd wynikający z osób technicznych. To znaczy jak mamy jakiegoś CTO, który jest generalnie osobą techniczną, czyli przeszedł różne ścieżki kariery, w 1982 zaczynał w serwisie komputerowym i tak przeszedł, aż stał się CTO dużej organizacji.

To rozmowa jest zupełnie inna, Ta osoba będzie zwracać nie tylko uwagę na ryzyka, na, nie wiem, jakieś tam kwestie biznesowe, ale będzie potrafiła spojrzeć w dół, jak bardzo dużo problemów to może sprawić. No i teraz, na końcu drogi, jak jest mądry zarząd, to się dają takie dwie strony, czyli osoba, która chce zarabiać pieniądze, za wszelką cenę robić tą zmianę biznesową, no i osoba, która wie, z czym to się je. To jest idealna sytuacja. Nie, one się ścierają, jeszcze są, powiedzmy, partnerscy, dadzą radę się dogadać. Według mnie, Kto ciśnie na Multiclouda? Multicloud jest wodą na młyn dla Enterprise Architektów. Znaczy wyobraź sobie, jak jesteś osobą, która pyta biznes co trzeba zrobić i ta osoba buduje absolutnie skomplikowaną infrastrukturę.

Rozmawiam, przepraszam, z certyfikowanym Enterprise Architektem. Wiesz, do czego zmierzam. To jest woda na młyn, ale ja nie mówię, że to jest zła pobudka. To wynika z tego, że po prostu należy to rozważyć. I teraz, jeżeli to jest dobrze rozważony temat, to wnioski wracają w taki sposób do tego zarządu, że to się nam przyda do X, albo nam się nie przyda do Y, albo kosztuje tyle. Jest to zrealizowane. Ale bardzo często Po prostu stwierdzamy, że ojejku, no skoro już się zdywersyfikowaliśmy w jednej chmurze, jesteśmy w kilku regionach, mamy to porozsypywane, no a jak coś się stanie, jak ona padnie, no szansa jest jedna na milion, ale ta szansa jest bardzo dla nas ważna i ryzykowna, no to przenieśmy się do drugiej chmury.

Więc to jest też duży problem, że te zmiany technologiczne one są drive'owane, Albo przez ludzi, którzy mają ukrytą agendę, albo przez innych ludzi, którzy mają ukrytą agendę, czyli generalnie chcą doić kasę. No nie oszukujmy się. I bardzo często te decyzje, żeby pójść w tą chmurę, jednak się kończą na tym, a że zmniejszymy ryzyko. Tylko teraz pytanie, jakie zmniejszymy ryzyko? Jeżeli masz AWS-a, to masz 22 regiony na świecie. I masz 100% gwarancji SLA na to, że Root 53 będzie się działać, czyli możesz się przełączyć. Szansa na to, że dwa regiony nie będą działały równocześnie jest mniej więcej taka, że i tak prawdopodobnie już nie żyjesz, bo jest wojna atomowa.

No wiesz, no to jest markowanie życia koniec końców, co nie? A jak widzisz taką kwestię, gdzie Zamiast iść w stronę rozwiązań, pozostać w strefie komfortu z pewnymi rozwiązaniami, które dobrze tam działają, nie? Natomiast i poszukiwać use case'ów blisko dostawcy, z którym jest dobrze, czyli na przykład jak pracuje ci się dobrze z AWS-em, masz to wszystko tam dobrze poorganizowane, szukasz use case'ów dla swojego biznesu, który będzie jakby tą innowację, no pozwalał ci dalej prowadzić to innowacyjne działanie. Ale dla pewnych segmentów swojej pracy, swoich procesów w firmie czy tam rzeczy, Po prostu podejmujesz taką decyzję, że bierzesz rozwiązania z półki i tam nie robisz innowacji żadnej.

To jest taki codzienny biznes. Bo wiesz, bo ja trochę czasami walczę u klientów z tym, że oni we wszystkim możliwym próbują być innowacyjni. I to nie jest dobre dla ciebie jako producenta. Ja uwielbiam firmę produkującą gwoździe, to jest mój stary numer. że po prostu jak jest firma produkująca gwoździe, która ma robić szybko gwoździe i oczywiście zatrudni paru fajnych cloud native developerów, jakich w ogóle stać, albo weźmie firmę, która im to zrobi i niech piszą świetną aplikację w Serverlessie, w AWSie, bo jest, jak już dzisiaj stwierdziliśmy tutaj, że jest najlepszy. No dobrze, ale np. do codziennej pracy mogą używać Office 365 albo Google Workspaces, bo wcale nie muszą pisać nowego postfixa.

Pewna część naszego biznesu musi być rdzennie innowacyjna i tam trzeba szukać rozwiązania może nie multicloudowego, a w innych rzeczach pójść w rozwiązania, które tam dostępne są na rynku. Tak mi się przynajmniej wydaje, że nie starajmy się prowadzić innowacji na wszystkich frontach, bo nie mamy tych budżetów i możliwości technicznych. Dla mnie aplikacje z pakietu Office To jest taki jakby fundament i nie postrzegam go jeszcze raz jako argument w dyskusji Multicloud. I jak najbardziej. Prawdopodobnie Microsoft ma najlepsze rozwiązania i wiele osób chwali.

Opcje, które dają nam szersze pole wyboru w przyszłości, nawet kosztem dzisiejszych wyrzeczeń, kosztów itd. Myślę, że to była jakaś dla mnie nowość i dlatego to sobie tak zapamiętałem, nawet przypomniałem specjalnie przed tą rozmową, bo w jakiś sposób oni to udowodnili badaniem na jakiejś grupie osób. Iż przez to, jeżeli dobrze Cię rozumiem, że wybieranie rozwiązań multicloudowych jest dla nas naturalnie, wydaje się naturalnie ciekawszą opcją, aczkolwiek można przez to ponieść dość duży koszt. No co się tak finalnie dzieje? Nawet nie tyle, że ciekawszą, tylko że lepszą. Po prostu, że czułem, że jest lepsza.

Bo ciekawość to może być, wiesz, można to pociągnąć w to, że my jako inżynierowie lubimy zabawki. To nie o to chodzi. To jest po prostu kwestia, że to jest w naszych głowach jakoś gdzieś głęboko osadzone. I my po prostu, jak się mówi bajas po polsku, jesteśmy przesunięci. Jakby zawsze te opcje będą dla nas, faworyzujemy je. I teraz na to też się nakłada to, że my od lat Jako architekci i programiści łączy nam się do głów, że my musimy dostarczać rozwiązania, które będą przede wszystkim łatwe do zmiany.

My z tego będziemy zawsze korzystali, bo może architektura, która by była w 80%, a nie w tych 100, byłaby równie dobra, a my, oszczędzając 120% tej elastyczności czy zmienności potencjalnej, bylibyśmy w stanie zrobić coś dużo szybciej albo taniej itd. No tak, wiesz co, mi się wydaje, że w ogóle, robiąc już takie dzieła z infrastrukturą architektoniczną, Warto by było spojrzeć na to, to jest taki przykład, który ja lubię z życia podawać, jak ktoś buduje duży dom, nie? I ten dom ma dwa piętra, ma pokoje dla dzieci i tak dalej, nie? I on go buduje na całe swoje życie, on czy ona, nie?

I ten dom jest faktycznie bardzo elastyczny, nie? Można te pokoje wydzielić, wiesz, dzieci w różnych konfiguracjach w te pokoje powkładać, nie? Natomiast za ileś tam lat, a jest wybudowany na całe życie, zaznaczam, nie? Te dzieci opuszczają dom, nie? No i te pokoje stoją puste i trzeba grzać tą całą górę, kombinować. No i dodatkowo tu jeszcze, myślę, wchodzi jedna rzecz, którą trochę bym nawiązał do tego, co mówiłeś na początku, czyli firmy z dziesięcioletnim dość jakby historią. Oni już mają ten dom i tak bardzo trudno powiedzieć sobie, że może trzeba by było go sprzedać w diabły, nie? I za te pieniądze zbudować sobie mały, przyjemny domek dla dwóch osób, nie? Albo dla jednej. Bo wiesz, bo My się bardzo często boimy zmiany nie tyle nawet na lepsze, co na inne.

Czy nie sprzedają je po to, bo to jest zły produkt, tylko sprzedają je dla kogoś, kto chce poświęcić energię, siłę, czas i pieniądze na to, żeby robić lepsze te dwa produkty, które im zostały. Oni się tym nie chcą zajmować, chcą miliard wrzucić w ten swój główny. I tak samo trochę trzeba patrzeć na infrastrukturę, na architekturę, na aplikacje. Po prostu zrobić rachunek sumienia i stwierdzić, no dobra, słuchajcie, mamy te 57 tysięcy aplikacji, czy 50 aplikacji, 5 jest dla nas naprawdę ważnych, 3 musimy kupić albo zbudować samemu. No i nie dać się oszukać, że na wszystko będzie jakieś rozwiązanie wash and go, że się położy na jakieś cmp, rozwiązanie cloud management platform, które nagle nam to opyli na wszystkich możliwych chmurach.

Bo są różne warstwy, tak jak cały czas do tego wracam i na końcu drogi wydaje się, że Mów, mów, przepraszam, bo ci przerażam. Dokąd, bo ten koniec drogi może być ciekawy. Wiesz co, i na końcu drogi wydaje mi się, że odcinać się powinno stare zeschnięte konary, żeby młode miały gdzie rosnąć. I to jest według mnie szansa właśnie w Multicloudzie. To znaczy, jeżeli on będzie świadomie wdrażany, to człowiek zrozumie, że skomodyzował pewną część rzeczy i trzeba po prostu te stare konary poodcinać, przenieść się na nowe platformy. Niektóre stare zostawić, bo dobrze żrą i po prostu przynoszą kupę kasy dla firmy, a np. nowe rzeczy budować już w całkowicie nowych, zupełnie skalowalnych i zupełnie innych platformach.