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

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

I dla mnie to konkretne rozwiązanie pokazuje właśnie, w jaki sposób można to zrobić, jednocześnie zachowując to mapowanie między Zanim przejdziemy dalej, Witamy w Inleokaście, 23 odcinek. Zaczęliśmy jak zwykle z rozbiegu. Dzisiaj ze mną Wojtek. Wojtek jest ewangelistą, to się tak pięknie nazywa? Kiedyś technica evangelist, dzisiaj developer advocate, dokładnie tak. Developer advocate w takiej małej firmie, która ma trzyliterowy skrót nazywający się AWS.

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

Ale co tu było konkretnie powiedziane? To jest w zasadzie wydźwięk całego tego spotkania, bo nie było zauważ czegoś takiego, że ogłoszyli, nie wiem, S3 nowe, nie? Coś tak fundamentalnie innego, że to rozwalało nam mózg. Przynajmniej ja nie odczułem takiego, że nie było takiego fundamentalnego ogłoszenia, ale z drugiej strony było coś takiego, że dobra, zrobiliśmy kolejne kroki, nowe procesorki, nowe coś tam, takie po prostu zwykłe rośnięcie. Nie ogłosiliśmy 230 nowych usług, tylko raczej pokompletowaliśmy te usługi w coś, co się da używać. I to jest według mnie ogromna zaleta, bo popatrz, taką rozmowę miałem na ostatnim AWS User Group Meetingu w Krakowie z kolegami, że prototypowanie

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

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.

Oczywiście znowu, to jest mega kontekstowe. Pomogło to, że była ta aplikacja już przeniesiona w AWS? Na pewno. Aczkolwiek wydaje mi się, że największy wysiłek, jaki był związany z tym konkretnym tematem, pomogło w tym kontekście, że nie trzeba było myśleć o migracji samej aplikacji monolitycznej 1 do 1, lift and shift do chmury. Bo to już poniekąd zostało zrobione, to już działało. To zdecydowanie ułatwiało sprawę, dlatego że można było się teraz skupić na powolnym wybieraniu tego, co najbardziej boli z tego monolitu, wyciąganiu tego na zewnątrz i wspólnie tak projektowaniu tej ewolucji architektury, Żeby pozbyć się tych najbardziej palących problemów związanych ze stabilnością, ze skalowalnością tego systemu, z wdrożeniem poprawnych i takich powtarzalnych potoków CICD, żeby to wszystko miało ręce i nogi, żeby mogło być utrzymywane w odpowiedni sposób.

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.

Ale popatrz. Jesteś firmą, która produkuje gwoździe. To jest mój ulubiony przykład. Ja z nim podróżuję przez Inleocast od chyba już 20 odcinków. Jesteś firmą produkującą gwoździe. Sam to pięknie powiedziałaś. Nie jest twoim corem robienie infrastruktury. Twoim corem jest szybsze i bardziej precyzyjne produkowanie gwoździ, które finalnie na końcu będzie szybciej sprzedaż te gwoździe. Dokładnie tak. I ty masz aplikację. Nawet jak nie masz tego zespołu, to sobie go wynajmujesz, który ci tę aplikację napisze, przepisze, whatever. W jakim celu, kiedy masz trzech ludzi w IT, czy pięciu, czy pięćdziesięciu nawet, możesz powiedzieć, że będziesz lepszy od firmy, która inwestuje, jak popatrzysz sobie na, bardzo dobre są takie, postaram się też dorzucić to jako załącznik, takie czarty, jak pokazane jest, ile AWS inwestuje w R&D.

I siła tej platformy była tak naprawdę w integracji. I trochę tak jak z tą wyświechtaną synergią. Suma wszystkich komponentów dawała dużo większą wartość na samym końcu dzięki integracji. 23 odcinek IGLEOcastu. Pierwszy raz, Wojtku, ktoś z AWS-a u nas, więc się niezwykle cieszę, bo myślę, że to może się przerodzić w jakąś większą historię. Developer Advocate Wojciech Gawroński, Maciej Lelusz, dziękujemy bardzo i zapraszamy ponownie w stosownym momencie, a tymczasem cóż, udanej zimy. Mam nadzieję, że zostanie z nami chwilę, a ja idę odśnieżać. Także trzymajcie się. Dzięki również. Dzięki.