Szymon Warda [SW]: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda

Łukasz Kałużny [ŁK]: i Łukasz Kałużny. Klasycznie wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io/55. Linki też macie w opisie, więc możecie z nich przejść wszędzie (również na nasze social media). Dobra, Szymon, to co masz?

SW: Wygrzebałem takiego… Myślałem, że głupiego tweeta, ale chodził za mną praktycznie cały dzień i jest ultrakrótki. Mianowicie brzmi: Autoscaling is an anti-pattern, autoskalowanie jest antywzorcem. No i… Czym więcej o tym myślę, tym bardziej dochodzę do myśli, że faktycznie dużo w tym jest. Często polegamy na autoskalowaniu. A, de facto, z naszej wiedzy to jest tak… Znaczy – wyłączmy w ogóle z dyskusji kompletnie funkcje: Azurowa, AWS-owa itd., bo to jest zupełnie inna bajka, on składa się dość szybko, powiedzmy sobie, w tych swoich schodkach. Ale powiedzmy tak: skalowanie maszyn wirtualnych. No tutaj mówimy o czasie 5 minut plus. I od razu mówię: też wyłączamy autoskalowanie… Kronowe jest w porządku, tylko takie autoskalowanie w wyniku obciążenia CBU, pamięci i innych takich rzeczy.

ŁK: Wiesz co… To inaczej. Popatrzę… Tak jak powiedziałeś Crona, to już mi uwaliłeś dyskusję częściowo. Bo tu się zgadzamy, ono jest…

SW: Kron ma sens.

ŁK: Kron ma sens. To słuchaj, jest tak… Jeżeli popatrzysz na autoskalowanie, to zależy o czym mówimy. Bo trzeba sobie zrzucić dwa konteksty, czyli to, co rzuciłeś: Cloud i on-prem. Bo to są dwa w ogóle oddzielne wątki.

SW: Zgadza się.

ŁK: Dwa zupełne oddzielne wątki. I teraz do czego… Moja perspektywa na cloude’owe. Wyrzuciłeś też funkcję i okej, zgadzam się z Tobą, więc jeżeli mamy te workcloudy na VMk-ach…

SW: Wielki K8s.

ŁK: i K8s-y, to słuchaj, jest jedno świetne pytanie: co ten kod robi pod spodem? Bo jeżeli jesteś w stanie wydzielać rzeczy kolejko… Zacznijmy od tego, że trzeba ten świat podzielić. Zresztą, jak Ty ładnie dzielisz ten świat na synchroniczny i asynchroniczny.

SW: Tak. Kolejkowa, którą stosuję jest łatwiejsza. Tak.

ŁK: Tak, więc tam to nie jest anti-pattern, bo jeżeli sobie popatrzymy… Przy skalowaniu requestów, to tak z mojej teraz perspektywy patrzę zupełnie, tak na gorąco.

SW: Przez requesty mówisz http.

ŁK: Http. Synchroniczne, o.

SW: Synchroniczne. Tak.

ŁK: O, wywołania synchroniczne. O tak. To będzie lepsze określenie. To zabawa polega na tym, że tak, walczymy z tym, co powiedziałeś. I teraz zabawa przy autoskalowaniu jest następująca. Ja mówię… Dlatego większość nie umie robić antyskalowania. Dlatego mogę się zgodzić z tym tweetem, bo większość ludzi nie chce poznać charakterystyki swojego systemu.

SW: Ale, nawet załóżmy, że poznają swoje ryzyka, czyli żeby ładnie zareagować na…

ŁK: Na ping.

SW: …żeby autoskalowanie było rozwiązaniem problemu, to musiał byś wybrać sygnał jakieś 5 minut wcześniej.

ŁK: Wiesz co, dlatego sprzedam swój timming i też potem dam do niego linka, bo został opublikowany. W przypadku K8s np. bo jest taki duży. W przypadku K8s-ów jesteś w stanie… częściowo zahakować, użyć K8s-a, tak jak jest przeznaczony pod spodem jego mechanizmów i mieć zawsze jeden nod więcej gotowy do wzięcia. Ale to jest inaczej… To jest świadoma konfiguracja. I wtedy to, co powiedziałeś, ten czas przy dobrze zrobionej apce skraca się gdzieś do 30 sekund odpowiedzi na autoskalowanie na ping.

SW: Około minuty wyjdzie. Ale okej, tak.

ŁK: Jesteś w stanie 30 sekund - 1 minutę. Powiedzmy, że jeżeli przechowujesz obrazy, jesteś w stanie zejść do 30 sekund.

SW: Tak. Ale i tu Cię teraz generalnie… Bo miałem podobne myślenie, ale jego dalszy tweet wyjaśniający mówi, że lepszą praktyką jest posiadanie zasobów, które będą lekko under-provision. Czyli będą generalnie miały wolne miejsce. I w razie czego właśnie doskalujcie do swoich wymiarów. Bo… Miałem powiedzieć… W tym sensie chodzi o to, że generalnie, Ty masz tego computer… Powiedziałeś, że mam tę maszynę, czyli właśnie mamy ją odrobinkę under-provision i ewentualnie rozszerzam ilość podów na nią, tak naprawdę.

ŁK: Tak, dokładnie. Wiesz, i to jest tak, czyli…

SW: I to zadziała.

ŁK: I dokładnie o to chodzi. I tak, właśnie o to… Cały myk polega na tym, że autoskalowanie potrzebujesz… Powiedzmy sobie tak, bo wykluczyliśmy Krona. Harmonogram jest Ci potrzebny, kiedy spodziewasz się pingów. Koncert, Black Friday, zakończenie miesiąca…

SW: Wiadomo.

ŁK: W bankach płatności ZUS-ów i innych podatków. Więc jest ileś takich sytuacji, które jesteś po Kronie i to działa… Sam wiesz zresztą, że to jest najprostszy możliwy sposób i działa wszędzie.

SW: Kron jest w ogóle fenomenalnym sposobem.

ŁK: Tak. I schodzisz. A na nieprzewidziane, niestety, to jest pytanie, jakie masz SLA biznesowe. Znowu wejdę właśnie, czy jest ta głupia dyskusja, która mówi troszeczkę też z googlowych paperów, że niestety czasami coś nie zadziała i trzeba zrobić retrie. To jest pytanie, jak bardzo chcesz się przygotować na takie rzeczy.

SW: Tak, ale też dochodzisz do tego, że właściwie autoskalowanie… Znaczy, bo… Ja to też ugryzłem trochę z innej perspektywy. Z perspektywy tak naprawdę zespołu platformowego, który do końca nie wie, co dostaje do utrzymania w tym klastrze. To doskonalenie jest wymagane, bo ono de facto co pozwoli? Pozwoli określić realny charakter systemu.

ŁK: Tak. I pozwoli…

SW: Tu ma sens.

ŁK: Tak. I w Cloudzie pozwoli Ci na realne oszczędności.

SW: Jak najbardziej tak. Będzie to wymagać od autoskalowania w kontekście właśnie dynamiczne. I zarówno horyzontalne i wertykalne. Jak najbardziej generalnie to tutaj ma sens. Ale z punktu zespołów deweloperskich, które się często zasłaniają i mówią: a to się wyautoskalujemy. Autoskalowanie nie powinno być właśnie tą główną odpowiedzią.

ŁK: Raczej nie. Autoskalowanie, wiesz co… To w ogóle powinno być z metryk. Zawsze powtarzam, jak ktoś już przyszedłby do mnie na szkolenie, konsultacje, zawsze powtarzam, że w większości aplikacji sygnał na zasadzie memory i CPU w ogóle nie ma sensu do autoskalowania w dzisiejszych frameworkach i rozwiązaniach. Tylko, de facto, wiesz… A zdobycie, tak jak mówisz, przy asynchroniczności, idąc do tego już upierdliwego K8s-a, ale co tam. Już weźmy, bo to jest…

SW: Głównie o nim mowa.

ŁK: Tak

SW: Doskonale wiemy, jak jest nierealne, powiedzmy sobie.

ŁK: Raczej…

SW: Ciężkie bardzo, może tak.

ŁK: Może inaczej. Wymaga od Ciebie naprawdę chęci robienia tego. O. To tak nazwijmy. Chęci i świadomego modelu. Bo zobacz, że AWS… W AWS-ie 10 lat temu to działało. To był wzorzec podstawowy, deployment na…

SW: Tak, tak, tak.

ŁK: …na Keling grupy? Dobra. Idąc do K8s-a. Kolejki opakowujesz prosto, bo masz Kerdel np. i zapinasz je na metryki na kolejkach.

SW: Tak

ŁK: I z drugiej strony, Keda również pozwala Ci obsługiwać sygnały z jakichś ingress controller, Prometeuszów.

SW: Tak, systemów, dokładnie.

ŁK: Tak, z systemu. I cała zabawa jest powiedzeniem – coś, czego nienawidzimy robić – to jest powiedzenie, jakie capacity na ilość requestów ma nasza instancja. Bo zobacz, że jeżeli sobie nawet na syntetycznym ruchu powiesz, ile w 200 milicorach CPU, ile instancja RPM-ów osiągnie, to, co powiedziałeś – jesteś w stanie zrobić agresywne skalowanie przy pingu po prostu.

SW: Tak, tak, tak. Ale po pierwsze: o klientach danego scalling kalkulatora tak naprawdę, czy określenie wymagań, że przy X requestach potrzebujemy X instancji, czyli obsługuje Y tego, to jest dość konieczne. Ale to dalej właśnie… Bo mówisz, że w tym momencie okej. Może on się składać Kedą itd. Keda jest super, bo faktycznie umożliwia skalowanie dużo wcześniej, zanim ta fala przyjdzie. Ale… to podajesz. Tak, też stosuję, jak na razie. Tylko problem będzie teraz taki, że zanim nawet się wyskalujemy w ciągu tych 30 sekund - 1 minuty, to ileś tam requestów będzie chodziło…

ŁK: Wolniej.

SW: Cholernie wolno.

ŁK: Raczej nie, dlatego powiedziałem o agresywnym. Czyli powinieneś mieć na tych regułach autoskalujących. Zrobiłem to, co powiedziałeś, ten under-provision, że te instancje mają capasity. To… inaczej. Cała zabawa polega na tym: jeżeli chcesz obsłużyć ping, będziesz za to płacił kasę.

SW: Tak. Cały czas. I ewentualnie trzeba sobie zbudować takie bufory, że pierw masz z under-provision zbudowaną maszynę generalnie, ona przyjmie to, i potem kolejną, kolejną będziesz tworzył.

ŁK: Tak, bo… I dostajesz czas na obsługę tego przez maszynę. I cała zabawa, to moja perspektywa, cała zabawa polega na tym, czy w ogóle Ci się opłaca to kalkulować.

SW: A ja bym to ugryzł z innej strony. Nie, czy się opłaca, tylko czy faktycznie autoskalowanie będzie tą złotą odpowiedzią, która jest często stosowana. Może inaczej: w jakim kontekście jest często zastosowana? Wydaje mi się, że nie będzie. I to jest taki właśnie… Jak będzie ping, będzie większy ruch, to będzie wielki smuteczek.

ŁK: No… Więc, ja inaczej…

SW: Więc bym się z tym zgodził bardzo mocno.

ŁK: Wiesz co, jest to częściowo. Ja powiem tak, dla mnie taką wyjściową rzeczą jest to, że zróbcie Krona i tak już jest przynajmniej połowa oszczędności na compute, jak w nocy zejdziecie, a na consumery wdróżcie kolei i po prostu skalowanie od zera Kedom i tyle. Z cronem w ciągu dnia, żeby odpowiadało szybko. Sorry. W większości przypadków i systemów w szczególności – nie oszukujmy się, większość pisze systemy internallowe.

SW: Tak. Gdzie w sumie to najczęściej poczeka, nie oszukujmy się.

ŁK: Tak. Więc to jest tak: jeżeli piszesz frontową aplikację, która może dostać po łbie, to prawdopodobnie… To jest stara opowieść, jak się ludzie chyba w Victorii sekretnie wyskakiwali infry, jak poszła reklama na Super Bowl czy gdzieś, bo marketing nie powiedział, że puszcza reklamy.

SW: (śmiech)

ŁK: I tam akurat… Nie do końca, bo tam też był amerykański styl zamawiania przez telefon, więc infolinia też dostała po dupie i call center, jak dostało DDoS-a. Ale wiesz… cały myk polega, że da się to przewidzieć.

SW: Tak, ale to do tego zmierza: że możesz przewidzieć, bo Kron jest formą przewidzenia tego de facto. To zapewni 90% przypadków użycia. To włączenie skallera w K8s-ie i gdziekolwiek indziej, nie będzie takim super rozwiązaniem, jak nam się często wydaje.

ŁK: Dobra. To weźmy teraz…

SW: Co u Ciebie?

ŁK: Wiesz co, miałem parę rzeczy. Coś tam czytałem, ale to zostawmy. Kilka odcinków temu mówiliśmy, czego byśmy użyli, jakbyśmy coś robili. Na zasadzie stosu technologicznego. I tadam! tadam! W zeszłym tygodniu musiałem sobie parę rzeczy narzeźbić, że tak powiem, do save projectów. I z tego, co opowiadałem, to dotknąłem. O tak, tego stosu, żeby nie było, że go nie używam. I też parę nowości dotknąłem. Więc… Lecąc całym tym stosem, potrzebowałem zrobić parę takich webowych rzeczy, trochę back-endowych. I czego użyłem? Zaczynamy. Dotknąłem TailWind, TailWind CSS, i tu… Kurde, ja wreszcie mogłem coś zrobić w jakiś rozsądny sposób, żeby nie odrzucało. To była w ogóle magia przy prostocie używania tego.

SW: Znaczy, właśnie się temu przyglądam i wygląda nieźle. Nie, Łukasz, swoją reklamą, że nawet u Ciebie wyglądało dobrze. To jest dobre. Oczywiście żartuję. Ale wygląda sensownie.

ŁK: Następną rzeczą, którą z takich odkryć, jak wejdziesz na stronę Architektura i kontenery, to jest to, co tej konfry, którą prowadziliśmy. To akurat jest właśnie moje dzieło na TailWindzie wyklikane, więc widzę twoje niedowierzanie. (śmiech)

SW: Wygląda nieźle, bym powiedział.

ŁK: Więc tak.

SW: A dużo rzeczy widziałem.

ŁK: I druga rzecz, którą odkryłem, to są… Bo powstaje masa różnych edytorów graficznych do robienia front-endu i innych rzeczy. Jest polski produkcik, nazywa się shuffle.dev. I oni mówią, że to jest dla basicdeveloperów i mają gotowy zestaw ponad 6000 komponentów UI do różnych frameworków, zrobiony właśnie na bazie TailWind. I co lepsze: mają gotowy generator, który Ci wypluwa cały zainicjowany projekt w Node albo w statycznym HTML’u. I nagle się okazuje, że mają właśnie widoki do dashboardów i innych rzeczy. Więc po prostu genialnie! Jako sierota front-endowa potrzebująca coś zrobić, układałem sobie to, co potrzebowałem zrobić i wypluwało mi gotowy dosłownie HTML cały responsive do użycia. Więc zrobienie jakichś back-end’owych dashboardów i innych rzeczy – to u mnie wygrało. Kolejną rzeczą od twórców TailWinda są komponenty. To jest też TailWind UI - zestaw gotowych komponentów i ich szablonów. Więc tak samo… Naprawdę byłem zdziwiony, że z tym mi idzie. I potem potrzebowałem to gdzieś ubrać, no nie tylko w statycznym HTML, więc potrzebowałem w coś ubrać. Nie chciało mi się do końca pisać w waniliowym JS-ie wszystkiego, ani też tak naprawdę pakować się w jakieś ciężkie frameworki w jednej rzeczy. Więc sobie czegoś takiego, co się nazywa Alpine JS, przez twórcę jest określany właśnie TailWindem dla JavaScriptu. I daje bardzo leciutki, bardzo mały framework. De facto ma 15 atrybutów, 6 propertiesów, 2 metody. Na całość. I daje…

SW: Oszczędne, właśnie widzę.

ŁK: Tak. I daje wiesz - dokumentacja jest genialna po całości, jeżeli tam popatrzymy. Jest bardzo leciutki, daje super możliwość zrobienia, napisania reaktywnie całości, gdzie są śledzone wszystkie dane, którym jest cały model i zrobienia kawałka bardzo przyjemnego, prostego frontu. Na zasadzie: robisz import i lecisz z użyciem tego. Więc to było genialne. I potem hostowanie i back-end. Cloudflare oczywiście wygrał w tym przypadku. Więc poleciałem z cloudflarowymi workerami oraz Cloudflare Pages, które było zapinane. CI/CD, bo to jest w ogóle genialne. Pages w workerach - zapinasz po prostu do repo do GitHuba i mówisz, który branch ma autodeployować, i którą komendę z NPM-a odpalić. Więc tutaj…

SW: No… taki częsty CI/CD jaki weźmiesz dla tego typu stron.

ŁK: Tak, tak. Proste, genialne. Do tego drugi kawałek, bo z tego TailWind UI-a korzystałem z takiego gotowca do dokumentacji. On jest zrobiony na nestJS i pierwsze wrażenie jest na bazie reacta. NestJS to nakładka na framework na bazie reacta. Żeby zrobić…

SW: To konkretnie kojarzę

ŁK: Co? Tak. To tak: ładnie wyglądająca, przepraszam - nie nest tylko next.js. Przepraszam. Next.js. Walnąłem się. Ładnie wyglądająca, był gotowiec piękny do dokumentacji. Musiałem dodać sobie uwierzytelnianie, parę innych rzeczy. I takie pierwsze wrażenie, tak jak ten TailWail, Alpine – świetnie, to przy Nextcie już takie mocno przekombinowane do prostych rzeczy. To było takie moje wrażenie. Aczkolwiek z gotowego szablonu wyszło mi coś, co w ogóle pięknie wygląda, pięknie działa, ale przekombinowane. I tutaj taki rant w stronę tego wszystkiego, co wymieniłem, poza Alpine i Tail Windem, ale ogólnie, bo tam jeszcze było w miarę okej, dokumentacja i tutoriale do tego wszystkiego ssie. Te dowcipy na temat wersji frameworków, że wychodzi co chwila update i inne rzeczy, jak szukasz i googlujesz wiedząc nawet, czego szukasz, to trafiasz na starsze wersje, niedziałające rozwiązania etc. Więc żarty o front-end, że co chwilę się coś nowego pojawia i rozjeżdża, wszystko, co… Dotknąłem teraz tego.

SW: Wygląda nieźle. Gratulacje! Gratulacje konferencji.

ŁK: Tak. A! No i na koniec: Make.com, czyli load code do integracji. Sorry, przy takich side projektach…

SW: Idealnie, że dotknąłeś load code. Mam do tego dobrego linka.

ŁK: No.

SW: Znowu, jak już mam refleksje i inny motyw.

ŁK: Dobra, to dajesz.

SW: GitHube wydał fajny, zobacz sobie link, który właśnie Ci wysłałem.

ŁK: Dobra.

SW: GitHube wydał fajny link od Google właśnie. Jest, no nie?

ŁK: Code as policies.

SW: Tak. Code as policies. Zobacz, i o co chodzi? Chodzi o to, że wcześniej jak AI… AI ma sterować robotami. Wcześniej AI generował po prostu kod od razu bezpośrednio, a teraz zobacz na pierwszy kawałek kodu. De facto ten kod generuje… Kod ładnie zmoduleryzowany.

ŁK: Mhm

SW: Poprawny kod, naprawdę dobrze wyglądający. Czyli są funkcje główne i są funkcje rozwinięte. Ale do czego teraz dochodzi? Po pierwsze, pierwsza myśl moja jest taka, że wydaje mi się, że ostatni rozwój AI i generowania kodu itd. to pokazuje jedno: że load code odchodzi, a zastąpi go właśnie kod generowany przez AI albo przez jakiś właśnie team helperów.

ŁK: Wiesz co? Zgodzę się z Tobą, że to będzie kierunek. W szczególności też Microsoft coś tam pokazał z flowem. Jest tylko jedna rzecz, która żeby to wszystko działało. Trzeba te modele nakarmić albo muszą być zrobione wreszcie poprawnie konektory, albo musi być aktualna dokumentacja i sample wethutów. I pilodów, które są przesyłane.

SW: Tak. Ale teraz jest druga myśl w ogóle, która mnie zastanowiła, i to taka już bardziej meta. Zastanawia mnie jedna rzecz. Jak my dorastaliśmy, byliśmy w szkole, to często mówiono nam generalnie: ucz się matematyki, bo nie zawsze będziesz miał kalkulator w kieszeni. To okazało się nieprawdą powiedzmy delikatnie. Zastanawiam się bardzo mocno, czy tak naprawdę w tym samym kierunku nie pójdzie AI i w ogóle wsparcie, jeżeli chodzi o kodowanie. Teraz uczymy niskopoziomowego stuffu de facto, który oczywiście jest ważny, jest sensowny, ale tak naprawdę robota za powiedzmy lat 10, mówimy powiedzmy o naszych dzieciach za 10 lat, to nie będzie takiej opcji generalnie, że oni skupią się bardziej na tym, że będą mieli AI zawsze w kieszeni czy też w pracy tak prawdę. To będzie bardziej weryfikacja tego, co tam się wydarzyło. I to było fajne zdanie, że jeżeli ktoś chce być dobrym developerem za kilka lat, to czy nie lepszym obecnie postawieniem kasy będzie to, żeby nauczyć się dobrze te wszystkie autogeneratory obsługiwać i generalnie korzystać z ich mocy. Tak samo jak korzystanie z C# albo innych właśnie.

ŁK: Wiesz co… Dlatego ja mówię… To tak jak z Copilotem i tym czasem GPT, jak sobie rozmawialiśmy, że to jest tak naprawdę clue.

SW: Tak, to jest. Tak to będzie, jak najbardziej.

ŁK: Że to jest clue całego tego, że ten asystent… Nie mówię, że to nas zastąpi, to ma przyśpieszyć pracę osób, które wiedzą, jak to wykorzystywać.

SW: Odejdzie dużo manualnej roboty. Tak samo jak prowadzenie robotów do montażu samochodów. Dokładnie ten sam case.

ŁK: No… więc jest to…

SW: Ciekawy w ogóle artykuł jeszcze od Google.

ŁK: No, zobaczymy, jak to będzie właśnie wyglądało. To też jest do prześledzenia. Dobra, to chyba kończymy.

SW: Kończymy, na razie.

ŁK: Trzymajcie się.

SW: Hej