W tym odcinku nasza luźna rozmowa o tym jak jest z Serverless z różnych stron – tych dobrych jak i tych gorszych!
Ciekawe linki i inne znaleziska z tego odcinka:
Łukasz Kałużny [ŁK]: Wiesz, co temat na dziś Serverless, czyli porozmawiamy od technologicznym powiewie świeżości albo niby powiewie świeżości.
Szymon Warda [SW]: Tak, bo ten powiew to wieje już od 10 czy 15 lat można powiedzieć śmiało. Zaczęło się…
ŁK: … 2004.
SW: To mówisz teraz o s3?
ŁK: Tak.
SW: A wcześniej jeszcze była taka usługa, która zbankrutowała z Wielkiej Brytanii, która właśnie dawała opcje, daj mi kod, wtedy chyba był Pythonowy i będziemy z tego wykonywali. Takie w quazi serverless. No, ale to był 2004, mamy 2019. 15 lat.
ŁK: Tak, idea 15 lat.
SW: Tak, więc jak się tutaj zachwycamy, jako IT powiewem świeżości, to powiew to nie jest tak naprawdę.
ŁK: Tak, Serverless chyba z lambda 2015 dobrze kojarzę?
SW: Może być trochę wcześniej.
ŁK: Końcówka 2014, przełom 2014 i 2015 już tak rzucając wtedy pierwsze takie pojawiły się Serverless Hype, ale gdzieś te serwery stoją.
SW: Tak, gdzieś te serwery stoją. Serverless jest zabawny, bo to jest niby coś, co jak już stwierdziliśmy trochę czasu ma, a jak się patrzy na to, jak stosujemy, to pochodzimy do tego jak do świeżynki. Podchodzimy do jak pies do jeża, trochę nie wiemy jak ugryźć, co z tym zrobić, zaczynamy od zera gdzieniegdzie tam.
ŁK: Tak ta filozofia. Chyba pierwszym dobrym jak już mówimy o wzorcach, chyba pierwszym dobrym podejściem było patrzeć, znowu wrócimy do modelowania, ale ogólnie serwisów, czyli to moja perspektywa będzie niedojrzałość od tych, że ludzie często rzucają się i powstaje dużo nano serwisów.
SW: Tak. Chmura nam ładnie daje ogarnianie, ale potem przejście tego, co gdzie jest, jak co ogarnąć, już staje się dużo trudniejsze tak naprawdę. Rzecz kolejna, która mnie też martwi, to jest to, że często wchodzimy w chmurę, wchodzimy Serverless, ale mamy komunikację synchroniczną wszędzie i znwu te wszystkie problemy, które mieliśmy, wracają tylko w innej platformie, które już rozwiązaliśmy gdzieniegdzie właśnie szynami i tak dalej, tutaj nie są.
ŁK: Tak, a patrząc się w sumie i lambda i Azure functions, to jednak były zawsze promowane chyba od strony eventów i messegingu.
SW: Tak. I tu się zgodzę. Gadaliśmy to, co Microsoft mówił właśnie, że to jest code plus data plus events. No i mam wrażenie, że trochę na tym promowaniu się często kończy, jak w formie implementacji.
ŁK: Tak, promowanie tak, to jest ciekawe tylko tam, gdzie to sensownie zrobione.
SW: Tak, a nie jest łatwo. Ja czasami mam takie wrażenie, że to samo, co widziałem w Powershellu jak się deweloperzy przenosili na Powershella, to nagle zmienne globalne są całkiem w porządku. Tam też można ładnie przekazywać wartość przez parametry, a nagle widzę, że jest na górze blok 20 zmiennych globalnych i się odwołujemy i je montujemy i tak dalej. To też jest programowanie, czemu ty stosujesz rzeczy, których nie robisz gdzie indziej, więc tak to bywa słabo.
ŁK: Dobra to kolejna rzecz to jest częściowo rozwiązywany już częściowo nie, to będą długotrwałe przetwarzania long-running procesy z mojej perspektywy z tym jest problem.
SW: Ja to się zastanawiam tak naprawdę czy…zgodzę się jest problem. Zastanawiam się czy to jest dobre miejsce, żeby umieszczać długotrwałe procesy, bo to ani nie będzie ekonomiczne, ani nie będzie szybkie, bo się nie możemy skalować na poziomie maszyn. Więc to może po prostu nie jest dobre miejsce dla tych rzeczy.
ŁK: Wiesz, co to z perspektywy tak, tylko zobacz, że ludzie się rzucają. Chcą mieć wtedy taką clean architecture. Zauważyłeś takie myślenie? Przy czym masz też jak mówimy serwer albo wszyscy patrzą na te functions, a tak naprawdę mamy kupę usług po boku, które mogą to też nam zrobić. Weźmy na przykład, swego casu były takie popularne architektury głównie w aws, czyli, że odpalamy sobie poprzez lambdę inne rzeczy, odpalamy na przykład MapReduce i inne rzeczy i to dość fajnie wyglądało. Czy z drugiej strony teraz Serverless’owe kontenery, w których te cenniki już wyglądają znacznie lepiej. Tam też long-running proces mógłby się znaleźć. Więc to są takie rzeczy. No i gdzieś przy tym pewnie będzie to temat, który Ty lubisz, czyli orkiestracja takimi długotrwałymi procesami.
SW: Tak i to jest ciężkie i do tego ryzykowne. No, bo jeżeli mówimy o Serverless typowo gdzie nie jesteśmy przywiązani do maszyny i możemy być wywłaszczeni, to im dłużej nasz proces jest wykonywany tak naprawdę, to mam większe szanse, że on zostanie ubity przez coś, bo mieliśmy błąd, jesteśmy wywłaszczeni z maszyny i tak dalej. Więc orkiestracja fajna, ja bym przerzucał zdecydowanie wykonywanie na coś dłuższego, gdzie możemy lepiej tym zarządzać i chyba tyle tak naprawdę. Jeżeli mówimy o pojedynczym procesie tak to wyrzucanie w ogóle. Jeżeli mówimy o opcjach biznesowych, to to jest fajne adresowane, bo to już się zaczęło dziać, zaczęło dziać się w aws przez step functions. Dobry wpis był ostatnio jednego z aws hero a propo tego. To już jest adresowane jak się popatrzy to jest fenomenalnie rozwiązany problemu orkiestracji i zarządzania. To, co w kodzie normalnie mamy skomplikowane, to tutaj nagle jest to mega czytelne. Zawsze pokazuje na szkoleniu. To ludzie robią wow. Z czegoś, co miało 100 linii kodu mamy 3.
ŁK: No tak. Dobra, gdyby te przejścia były jeszcze troszkę szybsze w niektórych miejscach, to pisze się czysto.
SW: Pisze się czysto. Tak. Wygląda ładnie, debaguje się ładnie.Wydajnościowo nie zabija, nie oszukujmy się.
ŁK: Tak, chociaż teraz zobaczymy jak ten provider dla serwis fabrica będzie działał, bo już się pojawiło na GitHub.
SW: Tak też jestem ciekawy w ogóle cały ruch wokół serwis fabrica. No lubię serwis fabrica, ale tak jakoś mam wrażenie, że trochę się nie przyjął przez community.
ŁK: Nie, Microsoft pewnie, dlatego.
SW: Tak, tak samo jak inne ich pomysły, które są fajne i nagle ktoś je przerobi i jest wow to bardzo fajna technologia. Bywa.
ŁK: To, co jeszcze z niedojrzałych paternów.
SW: Z niedojrzałych paternów to się pojawia szczególnie przy czymkolwiek, co piszemy większym, dependency injection. Będziemy mieli wstrzykiwanie zależności i niestety, ponieważ funkcje są dodawane inaczej, da się, ale trochę mi to przypomina czasy, kiedy pojawiło się z dependency injection w nowym gs, jak próbowali, jak to zrobić, jak do tego podejść i jesteśmy chyba na takim samym etapie rozwoju, jeżeli chodzi o dependency injection w Serverless.
ŁK: Ja widzę tak, bo w Azure function się od strony .Net-u się też tak pojawiło, zaczęło się nieśmiało pojawiać, support i inne rzeczy. Ja dependency injection nienawidzę tak naprawdę poza monolitami, bo często i gęsto ludzie nawet nie wiedzą po, co to robią.
SW: Tak to inna bajka. Zgodzę się, że to jest narzędzie nadużywane. Czasami się przydaje, tym bardziej, że często my obracamy się w różnych środowiskach korporacyjnych, gdzie te projekty są trochę większe i one rosną, więc trochę używanie kodu przez dependency injection miewa sens. Dobrze, ale tak naprawdę jest także wiele z problemów, które wymieniliśmy, są trochę adresowane się przez samych prowajderów chmurowych. Co jest fajnego?
ŁK: Dobra z mojej perspektywy to gdzie to działa to są dojrzałe platformy, czyli jeżeli weźmiemy Azure, AWS, niektórzy się śmieją, że Azuer to od alfy. Pierwsza litera, ale jeżeli popatrzymy to są duże i dojrzałe platformy. Czy jeżeli weźmiemy tam Google, to teraz jeszcze próbują robić no i cały ten Stack posiada masę usług, które gdzieś są już pod spodem natywnie dostępne. Jak sobie popatrzymy chyba pierwszą taką rzeczą to będzie monitoring aplikacyjny.
SW: Logowanie i jej całe observability wokół tego.
ŁK: Tak, traceing. Jeżeli sobie popatrzymy, to jest to taki naturalny świat. Jeżeli w Azure mamy application inside, które po prostu wpinamy, no niestety jest drogie jak też tak popatrzymy przez pryzmat, inne rozwiązanie dominanty APM potrafią być droższe i dostajemy tak naprawdę taki cały distributed tracing z pudełka z metrykami, ze wszystkim, dodając tak naprawdę bibliotekę i podłączając to często przy deployment.
SW: Można to nawet uprościć do check box, realnie.
ŁK: Dwóch check boxów.
SW: Dobrze, dwóch. Niech będzie, jak najbardziej. Tak, application inside super możliwości, nie jest najtańsze, absolutnie nie najtańsze. Na start fenomenalne narzędzie. Ilość czasu spędzonego do wartości zyskanej, proporcja jest fenomenalna uważam. Zgodę się jak najbardziej observability i tracing i cały monitoring to jest klucz w ogóle dla mnie, czemu używac Serverless. Trochę dalszy powód, który Ty wspomniałeś. Fenomenalne wsparcie dla messagingu. On jest z pudełka, nie trzeba nic konfigurować żadnego rabbitta, Kafki niczego. Po prostu wysyłamy wiadomość. Jak pokazuje ludziom na szkoleniach jak prosto jest wysłać wiadomość z funkcji, to jest wow.
ŁK: Filozofia ja to nazywam funkcyjnego programowania, czyli in-out, podejście in-out.
SW: Przyjmij, przetwórz, wyślij dalej. Co może powodować tutaj skrajności nanoserwisów. Przeżyjemy, nauczymy się i mimo wszystko będzie dobra.
ŁK: Tak przy tym to jeszcze dużym bonusem jest właśnie wymuszenie asynchroniczności, bo benefituje Ci nie robienie synchronicznych, jako, że płacimy za czas jak to działa, to trochę wymusza u nas też myślenie o tym, żeby ten kod nie był synchronic nie był synchroniczny oprócz takiego messagingu. To też inne integracyje, inne rzeczy. Tak jak strzały, jeżeli potrzebujemy strzelić do kilku zewnętrznych api, zebrać dane, zorkiestrować, no to też już zaczyna wymuszać na nas myślenie asynchroniczne jak to wszystko puścić naraz albo przetworzyć hurtem.
SW: I dotknąłeś też innej rzeczy, którą ja bardzo lubię. To nas kosztuje. Po raz pierwszy chyba w IT możemy nauczyć się na poziomie tak drobnym, co Ile nas kosztuje i czy opłaca się ten kod w ogóle optymalizować. Z reguły mieliśmy monolit, który stał na WMC, która miała 24 procesory i setki gigabajtów ram-u i nikt nie wiedział, co warto optymalizować, a tu mamy poszczególna funkcja, wykonuje się długo, jak tam zetniemy o pół, zaoszczędzimy 2000 $. Łatwo liczymy, optymalizacja zajmie nam tyle. Tyle zyskamy na samej optymalizacji. Prosta kalkulacja i fenomenalne spojrzenie na to, co warto robić w IT. To bardzo sobie też cenię w Serverless.
ŁK: Dobra to jeszcze z takich plusów na około integracja ogólnie z komponetami na platformach, gdzie żyją.
SW: Tak i to już setki integracji tak naprawdę. Azure chyba się doliczył komponentów, z którymi się integruje już chyba koło setki.
ŁK: Lambda tak samo od początku było promowane, jako podłącz je tutaj, wywołaj z tego sobie event, z tego. No, więc integracja. Ja się śmieję te operacje na plikach, bo one są tak częste. Niby pokazuje się na samplach, a okazuje się, że to są bardzo częste scenariusze potem. Realne. Rozpoczynanie flow właśnie od tego, że wpadł mi plik na storege obiektowy i coś muszę zrobić. To jest dość częste. Jednak jest to scenariusz biznesowy. Ja się z tego śmiałem zawsze, że pokazujemy sample, a w rzeczywistości to jest realny scenariusz.
SW: Ale to mój drogi, nie wiem, czy wiesz jak działają przelewy elixir w bankach.
ŁK: Wiem niestety.
SW: To są pliki. Plik jest idealnym protokołem, bo możesz go pobrać. Okej, ale czy jest tak różowo z platformami. No nie jest.
ŁK: Nie jest zdecydowanie.
SW: Co najbardziej kopie? Cold starty.
ŁK: Cold starty. Zdecydowanie. Najwięcej chyba topowe wpisy o problemach.
SW: To zdziwienie ludzi często, czemu tak się dzieje. Zawsze powtarzam ludziom, że zrozumcie jaka była idea. Serverless powstał po to, że była nadwyżkę maszyn, które trzeba by aktualizować. To jest serwis optymalizowany pod tanie utrzymywanie, dzięki czemu on jest tani dla nas. Biznes is biznes, musi się zgadzać. Cold starty będą i to będzie zawsze realny problem, który można obejść tak a nie inaczej. To jest coś, co nie zniknie.
ŁK: Raczej możesz bardzo prosto obejść. W Azure masz te plany premium, czyli płacisz, nie za wywołanie, a za to, że jest dostępne.
SW: Tak, ale wtedy płacisz kasę za up front i wiesz ile płacisz. Ja podchodzę do tego jeszcze inaczej. Często pokazuje ludziom, jak zrobić. Gdzie Cię boli cold start? Jak odbierasz połączenia http to 5 sekund boli cię bardzo cold startu. Jak odbierasz wiadomość, to pięć sekund Cię boli? Dużo mniej.
ŁK: Tak, bo zwykle wrzuciłeś na przykład event. Jeżeli zrobiłeś to prawidłowo z api. Mi zawsze trafia się przy eventach mój ulubiony kod http202, accepted, przyjęłem do procesowania.
SW: Tak dokładnie i to jest inna opcja. Natomiast, jeżeli chcesz budować API, które będzie client facing, po http, użyj nołda. Cpld start jest chyba 10 sekund, 10 milisekund. Niezauważalne dla użytkownika.
ŁK: Tak, ja bym jeszcze dorzucił do tego, bo jak podeszliśmy client facingu, no to chyba najczęściej pokazywane budowa właśnie API Client facingowych dla aplikacji mobilnych, dla innych. To dochodzi jeszcze jedna rzecz, API Gateway.
SW: Konieczny przy funkcjach tak naprawdę.
ŁK: Tak, przy funkcjach takie podejście właśnie scalania tego w jednym miejscu. No i tutaj zaczynają się zabawy z tym, jak to może być dobrze zrobione. Na pewno cashowanie w niektórych momentach może pomóc na te cold starty.
SW: Tak i jeszcze inne rzeczy. To jest to między innymi, że odchudzenie całych funkcji, czyli wyjęcie z nich logowania, wyjęcie z nich autentykacji, autoryzacji.
ŁK: Uwierzytelniania Szymon, uwierzytelniania.
SW: Przepraszam. Poprawię się. Wyjęcie rzeczy, funkcji, których nie powinno być i dzięki temu one stają się chudsze i dzięki temu mamy mniej dependency injection trochę, które jak stwierdziliśmy nie jest tak pięknie ogarnięte.
ŁK: Dobra, lecąc sobie jeszcze w temacie, jak jesteśmy przy wywołaniach synchronicznych, http, no to można powiedzieć, że brak w ogóle pomysłu na service discovery pomiędzy tymi usługami, serwisami. To jest dla mnie troszkę bolączka.
SW: Poważne, szczególnie, jeżeli mówimy o komunikacji w obrębie niejednego serwis APA tylko w kontekście całego systemu tak naprawdę. Potrzebuję serwisu do logowania, potrzebuję serwisu do czegokolwiek. Nie znam url-a i oczekuję, że ktoś mi go poda. Zgodzę się, brak service discovery i brak w ogóle pomysłu jak to zrobić.
ŁK: Niby są jakieś tam configuration story i pomysły, ale nadal to są statyczne konfiguracje, więc to jest dość ciekawe. Devopsujemny sobie do jakiegoś configuration storea tak naprawdę informacje.
SW: Pytanie jeszcze można by zahaczyć i użyć Key Vault, ale to nie jest już takie piękne.
ŁK: To właśnie statyczna integracja. Dla mnie to jest właśnie statyczny service discovery, kiedy wciskam informacje. Z mojej perspektywy już wolę te service discovery z Kubernetesa dns-owe, bo on już jakąś ma filozofię.
SW: Które jest niezłe. Tak.
ŁK: Które ma jakąś filozofię na początek niezłą.
SW: Ale jak jesteśmy przy integracji, to kolejna rzecz, która boli. Nie zawsze jesteśmy całkowicie w chmurze i mi się już raz udało ubić system na on premie, puszczając tam wytworzenie wiadomości w hederze wiadomości funkcje odpytywały z systemu na on premie i nagle okazało się, że wygenerowałem 200 requestów na sekundę i system na on premie powiedział, ja tu więcej nie pracuje. Integracja jest ciężka w ogóle, takie ogarnięcie, ile możemy requestów robić, jak, jaka orkiestracja na poziomie serwera, na przykład limitowanie i tak dalej. Nie ma tego do końca. Nie działa się, robi się to ciężko, bo robi się to na poziomie całego function appa. To jest znowu karkołomnym i nakłania nas do wydzielenia znowu niektórych funkcji tylko po to, żebyśmy je limitować. Nie jest to dobre podejście. Czasami tak trzeba zrobić.
ŁK: Tak sieciówka potrafi boleć. Filozofia, żeby to było bezpiecznie.
SW: Tak funkcje stoją publicznie.
ŁK: Tak, w aws jest troszeczkę lepiej niż w Azure, ale nadal uważam, że tak jak powiedziałeś, zrobimy to może tam troszkę prościej, ale będą te problemy, o których Ty wspomniałeś.
SW: To, co mi się podoba teraz to doszła opcja, ona jest chyba w preview, że możemy zrobić to samo co robiliśmy na on premie, czyli możemy wygenerować sobie service principala, którym będziemy się uwierzytelniali do naprzykład innych usług tak naprawdę, Czyli ta opcja wewnątrz Azure jest prosta, ale dalej dostęp do funkcji jest chroniony przez secret, który jest wysyłany w url-u. To nie jest dużo, powiedzmy sobie.
ŁK: No API Gateway, o której wcześniej wspomniałem właśnie, dlatego też nie client facing. Inną rzecz, którą ja widzę, trochę kontynuując przy tych Twoich limitach, o których wspomniałeś, no to już fasy ogólnie to jest bardzo wysoki poziom abstrakcji. Jeżeli sobie popatrzymy od serwerów, aplikacji i innych rzeczy. No i podkręcanie parametrów innych rzeczy może być problematyczne.
SW: Tak. Pamiętam, że mieliśmy taką sytuację, że nagle nasza aplikacja zaczęła działać tam chyba 10% szybciej. To jest zauważalne. Co się stało w ogóle? Okazało się, że jeden note, na którym pracowaliśmy miał po prostu procesor, którzy się bardziej bustował, zauważalnie tam chyba o pół GHz. To jest zauważalne i nagle różnica czasu frequestów wychodzących, bo to monitorowaliśmy, nagle była tam rzędu 10-15% krótsza. To są naprawdę zauważalne wartości. To przydaje się, co w ogóle fajnie widać we wpisach ludzi od stack overflow. Oni to robiątweakowanie bardzo mocno i mają na tym realne zyski.
ŁK: Tak i malutką infrastrukturę jak popatrzymy.
SW: Tycią jak na ich zapotrzebowania to jest naprawdę bardzo mała infrastruktura.
ŁK: Tak. Tweakowanie i compute, o którym wspomniałeś, to jest dobry przykład, że są pewne limity i rzadko, kiedy możemy je wykręcić, czyli potrzebujemy dwa cory, haha nie dostaniesz ich.
SW: Nie masz w ogóle pojęcia corów, nie masz pojęcia ram-u i koniec kropka. Może być funkcja, która potrzebuje z definicji bardzo dużo ram-u, a trafi na hosta, który ma trochę mniej tego ram-u i nie dostanie.
ŁK: I out of memory.
SW: Dokładnie.
ŁK: Przypomina mi się mój fuck-up. Zastanawiałem się, czemu mi się coś wywala. To był taki nazwijmy to proof-of-concept, ćwiczyliśmy różne ciekawe rzeczy, czyli jak naprawdę zbudować przetwarzanie na functions albo coś. I słuchaj i zrobiłem głupotę, skapowałem się dopiero po dwóch dniach, czemu mi się to wywala. Okazuje się, że źle przekazałem, zostawiłem sobie w akurat Azure functions tam przy wołaniu robisz, co ci wchodzi tak i zrobiłem sobie glova wtedy jak string i okazuje się, że on ładował całą zawartość pliku do pamięci. Jak były małe jsony do testów przetwarzania tych danych, człowiek tego nie widzi, a potem zaczynałem już taki prawdziwszy wolumen i były sobie pliki po 300 mega, ale zdarzały się po 700.
ŁK: Oj smuteczek.
ŁK: I zastanawiasz się, czemu idzie out of memory i tak jest dziwnie z tym przetwarzaniem. I czemu na początku.
SW: Tak i out of memory i za chwilę będzie out of money.
ŁK: Na szczęście to nie było takie duże, ale to też pokazuje, że trzeba trochę pomyśleć o tym.
SW: Tak, łatwo się nadziać. Ten poziom abstrakcji jest nie tylko na poziomie maszyn, ale też na poziomie kodu i api, jakie udostępniają. Faktycznie tam może być obiekt, a może to też być też sam url.
ŁK: Tak, ja wtedy źle zrobiłem.
SW: Domyślam się, że chciałeś, co innego zrobić.
ŁK: Tak, co innego, więc to też pokazuje, że trzeba trzeba myśleć.
SW: Jeszcze kontyunuując ten cały pomysł, że platformy są niedojrzałe, to też powiedzieliśmy sobie, że mamy niedojrzałe wzorce, platformy. Został jeszcze ostatni kawałek – wdrożenia. Nie do końca wiemy jak to zrobić dobrze. Wersjonowanie możemy sobie w teorii zrobić. Mam wrażenie, że jak patrzę na zespoły, które myślą jak to zdiplojować, to jeszcze jest takie chodzenie trochę po omacku, bo widzą, że mają duże możliwości, ale do końca jeszcze nie wiedzą jak je wykorzystać. Testowanie, wdrażanie. Jeszcze jesteśmy na drodze wiedzy jak zdiplojować A tam gdzie widzimy możliwości jest fajne. Dla mnie jak widzę Serverlessy to jest uber fajnie diplojuje, przez jaki długi czas. Akurat wyszedł w ogóle raport niedawno, że w kwartale byli chyba dwa miliardy w plecy. Trudno. Oni robili tak, że po prostu za każdym razem diplejowali nowy serwis w nowej wersji i jak ogarnialii temat czy ktoś używa tego serwisu. Przez monitoring. Co z tego, że postoi pół roku i nikt nie używa. W Serverless jest tak, że jak nikt nie używa to nie płacimy. No płacimy za storage, którego cena jest minimalna. I to jest to jest fenomenalny i chyba jedyny sposób na robienie takich prawdziwych mikroserwisów na poziomie organizacji, która nie jest w skali Ubera.
ŁK: No coś w tym jest, ale to podsumowując CICD jest prosty dla pojedynczych instancji. W założeniu może być powtarzalny.
SW: Może być, wersjonowanie może być też łatwe, natomiast ogarnięcie całości systemu opartego na mikroserwisach, a szczególnie w serverless już jest mocno nietrywialne. Wchodzimy w same problemy tylko mamy to podzielone w mniejsze instancje.
ŁK: Tak jak powiedziałeś o wersjach w nie, którym miejscu, no to zobacz przy wersjach, jeżeli zapniemy się na tę samą szynę, zapniemy sobie dwie wersje usługi, czy walczenie potem to, co wspomniałem o braku service discovery. Jak już zaczynasz, mówisz o tym o diplojowaniu nowej wersji z tym, no to już nie jest trywialne.
SW: Canary deployment cały jest mocno mocno nietrywialny. Mamy zrobione ładnie Canary deployment na poziomie up serwisu, gdzie deployment sloty, tu już jest trochę gorzej. Taki dobry dobry deployment nie jest taki prosty. Dobra ponarzekaliśmy. Jakie są plusy?
ŁK: Czy wiesz, co to ja jeszcze może rzucę przed plusami, rzucę troszkę inny. To będzie teraz moja perspektywa. Serverless musi stac się commodity.
SW: Oo temat, w którym się trochę się nie zgadzamy. Dobrze dobrze.
ŁK: Tak, bo to pewnie będzie się zdarzało. O co mi chodzi. Jest taki problem, że ci dostawcy mają troszkę inne filozofie implementacyjne i to nie jest już to, co mogę, jako architekt nazwać szczegółem, detalem implementacyjnym.
SW: Tak, co więcej wraz z upływem czasu te pomysły się rozjeżdżają. Durebul wygląda inaczej niż step factions. Inny w ogóle pomysł. Durebul jest w kodzie, step factions są deklaracyjne.
ŁK: Niby jest ten no js framework Serverless, ale to też są inne filozofie.
SW: On nie przykryje aż takich różnic.
ŁK: Tak, trzeba przepisywać kod.
SW: Tak, zgodzę się. Zgodzę się z tym argumentem. Dla mnie jest, co innego, jeżeli wchodzimy w Serverless, to reszta systemu raczej będzie, jako usługa, więc godzimy się wender lockiem. Po prostu jest. Nie można być agnostycznym od platformy i oczekiwać, że wszystkie fajne będą spływały. Jak się odcinamy, to bierzemy delores common denominator i realnie mamy bardzo prosty interfejs i gadamy z najprostszą bazą danych i tak dalej. A tu po prostu wchodzimy w konkretnego vendora, korzystamy z tego jak on to robi, korzystamy z usług innych, które oferuje, które jak sam powiedziałeś, to są realne systemy Sercerlessowe i to jest coś, z czym po prostu trzeba być okej. Więc masz rację. Ja mam trochę inne podejście.
ŁK: Tak. Ja patrzę z takiego zrzutu bardziej też strategicznego na to, że wszyscy, kontenery, Kubernetes, wirtualki, stały się mocnym commodity.
SW: Tak bardzo mocno w tym kierunku idą. Dokładnie.
ŁK: Tak Kubernetes tak tam ma swoje ten, ale jeżeli popatrzymy na część aplikacyjną, nie mówiąc o usługach w ogóle tam, wokół, bo nie oszukujmy się najdroższy, chociaż i tak najdroższa jest zawsze baza danych, to od tej strony aplikacyjnej no tak, kontenery, gdzieś są najbardziej takie commodity teraz.
SW: To może być temat na rozmowę, czy pójdziemy w Serverlessa, czy Kubernetesa. Ta przyszłość jest ciekawa naprawdę. Naprawdę nie wiem, gdzie to się skończy.
ŁK: Dobra to mówiłeś o zaletach.
SW: Ty miałeś jeden bardzo fajny argument do użycia Serverlessa.
ŁK: Tak dla mnie Serverless i to będzie dla mnie królem, czyli budowa NVP.
SW: W 100% się zgadzam. Jeżeli chodzi o prototypowanie, czas dostarczenia, żeby pokazać coś ludziom, pokazać biznesowi nasz system i inne rzeczy, przetestować realne działanie, no to sorry nie da się zrobić nic szybciej. Po prostu siadasz, setapujesz projekt i lecisz.
SW: Tak i ja jeszcze zawężę to, prototypowanie integracji z innymi systemami w formie NVP na szybko. Od groma przykładów w ogóle Derverlessa to jest na integrację, z czym, uwaga ze slackiem. Zrobienie webhooka, który potem dalej przeprocesuje. To jest genialny przykład użycia i się podpisuje rękami i nogami po tym.
ŁK: Tak to druga rzecz, którą dobrze powiedziałeś przy kosztach. Jeśli nie działa, nie płacisz.
SW: Płacisz bardzo bardzo mało za storage, ale tak. Można uprościć, że nie płacisz.
ŁK: Nie płacisz, ja mówię o samym kodzie, jak trzymamy samą część aplikacyjną, bazodanówka to jest zupełnie inna rzecz.
SW: Zgodzę się i to jest fenomenalne, też może być ryzykowne, bo nagle możemy obudzić się z takimi 30 fanction upami i no żyją, niby za nie nie płacimy albo płacimy parę centów rocznie, że ktoś może używa i teraz co to właściwie jest. To też może być ryzyko, więc też nie należy się zachłysnąć, ale zgadzam się. Ryzyko, że coś żyje i nie zostało ubite jest zawsze i to trzeba o takie rzeczy dbać. Kosztowo to jest super idea.
ŁK: To jeszcze rzucę takie trochę odmienne, bo mówimy, że świetne kosztowo, ale przy dużym wykorzystaniu.
SW: Przy dużym wykorzystaniu to kosztowo jest świetne, ale, dla kogo innego, dla providera.
ŁK: Tak przy dużym, ja chyba widziałem takie wyliczenia, że tak powiem, to już jest skala fajna, bo to projekty, żeby uświadomić, o jakim targecie mówię, tutaj mówiłem o przetwarzaniu danych, o generowaniu webhooków, o automatyzacji przy 50 000 - 60 000 użytkowników. To są już fajniejsze skale, więc to też będzie moja perspektywa. Kiedy będzie drogo. Tam było już w diabły wywołań i jeszcze jak wziąłem, założyłem, pamiętam, że w kalkulacji założyłem, że ten kod nie będzie optymalny, że będzie trzeba poczekać, to takie wywołania kosztują drogo. Rynek też pokazuje, że te kosmiczne liczby z kalkulatorów się potwierdzają. Był znowu fajny tweet z jednej firmy, gdzie zeszli z Lambdy, z 32 tysięcy dolców miesięcznie, Lambdy i API Gateway na półtorej tysiąca za kilka wirtualek i dwa miesiące pracy developerów, żeby przepisać to i użyć tego modelu aktorowego rozproszonego.
SW: Ale to fajnie pokazuje i nawiązuje do tego, co mówiliśmy w poprzednim odcinku, że wpierw robimy NVP, patrzymy czy ktoś tego używa, jak tam jest z biznesem, czy to jest to czego chcieli, jak jest to przepisujemy.
ŁK: Albo zostawiamy, bo godzimy się z kosztami, bo się opłaca.
SW: Tak to jest decyzja biznesowa generalnie, czy zostaje czy nie zostaje. To co mówiłeś też wcześniej good enough jest good enough.
ŁK: Tak.
SW: Jeżeli biznes jest okej z płaceniem 30 000, bo gdzieś mogą dalej uzyskać pół bańki, jest okej, nie ma co się tym frustrować. Dobrze, ale czasami kopnie nas to, co mówiliśmy wcześniej – limity. Tych limitów trochę jest i chyba warto byłoby o nich porozmawiać i skupić je w jednym worku. Co nas ogranicza?
ŁK: Dobra to taka pierwsza rzecz to było trochę z moim commodity. Biorąc pod uwagę to, że narzucają nam filozofie.
SW: Tak ta filozofia jest, ale ona czasem jest dobra.
ŁK: Tak, nie jest zła. Plusem tego będzie właśnie to, co powiedzieliśmy, zmuszenie do event-driven.
SW: Tak ogromny plus.
ŁK: To jest ogromny plus przy de cloudowych i rozproszeniu. Zmusza nas do myślenia. Z Twojej strony?
SW: Z mojej strony tak patrząc na to, co się dzieje często i co słyszę na warsztatach to jest to, że czasami mamy potrzeby wgrania coś wewnętrznego z konfiguracji jakiegoś podpisu i nagle zaciąganie tego między różnymi usługami, jak mamy system korporacyjny one często wymagają różnych dziwnych zależności. Albo odpalenia jakiegoś egzeka i tak dalej. I wtedy zaczyna być to takie karkołomne. Rzumiem, czemu nie możemy tego zrobić, ale realnie często prowadzi do tego, że nie możemy mieć takiego czystego fasa.
ŁK: Tak jest tam, gdzieś w filozofia, troszkę mi się podoba rzeczy z AWS, jest Lambda liar, gdzie możemy przynieść, ale tylko linuxowową binarkę.
SW: Co nie dziwi mnie w AWS oczywiście.
ŁK: Jest gdzieś tutaj filozofia. Jest ta filozofia fajna, ale też nie jest przenaszalna, bo gro dziwnych komponentów.
SW: Tak ten świat się mocno ewoluuje przez ostatnie 3 lata. Więc to będzie coraz mniejszy problem bym powiedział.
ŁK: Tak, ale jest druga rzecz sieciówka.
SW: Tak Twój temat, ja nie jestem orłem.
ŁK: Tak, w zależności od platformy sposoby, brak prywatnego IP, brak możliwości dobrego sfajerłolowania w niektórych przypadkach, bądź kombinowanie. No gdzieś to boli, bo trzeba zmienić filozofię myślenia o tym, w szczególności, że to się znajduje zupełnie poza naszą kontrolą.
SW: Tak to prywatne IP, możemy się oburzać, ale to często naprawdę ma sens z punktu widzenia korporacji. Naprawdę ma sens, tym bardziej, że powiedzieliśmy, że dostęp do funkcji jest taki jaki jest. Sekret.
ŁK: Wiesz, co sprawdzę jedną rzecz, bo nie przygotowałem się w tym, jak było w AWS, w Lambda, private… Tak jest privite. Mają tam zupełnie inne architektury.
SW: Wszyscy też często się dziwią, czemu musi być unikalna nazwa. Bo jest publiczny. Ale to też może ewoluować. Na chwilę obecną te limity są takie, jakie są. Dla mnie z zalet, bo trochę ponarzekaliśmy, jedyny case, kiedy realny jest przypadek, kiedy w mikroserwisach będziemy mieli wiele języków w jednym systemie, oczywiście tych wspieranych, bo nie oszukujmy się, często te całe API nam powoduje to, że no sorry nie będziemy mieli będziemy mieli r-langa, Javy i wszystkiego innego w jednym systemie opartym na mikroserwisie. A tutaj faktycznie realnie mamy. Na tyle zostało dużo z platformą odcięte, jest poza naszymi możliwościami, że zaczyna być realne posiadanie np. .NET tak ogólnie w jednej platformie. Co więcej, z mojego punktu widzenia to jest nawet wskazane. Pewne rzeczy po prostu lepiej jest zrobić w node.
ŁK: Tak, można łatwo wybrać język, który potrzebujesz w zależności od tego, co potrzebujesz, czyli taki prosty kod szybki możesz klepać w node bez problemu, a tam gdzie masz więcej filozofii biznesowej, możesz przenieść sobie do CSharpa i tam się tym bawić, czy możesz równie dobrze wymieszać, tam jeszcze Pythona, dorzucić nutkę Javy i będzie to może jakoś działało. Ja czekam aż golang trochę mocniej będzie wspierany, bo to będzie w paru miejscach, może być ciekawe.
SW: Chyba Google wspiera teraz…
ŁK: Tak, to w AWS też jest. W Azure, w dwójce dzieje się. Jest informacja na temat trwającego privite preview. Ono jest za zamkniętymi drzwiami, ale też tam dzieje się dodanie do tego, więc to dość ciekawie też wygląda.
SW: Będzie ewaluowało, ale to jest fajny przypadek dla firm, które nie są Uberem, Googlem, i tak dalej. Możemy faktycznie mieć wielotechnologiczny stos jedyny. Dobra chyba podsumowujemy dyskusję.
ŁK: Ty zaczniesz?
SW: Mogę zacząć. Dla mnie punkt pierwszy Serverless to jest godzenie się z wenderlockiem. Obchodzenie tego nie ma sensu, bo nie wykorzystanie czegoś takiego jak turbo factions czy step factions, zależy, w którą platformę pójdziemy jest slabym pomysłem. Pogódźmy się z tym faktem i lecimy dalej tak naprawdę. Co u Ciebie?
ŁK: Dobra to ja trochę tak jak podszedłem tez z NVP. To jest największa zaleta. Jeżeli trzeba coś zrobić nowego, to jest to świetny sposób do prototypowania czy też dodawania do nowych funkcjonalności, w szczególności jak zrobiliśmy jakiś lift-and-shift aplikacji, bo jest to przez providerów cloudowych bardzo promowane, zrób pan lift-and-shift wirtualki i systemu, monolitu i innych rzeczy i rozbudowywanie tego o nowe funkcjonalności.
SW: Zgadzam się, jak najbardziej. To ja od siebie coś dorzucę. To, co chyba obaj mówiliśmy, nakłanianie do dobrych wzorców. Microsoft miał też takie podejście nakłaniania do dobrych praktyk. Pójdźmy do tego pitfola, bo tam jest dużo fajnych skarbów i dobra architektura, łatwo można to zrobić i jest bardzo fajne wsparcie do robienia systemu dobrze. Ta platforma nagradza dobrą architekturę. To jest pierwszy chyba taki case jak patrzę tak wstecz na całą historię IT, która się wokół niej obracała.
ŁK: Dobra to lecąc po Twoim, modelowanie, czyli świadome będą te nanoserwisy i inne rzeczy w niektórych miejscach, trzeba się pogodzić, ale świadome ich modelowanie, że to jest bardzo istotna rzecz, że musimy świadomie to modelować, w jaki sposób to będzie budowane, troszkę te łańcuchy wywołań, zastanowić się czy przypadkiem nie można tego porozbijać, czy ten kod musi być. Tutaj akurat dochodzisz do factions te fasy nie muszą mieć tak długiego kodu jak mówiliśmy o mikroserwisach. To jest inny przypadek, więc tu jesteśmy nagradzani za to, że tak kody będą zwięzłe i dobrze jest robić offloading do innych usług, które są już, bo często ten kod też się integruje z innymi rzeczami. Więc właśnie modelowanie, nanoserwisy, żeby pomyśleć, jak to zrobić.
SW: Zgadzam się jak najbardziej. Ja na koniec rzucę jeszcze ostatni taki trochę zadzior. Jestem ciekawy i Ty chyba też jesteś ciekawy bardzo mocno, jak się będzie miał Serverless do serwis nasza, bo trochę Service mesh. Trochę Dervice mesh coraz bliżej tego tematu of loadingu, szczególnie, jeżeli chodzi o Kubernetesa, weźmiemy Service Fabric Microsoft, zaczyna być coraz bliżej, więc to może być bardzo ciekawe połączenie i gdzie się skończy za rok, dwa, jak to będzie wyglądało. Trzeba będzie uważać.
ŁK: Tak. Serverless jest gdzieś tą architekturą na najbliższe lata. Podejście jest dobre, bo zmusza nas do skupienia się na kodzie, a nie na platformie wreszcie. A to jest duży plus.
SW: To, co tyle.
ŁK: Tyle.
ŁK: Kończymy.
SW: Kończymy. To do kolejnego.
ŁK: Na razie.
SW: Na razie.