Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki na patoarchitekci.io albo gdzieś góra, dół. Ogarniecie temat. Dobrze, Łukaszu, co tam wyszperałeś?

Łukasz Kałużny: Prezent gwiazdkowy dla ciebie, Szymonie. Przepraszam Was, nie usłyszycie już radosnego śmiechu, ale mina Szymona jest świetna. W Visual Studio Code jest sobie taki rest client i Szymon, Ty to używasz w ogóle do dokumentowania rest calli.

Szymon Warda: Tak, dla kontekstu, co on w ogóle robi? Dla pliku z końcówką http pisze się normalny tekst i tam określasz czy to jest get, post, itd., link, ładne można body, super przejrzyste jeżeli chodzi o dokumentację, szkolenia, o cokolwiek, nawet testowanie calli właśnie z zapytania http.

Łukasz Kałużny: I taki duży plus, tam w zależności od tych, ogólnie leży sobie z IDE. To jest duży plus i z kodem źródłowym. To nie jest Postman, Insomnia czy cokolwiek otwarte na boku.

Szymon Warda: Super działa z Codem, tak. Rewelacja!

Łukasz Kałużny: I słuchajcie ja to wziąłem, bo pojawił się akurat na dev blogu Microsoftu, na ISE Developerze, jednym z tych blogów, które są właśnie API testing z http files and Rest Client, bo to są dokładnie http filesy, tak to się określa. I jedna rzecz, która mi przykuła uwagę, czego mi brakowało, to słuchajcie, coś do wywoływania tego, jakiś runner do tych testów. I okazuje się, że ktoś nad tym siadł. Jest sobie http jak i w postaci pluginu w Visual Studio Codzie, jak i po prostu paczka NPN-owa, którą można zapiąć jako runner. I co jest piękne? Można te testy załadować do CI/CD i opublikować z tego JUnit. Czyli taka pierdoła, która może ułatwić automatyzację testów API.

Szymon Warda: I przede wszystkim też wprowadzenie tego, że nie będzie to tylko dokumentacja, która tam sobie żyje na boku, ale będzie to też coś co faktycznie można ładnie optestować, można ładnie omówić. I jeszcze patrzę też wprowadzili ładnie zmienne środowiskowe, których też brakowało przez jakiś czas. Więc wygląda świetnie.

Łukasz Kałużny: Nie, nie, to tak, tutaj obsługa jest fajna, czy sposób jak zobaczymy sobie środowiska. Dużo rzeczy, które było w sumie w, jak popatrzymy, Postmanie np., czyli właśnie środowiska i inne takie rzeczy.

Szymon Warda: Bardzo dobrze.

Łukasz Kałużny: I od strony IntelliJ też jest obsługiwane, więc nie patrzcie, że VS Code, ogólnie szeroko można tego użyć. Dobra, co u Ciebie?

Szymon Warda: U mnie ciekawy link, slackowy, link podwójny właściwie można powiedzieć, bo jeden kontekst jego to jest wprowadzenie do cell architecture, czyli architektury komórkowej, można tak to powiedzieć. Nie jest to takie głupie, nie jest takie głupie.

Łukasz Kałużny: Nie, wiesz co? Nie, nie, przewinęło mi się to samo w kontekście tych kamerek Amazona. Dokładnie, też pojawiło się. Coś czuję, że zaraz na to będzie moda, na to pojęcie coraz większa.

Łukasz Kałużny: Ma to jakiś sens. Ale w ogóle o co chodzi? Chodzi o to tak naprawdę, pomysł absolutnie nie jest nowy. Może wyjdźmy od problemu, jaki miał Slack. Slack miał taki problem, że Slack w ogóle z ciekawostek, jest w jednym regionie, ale w wielu zone’ach. Ciekawe swoją drogą, no nie? I to działa tak, że mają tam ten storage centralny, który jest wysokospójny, wszystko spoko, różne regiony użytkowników, faktycznie gdzie chodzą, one idą do różnych availability zone. Te zone’y raczej komunikują się w ramach siebie, ale niektóre calle idą po prostu między zone’ami, itd. I problem, jaki się pojawił, to jest to, że gdzie niektóre zone’y miały awarię i potem mieli tzw. szary błąd, szarą awarię. Czyli że serwisy widziały różny poziom dostępności różnych serwisów i niektóre po prostu czekały, niektóre się wywalały, itd. Musieli ładnie manualnie zrobić drainage serwisu, żeby przełączyły się na działające serwisy i żeby to było spójne. Więc teraz stwierdzili, że jak pójdą, jak to rozwiążą generalnie, to problem jest taki, że zamiast mieć jeden centralny store, to zrobią taki myk, żeby serwisy, które ze sobą gadają, były w tej samej zonie, żeby nie było…

Łukasz Kałużny: Crosszone’y.

Szymon Warda: Crossover komunikacji sieciowej pomiędzy zone’ami. Więc teraz jak będzie wyglądało? Idzie request, on jest loadbalansowany na poziomie tego requestu, idzie do odpowiedniej komórki, ta komórka ma warstwę aplikacyjną, warstwę bazodanową swoją lokalną tego konkretnego użytkownika. I tych komórek może być dużo, one są automatycznie tworzone, automatycznie niszczone, bardziej tworzone w tym kontekście. I żeby mieć spójność raportową, to wszystko idzie sobie do data lejka. Czyli upraszczając ten cały pomysł do jednego zdania, mamy routing na poziomie http i izolacji na poziomie http i tworzymy shardy dla baz danych i dla warstwy aplikacyjnej de facto. Więc pomysł nie jest niczym rewolucyjnym.

Łukasz Kałużny: Raczej to też nie idzie jako pojęcie deployment stampów, gdzieś pojawia się, czyli: weź zreplikuj X razy daną architekturę i włącz replikację na poziomie danych, więc nie jest niczym nowym.

Szymon Warda: Nie jest niczym nowym, jest ciekawe faktycznie, bo trochę upraszcza sieciówkę. Co mnie tu najbardziej zaciekawiło, to jest to, że jeżeli ten element architektury się rozrośnie, to co wejdzie? Bo w tym momencie, AWS spróbuje zrobić automatyczną, wsparcie dla automatycznego tworzenia komórek. Czyli co to znaczy? Znaczy generalnie, że tworzenie shardów dla baz danych będzie łatwiejsze, co doskonale wiemy, że to jest upierdliwe jak nie wiem co po prostu w tworzeniu się systemów dynamicznych bardziej, bo tam trzeba kombinować z różnymi IaC-ami i jest to takie trochę słabe.

Łukasz Kałużny: Raczej jedna ciekawostka z tego dla wyznawców Multi Cloud i Multi Region. Zobacz - The most of our core computer infrastructure resites in multiple availability zone within similar region.

Szymon Warda: Tak i tu właśnie widzimy, Łukasz mnie nie słucha generalnie.

Łukasz Kałużny: Ale nie, nie, Ty mówisz, tylko dla mnie to jest taka, wiesz, kwintesencja tego. Ja to słuchałem, tylko taka kwintesencja, że core’owe. Dobra, jestem ciekawy jak z GDPR-em i innymi rzeczami, ale to zostawmy i nie znęcajmy się w tym momencie.

Szymon Warda: Tak, ale ciekawe. Wielki serwis w jednym regionie. Koniec, kropka. Jeden cloud.

Łukasz Kałużny: Core wielkiego serwisu. Już nie bądźmy tacy en. Dobra, kolejna rzecz, która jest fajna historia, jest sobie, teraz to się nazywa Ivanti Connect Secure. Kiedyś to był Puls, wcześniej jeszcze Juniper, czyli taka sieciówka do VPN SSL-a, rozwiązanie do VPN SSL-a. I tutaj co się zadziało? Jest to ciekawe, bo akurat miałem rozmowę z klientem czy wyłączać czy nie wyłączać urządzenia, które mają w firmie, dosłownie tego typu dyskusja, bo musiałem doradzić jednemu klientowi co z tym zrobić. I słuchajcie, jeżeli popatrzycie to, co będzie w linkach, to na temat jak wygląda ta podatność, czyli jak możesz zdobyć rewers shella z rootem na urządzeniu nie mając do niego żadnego dostępu.

Szymon Warda: Przerażające.

Łukasz Kałużny: I teraz słuchajcie, jest tak, że sobie poleciały jakieś zero-daye. Z 2 tygodnie temu odpowiednik CERT-u w Stanach, czyli Cyber Security Agency, wydało komunikat do wszystkich agencji rządowych: proszę natychmiast odłączyć te urządzenia z prądu, w trybie natychmiastowym. Taki poleciał komunikat. Też z klientem siedliśmy, zobaczyliśmy jak wyglądają te zero-daye i mimo że spatchowane, sprawdziliśmy czy urządzenie nie było zbackdoorowane tym co jest znane. I to, co klient zrobił, to stwierdził jednak, że trzeba to wyłączyć patrząc się. I czemu trzeba było to wyłączyć? Bo to jest ciekawe. Słuchaj Szymonie, tam jest chyba w drugim linku, można zobaczyć w part 2, w szczególności polecam, jest dokładnie opisane w jaki sposób działa to pod spodem. I co się okazało? Ktoś napisał customowy serwer http, a reszta to były perle i pythony pod spodem. I teraz patrząc się, obraz taki, żeby dostać taki obraz systemu, device’u nie jest trudno, bo jest w cloudach, w wersji trialowej możesz zapalić, więc dostajesz obraz np. w postaci VHD dysku cały do analizy ktoś dostaje. A kod nie będący ofousowany w pythonie, w perlu zawsze wygląda jakby był zofokusowany. Tak, ale całość jest, jak sobie popatrzymy, to całość szła do de facto sprawdzenia całej układanki pod spodem, tego co jest. Więc to jest ciekawostka, jak teraz z rzeczy, które nazywamy od bezpieczeństwa innych rzeczy, w szczególności takie appliance, że tam nie jest do końca bezpiecznie.

Szymon Warda: Ja bym powiedział, że problem jest inny tak naprawdę. Wiele osób zakłada, że jak to jest hardware, to będzie bezpieczne, w ogóle nie ma problemu.

Łukasz Kałużny: A tam jest po prostu Linux z tym wszystkim, co…

Szymon Warda: Jest zwykły komputer tak naprawdę, to się niczym nie różni. To jest zwykły komputer, który po prostu ma software, którym się mniej trochę interesujemy de facto. I z racji na taką ignorancję w pewien sposób, ignorancję de facto nie patrzymy na to tak uważnie, to dla mnie to jest dużo większa podatność tak naprawdę.

Łukasz Kałużny: Tak, więc całość, do dzisiaj tego nie zostało to popatchowane.

Szymon Warda: To to jest dopiero przerażające.

Łukasz Kałużny: Jeżeli sobie popatrzymy na całość zabawy, teraz jest fajne, chyba jest podatność, że można jednym curlem przejąć urządzenie, do tego stopnia.

Szymon Warda: Nieźle, to tylko pokazuje, że samo testowanie aplikacji w izolacji nie ma sensu. Trzeba testować na realnym deploymencie, jak to będzie w ogóle wykorzystywane.

Łukasz Kałużny: Tak, więc całość jest niezła tej układanki.

Szymon Warda: Dobra, to ja kontynuuję temat, jeżeli chodzi o bezpieczeństwo i też nawiązanie w ogóle do odcinka, który nagrywaliśmy poprzednio tak naprawdę, mianowicie Dust. Co się fajnego wydarzyło? GitLab odpalił, miał, a teraz odpalił swoją wersję generalnie narzędzia testowego aplikacji. Czyli na czym się to skupia tak naprawdę? Że w tym momencie dajemy w CI/CD, bardzo ważne, więc bardzo fajne, dajemy odpowiedni zestaw URL-i i to wcześniej działało na alertach ZAP-owych, to teraz przerzucili się na własne. I teraz tak, to umie się uwierzytelnić, umie crowlować, czyli przechodzić po całej stronie, wyszukiwać, umie robić pasywne skany i umie robić aktywne skany aplikacji www. I to jest super kontynuacja rozmowy, którą mieliśmy poprzednio - jak wpiąć i jak te narzędzia powinny być wykorzystywane. Jestem ciekawy czy ktoś z Was może korzysta z faktycznych realnych odczuć co i jak. Ale super krok w bardzo dobrym kierunku, więc mnie to bardzo ucieszyło, że się dzieje. Takie w kontekście bezpieczeństwa. Co tam Ty masz jeszcze?

Łukasz Kałużny: Dobra, dwie rzeczy Copilotowe. Po pierwsze, nie wiem co o tym myśleć, ale jest chyba dobre, Copilot in GitHub Support.

Szymon Warda: Dobra, ok.

Łukasz Kałużny: Tak i teraz jest tak, jeszcze się nie zagłębiałem, ale de facto możesz odpalić sobie, zamiast zrobić ticketa rozpocząć od czata z Copilotem supportowym.

Szymon Warda: To jest w sumie genialny pomysł. Realnie? Tak.

Łukasz Kałużny: W sensie inaczej, dobra baza wiedzy i sposób rozwiązania requestów, linki do dokumentacji. Przy skali GitHuba i innych takich rzeczy jest to dobre.

Szymon Warda: Mi się w tym momencie wydaje, że to jest idealny sposób, w jaki Microsoft może testować swój nowy produkt w przyszłości do właśnie obsługi supportu. Obszar świetny, rynek na to jest fenomenalny. Straszne pieniądze idą na support, więc bym się nie zdziwił gdyby za chwilę był taki produkt Azure, bardzo specyficzny do supportu.

Łukasz Kałużny: Druga rzecz, która jest przy Copilotach GitHubowych, to do chata Copilotowego, ja teraz już z tego trochę korzystam, pojawiła się komenda /doc do generowania i to Visual Studio i Visual Studio Code, żeby za pomocą Copilot chata dogenerować dokumentację i opisy. I muszę powiedzieć, że mało na to przeklinam. Teraz musiałem zdokumentować kawałek sobie, komuś pomagałem napisać kawałek terraforma i żeby ładnie zmienne i inne rzeczy podokumentować to de facto praktycznie nic nie napisałem poza pisaniem /doc i akceptowaniem wersji.

Szymon Warda: W ogóle te opisy, jeżeli chodzi nawet o PR, komentarze, itd., commity, to działa dobrze, to działa naprawdę bardzo, bardzo dobrze bym powiedział. Także tak, też jestem pod wrażeniem tego, co Copilot umie zrobić ładnie.

Łukasz Kałużny: Inaczej i co ważne, nie rozpisuje się.

Szymon Warda: Co mnie fascynuje? To właściwie za chwilę generujemy dokumentację Copilotem, tylko potem, żeby inny Copilot umiał ją czytać i generować kod tak naprawdę.

Łukasz Kałużny: Tak, witamy w Multi Agent w świecie.

Szymon Warda: Dobra, to ja mam jeszcze parę linków, ale taki ciekawy temat, który właściwie zaczęliśmy trochę przed nagrywaniem. Request Response na Rabbit MQ jako sposób na skalowanie requestów synchronicznych do backendów. Wpis o tym jak to zrobił last minute, cała strona do wyszukiwania lotów, itd. I Twoja reakcja była taka sama jak moja reakcja generalnie, co za głupi pomysł. Bo faktycznie Rabbit ma tą opcję, że mamy jedną kolejkę, wysyłamy, potem drugą odpowiadamy, itd. I oni opisali to ładnym artykułem: Evolution of high-performance system: from synchronous to seamless scalability. I teraz co im to daje właściwie? Daje, oni tam w ogóle oczywiście rozpisują się, że to w ogóle jest super, że tu rozdzielili zależności, mogą teraz wdrożenia robić różne itd., itd. Trochę może przekombinowane i trochę może za dużo tam reklamy wrzucili, ale Twoja reakcja była potem taka jak moja, że po co właściwie? To nie w tym kierunku i ogólnie request response, o ile jest rabialny i można go robić, to na kolejkach nie ma sensu. Nie powinno się go robić.

Łukasz Kałużny: De facto takie coś miało sens dla mnie zawsze, bo w MQTT też jest coś takiego, MPQ i wykorzystujesz to przy IoT, żeby dostać od razu zwrotkę z komendy i inne takie rzeczy. Z zupełnie innego wzorca. I druga rzecz, jeżeli budujemy klasyczne aplikacje w DMZ-cie, kiedy aplikacja sama z siebie nie może inicjować ruchu do wewnątrz naszej sieci, to gdzieś tam takie scenariusze były akceptowalne.

Szymon Warda: Tak, ale teraz jedno uzasadnienie, czemu dla nich to potencjalnie ma sens i czemu to jedną rzecz ułatwia? Jeden problem, który masz, to możesz ten load balancing jak najbardziej zrobić na poziomie requestu http. Ale w tym momencie musisz wiedzieć ładnie i ten load balancer musi być świadomy jak jest obłożenie, na którym node’zie i gdzie to zrobić po prostu, żeby nie robić round robina i akurat round robinem trafiasz na node, który jest totalnie zarąbany i nie może działać. Oparcie tego na kolejkach daje Ci automatyczne skalowanie bez tej pętli zwrotnej generalnie o informacji o obłożeniu.

Łukasz Kałużny: Tak, bo to worker, który podniesie, odpowiada na sesję.

Szymon Warda: Dokładnie, znaczy, że on ma ten moment przerobowy i ma tę możliwość, żeby to zrobić. Także dziwne, przekombinowane. Na pewno nie jest to takie piękne i nie jest to taka rewolucja, jak ten artykuł to opisuje. Ale ciekawe.

Łukasz Kałużny: Inaczej, jak mówisz, ok, to jest tam rzecz, tylko jak z drugiej strony o tym myślę, prościej utrzymać load balancer niż Rabbita do wysokiej przepustowości.

Szymon Warda: W zupełności się z tym zgodzę. Ewentualnie konfiguracje dobrego skalowania tych backendów, żeby po prostu były dobrze skonfigurowane.

Łukasz Kałużny: O Rabbit’cie, uwielbiam akurat Piotrka Stappa. Czasami publicznie mówi o pewnym failu z Rabbitem, jak weszli gdzieś w dużej instytucji na produkcję. Miał taką, parę razy o tym opowiadał publicznie, więc trzeba mieć świadomość. Ogólnie koncepcja, że te skalowanie jest ok, tylko że znowu dla mnie to jest już troszeczkę przekombinowane.

Szymon Warda: Dla mnie też jest przekombinowane. Ideowo? Ciekawe, bym powiedział.

Łukasz Kałużny: W szczególności jak zobaczycie na architekturę, ten Redis przy okazji, który tam jest.

Szymon Warda: Tak, bo muszą mieć jakąś synchronizację. A odnośnie jeszcze Rabitta, to z faili rabittowych ja bardzo lubię, już w standardzie kolejkowym jest zrobione tak, że on nie wyłapuje połączeń, które są już martwe, jeżeli klient się nie rozłączył, tylko po prostu jest przeciążony i po prostu nic się nie dzieje.

Łukasz Kałużny: Nie, chyba już teraz dawno nie widziałem takich fuckupów, ale to już możemy…

Szymon Warda: Mieliśmy.

Łukasz Kałużny: Zostawić na razie w spokoju. Dobra, to i ostatni, taka ciekawostka i jestem Twojego zdania - learn more by building your own custom JavaScript framework.

Szymon Warda: Nie, a powiem generalnie, że to ma sens.

Łukasz Kałużny: I to ma sens…

Szymon Warda: Jako projekt na studiach.

Łukasz Kałużny: Raczej wiesz co, projekt na studiach, albo jak chcesz złapać, nazwijmy się, większy Experience Seniority.

Szymon Warda: Tak, tylko absolutnie tego nie wypuszczaj publicznie.

Łukasz Kałużny: Tak, to jest jedyna rzecz. To jest framework, który… Możesz go wrzucić do repo na GitHubie, ale go nie promuj. Zostaw go z wielką notatką: ja się tu uczę.

Szymon Warda: Tak, ale idea w ogóle jest dobra, bo pamiętam, jak jeszcze ja się uczyłem kodować, to przecież była opcja, że póki czegoś nie zbudujesz, nie zrozumiesz jak to działa do pewnego momentu. Więc to jest tak.

Łukasz Kałużny: Tak, napisz własnego CMS-a, silnik blogowy i jeszcze parę innych rzeczy.

Szymon Warda: Sklep internetowy i platformę do e-uczenia się. Świetna trójka.

Łukasz Kałużny: Tak, klasyki domen, które możesz poznać bez wchodzenia w szczegóły w domenę.

Szymon Warda: Tak, tak, tak, kto forum nie napisał ten niech pierwszy rzuci kamieniem.

Łukasz Kałużny: Ale nie, więc pierwsza reakcja była: kurde, wtf? Druga reakcja, kiedy zaczynasz się uczyć, raczej powiedzmy sobie, że wchodzisz w takie realne stadium pomiędzy juniorem, midem i midem+, to jest taki fajny, w zależności od tego, na jakiej platformie w czym klepiesz, ale ogólnie napisanie kawałka jakiejś lipki, frameworka, czegoś takiego w języku, w którym piszesz, to nie jest aż taka głupia rzecz. Tutaj jesteś zmuszony do użycia czystego waniliowego JavaScriptu i poznania bebechów języka.

Szymon Warda: Dla mnie bardziej wartościowe jest co innego, zaprojektowanie API dla ludzi, którzy będą z tego korzystali potencjalnie. Czyli rozdzielenie części frameworkowej od tej części kodowej i użycia biznesowego. To jest wartość tak naprawdę, że mówimy: ok, to są moje granice, to jest moje API, itd. To to jest kawałek wartościowy dla mnie bardziej. To ja mam jeszcze jeden link. W sumie tak teraz patrzę właściwie, że jest to link, który ładnie adresuje nasz problem z last minute. Wpis o load balancingu dla usług, które mogą mieć. Przykład jest na Open AI-u oczywiście zrobiony, itd.

Łukasz Kałużny: Inaczej, przepraszam Microsoft za to, to jest już mój disclaimer, każda osoba z Microsoftu, która tu publikuje i republikuje, powinna dostać w czapę za to, że trzeba stawiać ileś instancji usługi passowej, żeby mieć do niej dostęp. Za to powinni dostać w czapę, bo przerzucają na klienta odpowiedzialność za to, że nie mogą wyskalować swojej.

Szymon Warda: Absolutnie tak. Nawet ten element Open AI-owy tam w ogóle nie powinien być istotny w tym całym. Ale to fajnie pokazuje w tym momencie, jak nasz kochany last minute mógłby to rozwiązać w formie inteligentnej zwracania i nawet monitorowania czasów odpowiedzi do konkretnych zapytań, zamiast wrzucania tego na Rabbita. Tak że w kontekście jakby tam trzeba usunąć tego Open AI-a i patrzeć tylko na kontekst inteligentnego load balansowania ruchu między różnymi endpointami, między różnymi downstreamami. Więc w tym kontekście ten link ma sens tak naprawdę, cała reszta nie.

Łukasz Kałużny: Tak, w tym kontekście skreślcie Open AI-a, bo tam jest robione, że niech się klient martwi, że my dajemy dupy.

Szymon Warda: Tak, tak to właśnie wygląda. I tyle z moich linków.

Łukasz Kałużny: Dobra, to kończymy. Trzymajcie się, na razie.

Szymon Warda: Hej!