#23 Mądrość i chytrość w cloud native na przykładzie AWS

Chciałbym w tym miejscu podziękować firmie Veeam za okazję sponsorowania przez tego wykwintnego producenta 23 odcinku Innocastu, w którym będziemy rozmawiać o mądrości i chytrości. Ich rozwiązanie Veeam Backup and Replication dla Office 365 pozwala zabezpieczyć dane, a wypadałoby, żebyście się zabezpieczali w różnych aspektach, w stosunku do danych również. Zapraszam na odcinek. Ja myślę, że w ogóle pokłosiem tej naszej rozmowy jest to, żeśmy się spotkali pierwotnie na tej kwintnej imprezie, która trwała pięć dni i doprowadziła nas do obrzęku stóp na pewno. Nie wiem jak ty, ale ja na re-invencie się bawiłem wyśmienicie, poza tym mnóstwo ludzi i to takich, z którymi w sumie się spotykam raz na rok. Albo w ogóle ludzi, z którymi pracuję w kontekście AWS,

Ale nie mam nawet czasu się w Polsce z nimi spotkać i się spotykam na re-invencie. Nie musimy przelecieć całą planetę, żeby spotkać się z ludźmi, którzy są na przykład z Wawki albo z Poznania albo z Krakowa, to by było najlepsze. Mieszkamy w tym samym mieście. 10 tysięcy kilometrów. U ciebie było podobnie? Też miałeś takie wrażenie? Wiesz co, podobnie, na pewno jeżeli chodzi o brzęk stóp, to na pewno. Ilość kroków, jakie się robi dziennie jest zatrważająca, ale to dobrze, bo przy naszym braku ruchu to akurat dobrze, że się ruszamy. Może te skoki są zbyt intensywne jednak, bo żeby to było tak, że to narasta, a to wiesz, przylatujesz, lecisz 12 godzin nie ruszając się i później Pierwszego dnia robisz 35 tysięcy.

Mam dwie, dwa ogłoszenia, które mi się prywatnie bardzo podobają. Sprzed reinventu zdecydowanie większość, umożliwienie podłączenia wielu MFA tokenów do jednego IAM usera. To jest coś, co było bardzo długo oczekiwane. Wreszcie się pojawiło. Także dla root account to rozwiązuje wiele problemów, które są z tym związane, więc to zdecydowanie na plus. A z samego reinventa Zdecydowanie coś, co mnie pasowało tematycznie, bo trochę się w tym temacie obracałem w jeszcze obecnym 2022, czyli AWS Application Composer, czyli ta nowa usługa, która tak naprawdę pozwala na wizualizowanie architektury, a jednocześnie

Przygotowanie Infrastructure as Code jako rezultatu tego wszystkiego. Mnie się to podoba z dwóch względów. Po pierwsze, to pomaga przy eksploracji, bo będzie łatwiej. Wiadomo, że na razie to jest dość ograniczona usługa, jeżeli chodzi o zakres usług. Wszystkich 250 ponad usług tam nie ma na razie. Ale to już w tym momencie daje ciekawy obraz, jeżeli byśmy chcieli sobie zobaczyć, jak wygląda konkretna definicja Infrastructure as Code dla czegoś, czego nie znamy. Czyli od tego zakresu eksploracyjnego to jest fajna sprawa. Natomiast druga sprawa, która mnie bardziej ciekawi. Miałem serię prezentacji, które były zatytułowane Lines and Boxes na temat tego, w jaki sposób mapować infrastrukturę, architekturę, jak łączyć te dwa światy ze sobą.

Ja nazywam się Maciej Lelusz, Evola Poland. No cóż, chcemy pogadać troszeczkę o tym, jak re-event nam minął, bo mieliśmy tę przyjemność i ból, o którym już wspominaliśmy, wystąpić albo być na tym evencie. A z drugiej strony też chcieliśmy pogadać o pewnym obrazku, który wysłałem zaszczepne na tę rozmowę, a o nim to będzie później. Jeszcze wrócę na chwilę do tych odczuć po publikacjach. Ja osobiście nie mam ulubionego takiego elementu, który został opublikowany, natomiast mam taki feeling, Po wcześniejszych reinventach nie był obecny, natomiast po tym jest. To znaczy, że zaczęła się taka faza dojrzałości. To znaczy, że nie publikujemy 500 nowych usług, które są w wersji MVP i wszyscy będą cierpieć ich używając i też na przykład cierpieć na integracji między nimi, tylko mówimy tak, skoro mamy 250, ponad 200 usług,

To jak dużo energii spalamy na to, żeby użyć tych 30%? No bo de facto tak jest. No bo jednak wiele z tych usług jest usługami dla rynków niszowych, nie? Znaczy dla użytkowników pracujących z niszową jakąś potrzebą. Natomiast powiedzmy 30% z nich to są takie commodity. Wszyscy ich używają i to jest nie wiem S3 albo EC2 albo Fargate'y. Coś co używają w zasadzie wszyscy, którzy idą w tą stronę. I teraz chodzi mi o to, że nagle się okazało, że można to Zrobić wersję drugą, trzecią, czwartą, piątą, lepszą i zadbać o tą integrację pomiędzy tymi usługami. I to jest klucz, który mówi o dojrzałości moim zdaniem. Zajebisty, bo dotychczas to było takie biegnięcie do przodu, jak buldożer, który nie zna spokoju, wiesz, sunie, nie? A teraz jest coś takiego, dobra, obejrzymy się do tyłu, zobaczmy, co nasi klienci używają i wpompujmy w to

Seksyliardy dolarów, żeby był jeszcze lepszym produktem i ta integracja nie zżerała tyle czasu. I ten kompozer jest tego przykładem, bo nie dałbyś rady zrobić, moim zdaniem, technicznie kompozera, który integrowałby gówniane produkty. No bo by się rozwalało to w tej integracji. A to pokazuje, że już to jest na tyle maturity, na tyle ma tej dojrzałości, że możesz popełnić takiego frontpage'a. Lekko. To jest jedna rzecz. Druga rzecz, bo bardzo mi się podoba, że to ty to powiedziałeś, dlatego że AWS z racji tego, że jest też najstarszą chmurą, zbiera słuszne bądź niesłuszne opinie, cienkie baty czasem na temat tego, jak wygląda integracja poszczególnych usług, jak wygląda temat związany z Developer Experience, który jest szalenie ważny, bo tak na dobrą sprawę

To właśnie osoby, które na co dzień implementują te rozwiązania, są bezpośrednimi klientami. I cieszę się, że to ty powiedziałeś, dlatego że to jest jeden z takich kierunków, który było widać trochę w 2021, a w tym roku jest to zdecydowanie jeden z priorytetów. I wydaje mi się, że to jest jeszcze jeden taki element, gdzie wychodzi to AWS-owe Customer Obsession, bo tak naprawdę sporo tych negatywnych feedbacków nawet często docierało. Natomiast słuchając ich dało się rozpoznać przewijające się trendy wzorce, które warto by było usprawnić i

Jest największą siłą chmury. Kiedyś prototypować trzeba było wydając na to pierdyliardy dolarów. Teraz można to zrobić za relatywnie nieduże pieniądze, ale trzeba mieć cholernie dużo wiedzy o backendzie. Na przykład spróbuj, tak jak ja jestem laikiem serverlessowym, jak sobie myślę o tym, że miałbym teraz usiąść i zrobić serverlessową aplikację, bym się pożygał. Trzeba mózg swój wywrócić na lewą stronę. To się da nauczyć, ale to nie jest łatwe. A ja bym chciał prototypować coś, więc biorę tak naprawdę ten generator i on mi trochę pomaga. Ja nie mówię, że to będzie coś, co będzie działać in scale, w przyszłości będzie super, ale przynajmniej sobie coś dowiodę. I myślę, że to jest właśnie ten następny krok, który fajnie, fajnie wybrzmiał w tym reinvencie.

Generalnie ja go opiszę swoimi słowami, Wojtka później ty spróbuj swoimi. Więc mamy tu dwie osie. Jedna to się nazywa mądrość, a druga, ja teraz mieszkam w Małopolsce z tym góralem niskopiennym, nazywa się chytrość. Czyli cleverness, taka chytrość. Na tej linii mamy pewnego rodzaju wykres, który pokazuje, że używanie chmury jako swojego datacenter jest ani mądre, ani chytre. Góra natomiast tego rozwiązania, czyli najbardziej wypasiony moment, mówi o tym, że kiedy jesteś najbardziej mądry i tak średnio chytry, to budujesz na zaufanych serwisach od dostawcy chmurowego. A kiedy jesteś durny jak pień, ale chytry,

To budujesz własną cloud agnostyczną, jakiś middleware w środku, który można przenosić pomiędzy różnymi chmurami. Taka jest generalnie moja interpretacja tego. Jak ty byś to, Wojtek, zinterpretował? Jak byś do tego podszedł? Lepiej bym tego nie zinterpretował ze względu na to, że bardzo podoba mi się tłumaczenie cleverness na chytrość, bo to zdecydowanie oddaje duch tego obrazka. Ja powiedziałem na początku, że ja się nie do końca z nim zgadzam, ale nie zgadzam się z nim nie na płaszczyźnie merytorycznej opinii, bo to jest dla mnie opinia, tylko bardziej się nie zgadzam nad tym, że to jest taka konwencja żartobliwa przyjęta, Ja lubię porozmawiać o konkretnych, wspartych danymi wynikach.

I tutaj jest jakaś opinia przedstawiona z perspektywy tego, gdzie pracuję, jakie ja mam doświadczenia też w przeszłości, jeżeli chodzi o implementację systemów. Zdecydowanie się z tym zgadzam. Można się naprawdę przechytrzyć, budując własne rozwiązanie, które będzie sprowadzeniem do wspólnego mianownika tego, co oferuje wielu dostawców naraz. Skończy się to masą świetnie zrobionej, nikomu niepotrzebnej roboty bardzo często. Natomiast z drugiej strony ten brak wiedzy i mówienie, że możemy mieć własne data center, cały czas jesteśmy w tym on-premie, też mi pasuje do takiego początkowego stadium dojrzałości nazwijmy tego cloud native.

Dzieje się kaskada ciekawych wyzwań, bo na dobrą sprawę jakby się nad tym zastanowić, to w przypadku tego przeniesienia takiego 1 do 1 bardzo często obserwuje się ani zysk, A więcej problemów wynikających z tego, że przechodzimy przez zmianę. I wydaje mi się, że podejście pragmatyczne do tego tematu jest chyba najbardziej zasadnym. To znaczy, jeżeli mamy potencjał w tym systemie, który przenosimy do rozwoju, do optymalizacji, do tego, żeby te koszty później Zmniejszać i ewoluować razem z tą obecną stanem architektury i infrastruktury, to jak najbardziej taki ruch będzie miał fundamentalne znaczenie dla rozwoju tego systemu.

I wydaje mi się, że tutaj jest największy zawsze problem i nacisk warto położyć na tę motywację i na tę przyszłość tego konkretnego systemu. Natomiast wracając do tego, co powiedziałeś na samym początku, że Ciebie by głowa rozbolała przechodząc do serverlessu w tym momencie, jeżeli miałbyś się za to zabrać. To jest jeszcze jeden z takich argumentów bardzo często używanych za i przeciw jednocześnie, jeżeli chodzi o chmurę. To znaczy dostajemy masę możliwości i to jest jednocześnie zaleta i wada. I wydaje mi się, że to, co jest chyba największym wyzwaniem zawsze z perspektywy Rozwoju aplikacji w chmurze i przejścia tej ewolucji do tego cloud native, które mamy na obrazku wymienione, to tak naprawdę podejście do tego, w jaki sposób będzie cała organizacja przechodziła przez tą zmianę, jak będą kompetencje i jak będą przede wszystkim ludzie ewoluowali razem z tym tematem.

To znaczy chytrość, wykres chytrości, który jest dość istotny, on polega na tym, że możesz być za chytry. To znaczy możesz przeskoczyć od razu na samą górę i stwierdzić, że yeah, będę od dzisiaj... Wiesz, wszystko ma napisane w Delphi. Zaszyte bez kodu źródłowego, bez dokumentacji. I on robi taki tak zwany skok, wiesz, hypersonic jump, nie? Skacze na serverless. I oczywiście to jest świetny wybór, tylko no jakby przepaść, którą przeskakuje jest ogromna i ten skok jakby z natury jest skupiony na tym, że się wglebi, nie? I już ja zawsze tak przychodzę na potrzeby i mówię tak, a może jakiś taki Pośrodku może stopień byśmy sobie wylali z betonu, nie?

Więc stworzyli takie monster VM-ki, w których puszczali kubernetesy na górze. No ja pytam, podnoszę tak nieskromnie rączkę i pytam, no panowie, dlaczego? I oni powiedzieli, że to pozwoli im przenosić się między chmurami. Czyli mieli swój middleware. Czyli mieli to samo w onpremie, to samo w chmurze i to samo, daj Boże, jeszcze w jednej chmurze. Czy miałaś podobną sytuację? Czy to jest popularne podejście? Bo ja byłem przerażony. Byłem relatywnie przestraszony, co tam się dzieje. Z mojej kariery jeszcze przed, zanim dołączyłem do AWS-a, to był jeden z takich standardowych przykładów, które ja osobiście i my osobiście odradzaliśmy zawsze. I bardzo mądre, najlepsze pytanie świata zadałeś.

Natomiast to jest jedna z takich rzeczy, o których się często słyszy. Nie chciałbym tego zamienić w taką legendę miejską, bo to trochę wygląda jak straszenie yeti albo właśnie czymś, co nie istnieje. To znaczy nikt się nie chce przyznać do tego, że tak robią, a gdzieś te przykłady jednak mimo wszystko są. Wydaje mi się, że i dlatego jeszcze wracając do tego co powiedziałeś o tym rysunku, o tym czemu się może trochę z nim nie zgadzam. Podoba mi się Podobają mi się osie, podoba mi się kształt, natomiast mam wrażenie, że jest jeszcze jedna krzywa, której tutaj nie ma, bo to, że można przechytrzyć siebie implementując multi-cloud strategy na bazie wielu dostawców, to jest jedna z takich rzeczy, o których się mówi i się trąbi bardzo często i gęsto.

Co mam na myśli? Pracowałem przy projekcie, który migrował, miał dużą infrastrukturę, bazę klientów i stosunkowo niewielką infrastrukturę na AWS. Natomiast wszystko było zamknięte w bardzo monolitycznej infrastrukturze. Oczywiście monolityczny kod, architektura to jedno, ale to była też monolityczna infrastruktura. Jeżeli mówimy o tej monolitycznej infrastrukturze, to mam na myśli olbrzymią maszynę EC2, na której było wszystko. Wszystkie serwery SQL Server, dziesiątki serwisów Windowsowych, wszystko na jednej maszynie, w jednej availability zonie, w US East 1. Ja mam dreszcze, jak sobie o tym myślę w tym momencie. Co tam się może później tak?

Miała bardzo Sensowny use case do wykorzystywania aplikacji desktopowych, które były rozlokowane w kilkudziesięciu tysiącach lokalizacji. One zbierały dane i wysyłały te dane do chmury, która miała tą monolityczną infrastrukturę. Więc kompetencji dotyczących Kubernetesa, Dockera kompletnie nie było w tej organizacji, a jednocześnie Była potrzeba, paląca potrzeba tego, żeby ten monolit rozbić. I tam udało się przeskoczyć konteneryzację i wskoczyć od razu do usług w pełni zarządzanych, serverlessowych, takich jak AWS Lambda, Fargate, robiąc bardzo stopniowy redesign tego systemu.

Zbudowaniu infrastructure as code, które nie istniało, ponieważ ten lift and shift został zrobiony. Odzyskanie backupu to było Infrastructure as a cloud. Wiesz co, jeszcze mam tutaj pytanie, bo dlaczego pytam o to, czy pomogło to, że ta aplikacja wraz z danymi znajdowała się w chmurze, bo przy środowiskach hybrydowych, z którymi najczęściej współpracuję, bo nasi klienci są akurat w tym stadium rozwoju, mamy ogromne data gravity po stronie on-prem. To znaczy te wszystkie data lake'i, wszystkie SQL, nazwij to jak chcesz, istnieje Tam. Dlatego, że tam zostało zbudowane i przez dziesiątki lat zbierane były tam dane. I teraz, jakkolwiek rozumiem ten news case, że to wszystko jesteś w stanie zapakować w wielką kulkę z kupy i położyć na C2 i tak czekać, aż się nie zawali, budując dookoła mikroserwisy, jest to drogą, którą wszyscy w zasadzie idą.

To znaczy organizacja musi się uczyć i wiadomo, że ona się uczy czasami skokowo, czasami regresywnie, czasami do przodu, czasami do tyłu, a gdzieś ona się uczy. Natomiast ten rysunek tego nie ma, natomiast on ładnie sumuje to wszystko, że najbardziej mądre i dość chytre, nie bardzo chytre, tylko dość chytre jest wybudowanie swojej aplikacji, oparcie swojej aplikacji o zaufane serwisy dostawcy, serwisy cloud native dostawcy. Ja myślę, że to jest klucz tej naszej dzisiejszej rozmowy, Wiem przez te 20 ostatnich lat, jak się projektuje systemy informatyczne, jak wiele energii i pieniądza trzeba poświęcić na przynajmniej dwie rzeczy.

Na jedną, czyli na zaprojektowanie i wykonanie, a na drugą na rozwój i utrzymanie infrastruktury. Jak przypomnę sobie te potworki kubernetesowe stawiane 3 czy 4 lata temu w on-premie, które musiały się zawalić. Wiadomo było, że jak powstaną, to będzie katastrofa. Bo się skończą ludzie albo pieniądze. No i tak się zazwyczaj działo. Parę mam przykładów, które ciągle jeszcze tam, wiesz, walczą chłopaki. Ale z drugiej strony mamy te Trusted Services, Trusted Cloud Native Services. I ty jesteś trochę orędownikiem tych serwisów, tak? Jakby rozumiem, bo to jest coś, co uważacie jakby w AWS, że jest może nie jedyną słuszną drogą, ale kontekstowo, w większości kontekstów się sprawdza. Tak, bo w większości kontekstów rdzeniem Twojego biznesu, tego jak funkcjonuje organizacja, na czym zarabia pieniądze, nie jest budowanie własnej infrastruktury i odsprzedawanie potem tej infrastruktury, chyba że mówimy tutaj o konkurencji, albo o kimś, kto faktycznie buduje tego typu rozwiązania i jest w segmencie technologicznym.

Tylko raczej skupianie się na tym, co twój biznes robi jako tą korową wartość przynoszącą, mówiąc przyziemnie, pieniążki. Czyli tak na dobrą sprawę to, co tworzy wartość dla przedsiębiorstwa. Jeżeli w tym konkretnym kontekście nie jest to odsprzedaż infrastruktury, budowa technologii, która jest odsprzedawana dalej, to jasne jest, że warto się skupić na czymś, Co w rozliczeniu całościowym, tak zwanym total cost of ownership, będzie na samym końcu tańsze. Problem jest z dojściem do tego etapu, bo on wymaga pracy, wymaga wysiłku. Tak jak powiedziałeś, nie ma tej krzywej uczenia na tym naszym obrazku.

Natomiast to nam daje największą możliwość potem, jeżeli chodzi o optymalizację. Możliwość skorzystania z doświadczenia i z tego, co zostało zbudowane przez dostawców. To nam daje po prostu największą elastyczność na samym końcu i największe możliwości. Jeżeli nie jest naszym celem konkurowanie z takim dostawcą albo budowa właśnie jakiegoś rozwiązania technologicznego, które będzie w bardzo podobny sposób odsprzedawane, to wydaje mi się, że kontekstowo zaaplikowanie i skorzystanie z tych w pełni zarządzanych usług, rozumianych jako cloud native, jako fully managed services, jako serverless, jak zwał tak zwał, przyniesie największe korzyści. Ok, czyli jeżeli segmentujemy nasz problem,

Nie popełnimy błędu wytwarzania swojej własnej infrastruktury w chmurze, tylko zawierzymy zespołom, które mają 100 tysięcy razy większe budżety i tysiąc razy więcej ludzi niż wasz własny zespół, bo ja też to widzę, wiesz, że my to zrobimy lepiej. Mamy taki use case, taki use case uknuliśmy, że prawą ręką, gdzie tam prawa ręka, lewą stopą za prawym uchem się drapiemy, nie taki use case. Jesteśmy jedyni na świecie, nie, dlatego nie możemy skorzystać z tego, gdzie ktoś włożył bardzo dużo energii. Nie wiem z czego to do końca wynika. Mam jakieś takie porażające wrażenie, że wynika to z naszej takiej wewnętrznej siłaczki. To znaczy, że za wszelką cenę my tam będziemy lepsi. Trochę tak, a trochę też wynika chyba z naszej branży. Wiesz, nie bez powodu w IT jest coś takiego, co nazywa się nich syndrome, czyli not invented here, czyli coś, co pozwala na ciągłe odkrywanie koła na nowo i tak jak mówisz, tą taką wiarę w unikalność, bo nasze konkretne zastosowanie jest unikalne, to będziemy chcieli to zrobić po swojemu, bo będziemy wiedzieć, jak zrobić to lepiej.