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

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka oczywiście w opisie gdzieś na dole. Dacie radę i na Patoarchitekci.io. Dobrze, o czym Łukaszu dzisiaj? A nie, wpierw szkolenia.

Łukasz Kałużny: Dokładnie, dokładnie. Zanim zaczniemy odcinek tytułowy Technology Radar to przypominamy o szkoleniach. Moje na początku grudnia, Architektura 101, gdzie porządkujemy wiedzę na temat projektowania systemów i nie od strony kodu, chociaż go tam gdzieś dotkniemy, żeby powiedzieć, ale ogólnie czym jest architektura, jak podchodzić do system designu. A Ty Szymonie co masz w listopadzie?

Szymon Warda: A ja powiem Ci, że będę miał coś bardzo aktualnego, nawet z tym Technology Radarem, ponieważ będzie observability i nie tylko w wykonaniu Observability 1.0, ale też Observability 2.0. Czym jest Observability 2.0, to sobie powiemy jeszcze właśnie w kontekście konkretnego blimpa w Technology Radarze. Ale ogólnie pobawimy się ze stosem grafanowym, właśnie Loki, Tempo, Prometheus, do tego jeszcze Grafana i jeszcze trochę Pixi, żeby zobaczyć sobie jak działają eBPF-y i cały profiling, gdzie to wszystko umieścić, łącznie z takimi tak zwanymi Auto-Instrumentation APM-ami. Budowanie takiej strategii właśnie wokół monitorowania i co warto wykorzystywać kiedy.

Łukasz Kałużny: Dobra, wszystko znajdziecie na Patoarchitekci.io/szkolenia albo gdzieś tutaj pod spodem. Dobra i dzisiaj bierzemy na tapet Technology Radar odsłona numer 31, u nas pewnie z siódma. I przypominając, Technology Radar jest raportem firmy Thoughtworks, która jest firmą taką konsultingową, doradczą. I oni dzielą się swoimi spostrzeżeniami, chyba trzeba powiedzieć to wprost, z ich punktu widzenia na świat i z ich punktu na projekty i tym, czym się aktualnie oni zajmują.

Szymon Warda: Dokładnie tak, te radary bywają różne bardzo. Bywają dobre, bywają tragiczne. Mieliśmy sytuację, kiedy parę razy po prostu olewaliśmy radary, bo po prostu nic nie było. Ale też były takie sytuacje, kiedy naprawdę były interesujące. Zobaczymy, co będzie tym razem.

Łukasz Kałużny: I co ja bym powiedział, że dobrze patrzeć na to, co jest tam wrzucone, żeby nie używać, a resztę patrzeć na to, że oceniamy, może akurat coś ciekawego się trafi, ale nie jest to must have.

Szymon Warda: Dokładnie. Dobrze, to w takim razie, bo Technology Radar jest podzielony na obszary tak naprawdę, cztery Łukaszu. Więc jakie?

Łukasz Kałużny: Są techniki, czyli jak coś robimy. Platformy, czyli narzędzia, ale nie platformowe. Powiedzmy, że dobrym przykładem narzędzia w platformach jest Kafka, czyli takie większe toole czy Kubernetes. Narzędzia, mniejsze rozwiązania. No i na końcu Languages and Framework, czyli jak sama nazwa mówi rzeczy przywiązane już gdzieś konkretnie do języka i do frameworku. I potem te wpisy dzielimy na poziomy. Jakie, Szymonie?

Szymon Warda: I są cztery znowu. Jest Adopt, Trial, Assess i Hold. Idziemy, to jest od wewnętrznego, czyli takie najbardziej używajcie. Adopt jest trochę na zasadzie, że po prostu używajcie, gotowe, bardzo fajnie, jest ok. Trial jest na zasadzie, że pewnie wam się przyda, jest dobre, jest gotowe do użycia, ale sprawdźcie pierw. Assess jest na zasadzie zobaczcie czy Wam się w ogóle przyda, zróbcie taki bardziej prosty POC, zobaczcie dokumentację czy Wam to będzie pasowało. No i hold, który sam, jak już wspominałeś, jest dość ciekawy, ponieważ hold jest, oni to nazywają ładnie “proceed with caution”, ale tak naprawdę to jest bardziej nie używajcie, czyli nie zalecamy.

Łukasz Kałużny: I to jest też ciekawe, bo w tym mi się odmieniło radarze na to patrzenie na Holda. Ale o tym zaraz, zaraz zejdziemy, że nie zawsze ten hold ma rację bytu.

Szymon Warda: W ogóle mało jest holdów, ale to przejdziemy jeszcze.

Łukasz Kałużny: Tak, przejdziemy sobie. Dobra, to co, lecimy od… W ogóle jakie są twoje przemyślenia może zanim w ogóle wejdziemy na temat tego Radaru, bo już zaczęliśmy trochę…

Szymon Warda: Są dwie rzeczy. Po pierwsze, jest dużo LLM-ów, ale tego się spodziewaliśmy i tutaj plus, bo w poprzednim Radarze nie było ich tak znowu dużo i nie były tak nahajpowane, więc plus. Mało rzeczy jest na on hold. Techniki są najbardziej interesujące. Reszta, tak trochę różnie z tym bywa. Ale uważam, że ogólnie rzecz biorąc jest dobry, chociaż miejscami wydaje mi się, że właśnie mieliśmy dyskusję przed nagrywaniem, że miejscami on jest na zasadzie co usłyszeliśmy, bo nie wszystkie wydają mi się obszary, które poruszają oni tam faktycznie siedzą i działają. Więc taki dobry, ku dobremu to leci, taki średni.

Łukasz Kałużny: Ja sobie popatrzyłem, jedno jest rzeczą, która jest wrzucona, jest tam Rust, o tak, jak sobie zobaczymy takie główne podsumowanie, tematy, to oczywiście jest spuszczanie się nad Rustem, że czego on tam nie robi. Mieliśmy taki projekt, nie polecamy. Ale co jest? Dobrze, że wskazują, że staje się dominującym językiem, ale programowania systemowego, czyli tooling i inne tego typu rzeczy, że nie przechodzi do tworzenia kodu biznesowego, tylko jednak znajduje swoją niszę gdzieś tam z tyłu. To było. Druga rzecz to jest WSAM, o którym wspominają i to jest takie… Z WSAM jest to, że on się tak jakby przebić nie może, nie może osiągnąć tej masy krytycznej.

Szymon Warda: A ja właśnie tak patrzę po nim, że on powoli, powoli to uzyskuje, tak. Wydaje mi się, że on wejdzie po prostu.

Łukasz Kałużny: Wejdzie, ale jest taka, że zobacz, że ciągle nie może tego platu osiągnąć, żeby przelać tą falę do i wejść i że ciągle coś. No i gdzieś są antywzorce na temat korzystania z AI jak i sam rozwój generatywnego AI, czyli LLM-ów. Ale do tego sobie zaraz przejdziemy. To co, co wybrałeś jako pierwsze z technik?

Szymon Warda: Ja wybrałem dwie rzeczy z technik. Dwie rzeczy, które pokazują też to, że czasami Technology Radar jest zbiorem opinii różnych ludzi i czasami zewnętrznie nie jest spójne. Pierwsze co polecają, to jest 1% Canary Releases w adopt. O co chodzi? Canary Release to jest to, że mamy system, wdrażamy nową wersję, puszczamy tam 1% ruchu, badamy jak się zachowuje i wtedy powoli przepinamy na coraz więcej. Podejście bardzo dobre, drogie w implementacji, w utrzymaniu, bo wymaga na przykład strategii odnośnie migracji rollbacków, działania na przykład wersji aplikacji z poprzednim schematem bazy danych, o czym było w poprzednim odcinku jakby ktoś chciał. I generalnie podejście jest bardzo, bardzo, bardzo dobre. To, że to się nazywa 1%, to jest takie trochę ok, nie każdy ma taki ruch i większość organizacji nie ma takiego ruchu, żeby ten 1% był w jakimkolwiek stopniu znaczący. Więc to będzie raczej nie…

Łukasz Kałużny: To jest bardziej…

Szymon Warda: To jest to. Kolejna rzecz z 1% to jest to, że Canary Release’y są super trudne do automatyzacji, żeby mieć automatyczny rollout, czyli że po kolei idziemy 1%, potem 5, 10, itd.

Łukasz Kałużny: Wiesz co, inaczej, nagle się okazuje, bo tutaj też potem jest continuous deployment, component testingi. Ale co znajduje się w tych właśnie, żeby to adoptować? Chyba chcieli sobie lejek zrobić sprzedażowy tych technik, bo tak to trochę wygląda. Bo całość, Szymon zobacz, że przejdziemy i to jest coś, co powtarzamy, że trzeba przejść do dyscypliny wytwórczej, używania feature flag, wygaszania ich i całej tej zgrai rzeczy, którą myślimy, że zrzucimy na infrastrukturę.

Szymon Warda: To jest bardzo mocno procesowe, wymaga bardzo dużych zmian w observability całym, szkolenia.

Łukasz Kałużny: Tak.

Szymon Warda: Shamelees plug i to w większość instytucji Canary Releases, takie jednoprocentowe, nie będą miały wartości, mówiąc bardzo prosto. I teraz idąc, pociągnę jeszcze drugi temat, w tej samej sekcji, też w adopt, jest continuous deployment. Więc moje pytanie jest: jak można zalecać 1% Canary Releases, które są mimo wszystko takim trochę szczytem góry lodowej, takim ładnym, że osiągniemy to, z tym, że no może byśmy mieli automatyczne wdrożenia tutaj?

Łukasz Kałużny: Continuous deployment, tutaj też pamiętaj, że to jest w rozumieniu jednak automatycznego wypluwania bez approvali po testach, etc. Więc to trochę się z tym łączy.

Szymon Warda: No nie, łączy się bardzo, ale jedno jest takim coś, co powinno być i już, właściwie umówiliśmy się, że wszyscy mają. A drugie jest czymś, co większość ludzi nie potrzebuje. Tak, ale to jest trochę budowanie lejka sprzedażowego w tym momencie.

Łukasz Kałużny: Tak. Dobra.

Szymon Warda: To co Ty dalej masz?

Łukasz Kałużny: Ja mam tutaj, słuchaj, po pierwsze, w adopcie to bardziej traktuję to zabawnie, czyli RAG-i pojawiły się w adopcie. No inaczej się tego nie da robić. RAG-i, żeby od razu rozwiązać skrót Retrieval Augmented Generation, czyli sposób wyciągania danych wiedzy, żeby dostarczać ją LLM-owi na różne sposoby. I teraz tak, co ważne, to w adopcie już wisi od zeszłego Technology Radaru.

Szymon Warda: Ale powiedz.

Łukasz Kałużny: Tak i ja się z tym zgodzę, ale to pokazuje tylko, że tutaj nie było na to, w adopcie to jest jedyny chyba taki stabilny, do których nie mamy dyskusji rzeczy. I mnie bardziej tutaj jedna rzecz w trialu ucieszyła, mianowicie syntetic data for testing and training models.

Szymon Warda: Właśnie, bo ja to specjalnie ominąłem, bo wiedziałem, że to dodasz. Mnie to tak trochę bardziej zmartwiło.

Łukasz Kałużny: I wiesz co? I teraz ja się zastanawiam, wiesz, jeżeli popatrzysz, ja to wziąłem w ogóle zupełnie w innym kontekście, bo uważam, że pod testowanie modeli i innych takich rzeczy, jeżeli chcemy wygenerować jakieś większe zbiory pod fine tuning i inne rzeczy, to będzie miało rację bytu, bo te dane będą gdzieś stabilniejsze w wygenerowaniu. Druga rzecz, która mnie bardziej interesuje, która pojawi się za tym, za rozwojem tych narzędzi, to jest budowanie testowych setów danych do aplikacji, performance testów i innych rzeczy. Bo jak te narzędzia zaczną dobrze generować dane, może się okazać, że będzie o wiele łatwiej zbudować sobie narzędzia pod generowanie danych do siebie, pod różne testy.

Szymon Warda: Mieliśmy próbę parę razy i to bardzo mocno zależy od kontekstu aplikacji i czasami wytłumaczenie tego kontekstu, co aplikacja ma zrobić, nie kupuję tego. Dane realne i charakterystyka, jak się zmienia… Znaczy dla mnie problem jaki widzę to jest to, że nie zawsze widzimy wszystkie wektory, gdzie dane się zmieniają, w sensie czasu, opisów, itd. Nie wygenerujemy danych syntetycznych, które będą bliskie, żeby właśnie wyłapać te punkty graniczne tak naprawdę i dane realne pokażą dużo więcej dla mnie. Dla mnie syntetyczne, fajnie, ale to jest tak samo jak ładna anonimizacja w pewnych sytuacjach, w pewnych, pewnie w takim momencie można to zrobić. Po prostu nie zadziała. Albo nakład pracy, żeby to zrobić, to jest tylko po prostu narobimy się, a potem, żeby tylko znaleźć sytuację, w której to nam nie zadziałało do końca.

Łukasz Kałużny: Dobra, ja mam tutaj inny punkt na to widzenia. Dobra. Co jeszcze masz z technik?

Szymon Warda: Mam z technik to, co się w ogóle zgadzamy tak naprawdę, bo zgadzamy się co do tego, że właśnie replacing pair programming with AI jest na hold. To jest ciekawe, bo ja uważam, że tak to powinno być. Pair programming jest trochę o czym innym niż wsparcie Copilotem, nie o to do końca chodzi, nawet w kontekście budowania relacji między ludźmi, bo to też jest ważne. Żeby nie było, wsparcie typu Copiloty są dobrym uzupełnieniem, nie są zastępstwem. I mnie to cieszy, że to jest on hold.

Łukasz Kałużny: Wiesz co? Tak. Dla mnie to jest takie. Bo też nie można mówić… Jako per programming tak, nie zastępuje tego w stu procentach, ale w codziennym kodowaniu to też nie można powiedzieć, że jest… Bo widzisz, tu jest takie twarde hold, a to nie jest prawda, to jest znalezienie balansu moim zdaniem.

Szymon Warda: Wiesz co, jeżeli nazwiemy to tak, jak to zostało nazwane, czyli replacing pair programming with AI, to jestem bardzo mocno, że tak. Ale Tobie chodzi bardziej o wsparcie. Wsparcie jak najbardziej powinno być, to się zgadzam.

Łukasz Kałużny: Tak, wiesz, to jest też wrzucenie, bo tu jest troszeczkę… Inaczej, wiesz co, ja patrzę na to tak, że niektórzy zaraz wyjdą na tym, że Copilot jest jednak tutaj, że Copiloty i inne rzeczy są złe, o tak to nazwijmy. Co tak nie jest, bo ktoś może to wziąć i troszeczkę źle zinterpretować. Bo wiesz, że niektórzy podejdą, że robienie z takiego właśnie Claude czy innych narzędzi, GPT gumowej kaczuszki, to też jest pair programming.

Szymon Warda: Tu się zgodzimy, że nie jest. Dobra, co tam innego Ty masz?

Łukasz Kałużny: Dobra, z rzeczy jeszcze na holdzie, z czym się totalnie nie zgadzam - LLM bans.

Szymon Warda: To opowiedz, bo to jest bardzo hasłowe.

Łukasz Kałużny: Dobra, bardzo hasłowe. I tu idea jest bardzo prosta, żeby zaprzestać przykrywania wszystkich LLM-ów w firmie, narzędzi banem po prostu jego wykorzystania. I teraz tak, to jest trochę idące, bo ban wynika, taki domyślny ban na LLM-y i oni tutaj to też potem bardziej szerzej rozwijają, ten wątek. Czyli żeby zaprzestać a zrobić focus, czyli w ogóle nie mówić, że nie, nie używamy LLM’ów i bardziej sfokusować się na tym, że dostarczamy wrzucone narzędzia, akceptujemy jakieś narzędzia i dajemy je pracownikom. Tylko jak zaczniemy liczyć pewne rzeczy, liczyć ROI, zaczniemy patrzeć jak to wygląda, to w większości przypadków, wiesz o tym Szymon, że taki ban ma więcej racji bytu niż procedura oceny czy narzędzie ma sens do wchodzenia czy nie, jeżeli popatrzymy tak szeroko.

Szymon Warda: Jesteśmy na tym momencie, że wszyscy szukają pomysłu, gdzie użyć, jak użyć i w ogóle rzucamy rzeczami o ścianę i patrzymy, co się przyklei.

Łukasz Kałużny: Więc inaczej ja jako od strony patrząc się nawet osoba zarabiająca na tym hype’ie i tak powiem, że jeżeli w firmie patrzysz, to jakiś Copilot dla developera, jeżeli spełnia Twój compliance, ok, good enough, gdzieś inne narzędzia tak, ale ogólnie to jest ten moment trochę jak z… Ja w jednym miejscu stosowałem, że jeżeli po KubeConie był zakaz dodawania rzeczy do Kubernetesa, przez miesiąc był ban na dodawanie rzeczy do back logu, tak ten LLM ban w tym momencie, on nie jest wbrew pozorom złą rzeczą. Tam powinna być taka mała dziurka, która dopiero mówi czy warto to rozważać czy nie, bo proces oceny też może naprawdę pochłaniać kupę, kupę energii i przez to czasu i kasy. I tu jest trochę tego niezrozumienie moim zdaniem.

Szymon Warda: No i kierujemy się też emocjami w takich rzeczach nawet. Dobrze, to jeszcze drugą rzecz dorzucę. Observability 2.0, mówiłem, że nawiążemy. O co chodzi? Chodzi o ten cały ruch, który się właśnie zrobił wokół eBPF-ów i co one mogą zrobić tak naprawdę, co mówiliśmy w poprzednim odcinku albo jeszcze w poprzednim odnośnie tego właśnie co zrobić, żeby zbierać telemetrię, znaczy telemetrię, stan aplikacji, bo to nie do końca jest telemetria, aplikacji właśnie wykorzystując eBPF-y, czyli taką automatyczną instrumentację, ale na poziomie modułów kernelowych w totalnie nowy sposób. I tak, po pierwsze fajnie, że mówi się o tym. Fajnie, że to się pojawiło dość szybko. Wydaje mi się, że pojawiło się za szybko, bo mam takie wrażenie, że za chwilę… Bo pamiętajmy o jeszcze jednej rzeczy, observability i w ogóle całość, ten cały standard powstał dla producentów oprogramowania, taka prawda, de facto, oprogramowania do monitorowania. I mam wrażenie, że za chwilę to właśnie monitorowanie przez eBPF-y będzie tym takim srebrnym pociskiem i zapomnimy w ogóle po co robić to Observability 1.0, czyli zmiany w aplikacji, itd. Tylko zachłyśniemy się tym, że o Jezu, jeden przycisk i właściwie wszystko widzimy, wszystko mamy. A to będzie jak próba picia wody z hydrantu. No nie wyjdzie to do końca. Więc cieszy mnie, ale też jednocześnie bardzo martwi, w jakim to kierunku może pójść, bo to może pójść w takim czysto marketingowym kierunku: bierzcie, używajcie, nic nie musicie robić, olejcie wszystko poprzednie i teraz macie, co właściwie chcecie. Tak że fajnie, bardzo dla mnie martwiące.

Łukasz Kałużny: Dobra, coś jeszcze z technik?

Szymon Warda: Nie.

Łukasz Kałużny: Dobra, to idziemy słuchaj dalej. To mamy teraz platformy.

Szymon Warda: Ja z platform mam dużo mniej niż Ty, więc leć.

Łukasz Kałużny: Dobra. Ja z platform w sumie mam dużo, ale to bardziej na wspomnienie i dla mnie pierwszy leci tutaj Iggy, czyli rozwiązanie, które jest napisane w Rust’cie i służy do event streamingu. I pojawił się opensource, który pojawił się w assess. I teraz tutaj oficjalne już gratulowałem Piotrkowi Gankiewiczowi spetzowi, gdzieś mu gratulowałem, bo jego PET Project, rzecz, która była jego PET Projectem w Rust’cie, rozwinęła się do tego stopnia, że trafiła do Technology Radaru i ktoś tego używa. Więc gratulacje. I tutaj budują całość, rozbudowują. I tak jak wspomniał, to było coś, żeby spróbować zrobić coś prostszego niż Aeron, czyli rozwiązanie kolejka event streaming pod High Frequency Trading. I próbował zbudować właśnie coś, co pozwoli Ci bez większego, jak to sam określił, że bez większego zrozumienia użyć event streamingu jak i Pub/Suba i też nie przypinać się do pewnych rzeczy i to dość mocno rozwijają. I pokazał mi jedną ciekawą rzecz z ich Discorda i wewnętrzny kanał, mamy nawiązanie i wewnętrzne kanały na temat dyskusji na temat projektu. Nazywają się Patodeweloperka i Patodesign. Ale idąc - gratulacje. O tak, dla mnie jest to bardziej ciekawostka niż rzecz jeszcze w tym momencie, żeby assess i zobaczyć, ale nieźle się rozwijają, mają parę fajnych, ciekawych pomysłów jeżeli chodzi potem o replikację, o floating na S3 i inne tego typu elementy. Czyli być może z tego naprawdę wyjdzie dojrzałe narzędzie. I może dobrze, że bez pewnych patoli, które są pod spodem w Kafce.

Szymon Warda: Dobra, to ja się wcisnę z dwiema rzeczami. W sumie dwie rzeczy wokół tego samego, też mieliśmy właśnie dyskusję przed odcinkiem, gdzie to wszystko dalej pójdzie. Mianowicie dwie rzeczy wokół Web Assembly, które mnie dość mocno ucieszyły. Jedno to jest Golem, a drugi to jest SpinKube. I o co chodzi z jednym i drugim? Golem to jest maszyna stanów do serverlessa, tylko tyle, że trzymana pamięciowo, właśnie cała wybudowana wokół Web Assembly. To wygląda fajnie obiecująco, jest na razie na assessie. I drugi to jest SpinKube, czyli znowu runtime wokół Web Assembly, pewną powtarzalność tu widzimy też właśnie wokół rzeczy serverlessowych, właśnie minimalizujące cold start, itd. Wszystkie dobrodziejstwa, które mamy właśnie z Web Assembly i jak to będzie odpalane. Ja mam wielką nadzieję, że jednak Web Assembly się przebije, bo to ma duży sens, coraz większy sens.

Łukasz Kałużny: Raczej chętnie wymieniłbym kontenery na Web Assembly.

Szymon Warda: Oj zdecydowanie tak. Dużo mniej problemów. Bardzo dobrze, że się pojawiają te rzeczy. Szkoda, że one nie są już w adopt’cie, ale realnie jeszcze nie powinny być, ten ekosystem nie jest aż tak bardzo dojrzały. Fajnie, że dwa projekty, dwa bardzo konkretne projekty pojawiły się już na assessie i one się rozwijają po prostu.

Łukasz Kałużny: Dobra. U mnie będzie to na początek Databricks Unity Catalog. I databricksów ogólnie w tym Radarze jest sporo.

Szymon Warda: Tak, rzeczy w ogóle do analizy danych jest dużo, szczególnie na platformach.

Łukasz Kałużny: Tak, ale databricksów jest dużo. Tutaj pojawia się, wziąłem jako jeden z przykładów Databricks Unity Catalog, jest tutaj akurat na trialu, gdzie samo… Czyli poszedł wyżej, bo wcześniej był, dwa lata temu był na assesie, żebyście mieli tutaj świadomość. Czyli jest to katalog, który pozwala nam zarządzać strukturą, assetami w ramach naszego, oni tutaj to ładnie nazywają, Lake House’u, czyli data lejku, większego data lejku, tak to nazwijmy. Ja przy databricksach w ogóle zrobię Wam uwagę, czy ten Databricks Unity Catalog ma sens, jak używacie databricksów? O tak, ma sens, jest mocny. Ale jest jedna rzecz, którą tak bym wziął, bardzo zza kurtyny ujawnił o databricksach. Jeżeli wierzycie, że mimo że te databricksy są na wszystkich głównych dostawcach cloudowych, czyli na Google’u, AWS-ie i Azure i że jeżeli wierzycie, że ci dostawcy traktują to jako z pierwszego rinku produktów, jakby to był ich, to się grubo mylicie. Oj grubo.

Szymon Warda: Znaczy cały obszar data jest w ogóle taki ciekawy, bym powiedział, dostawców, to jest takie…

Łukasz Kałużny: Ale wiesz, to jest też u mnie narzędzie. Miałem teraz taką sytuację, nie ma tam NDA, więc support nie jest okryty NDA-em, więc mogę się z tego tylko pośmiać, jak inżynier z supportu microsoftowego i databricksowego kłócili się, kto do jakich logów ma dostęp przy mnie na callu.

Szymon Warda: Narzędzia data to zawsze jest ciekawostka jak się tam wchodzi, inny świat.

Łukasz Kałużny: Drugi element, który się pojawił też z Azure’a, a tutaj Szymon to jest akurat raczej nie assess tylko adopt, patrząc się jeżeli nie trafisz na Performance Issue, czyli Azure AI Search, czyli usługa, która była chyba najwięcej razy rebrandowana w Azurze.

Szymon Warda: Jezu, tak i przez to totalnie nie widzimy historii tego blimpa, bo ta usługa też się pojawiała dość często w Technology Radarze wcześniej.

Łukasz Kałużny: Tak. Czyli po prostu Elastic… Inaczej, nakładka na Elastica, bo to jest ważne, to nie jest Elastic, tylko nakładka na full text searcha rozwijana o bardzo ciekawe elementy. Więc jak jesteście na Azure, robicie RAG-i, wyszukiwania w aplikacji pełnotekstowe, to jest way to go.

Szymon Warda: Jest prosty w użyciu, skaluje się ładnie, bardzo proste integracje z innymi usługami, zbieranie dokumentów, zbieranie rzeczy z innych usług.

Łukasz Kałużny: Tak i dużo automatyzacji, którą można w process ingestingu włożyć i nie trzeba tego samemu kodować. To jest chyba taka największa siła.

Szymon Warda: Największa siła jest to, że nie musisz utrzymywać samemu Elastica. Będzie to robił doskonale za Ciebie.

Łukasz Kałużny: Tylko nie służy do składowania logów, tylko danych aplikacyjnych. To jest bardzo istotne.

Szymon Warda: Tak.

Łukasz Kałużny: Dobra i dwie ciekawostki na zasadzie, bo aż zastanawiałem się czy za jedną zapłacili - Elastic Compliance Kubernetes, czyli wyspecjalizowana dystrybucja Kubernetesa, która robi GDPR, HPA i nie wiem co jeszcze. Jestem ciekaw kto im to przyniósł, bo myślałem, że już dystrybucji Kubernetesa mamy wystarczająco na rynku.

Szymon Warda: Tak, ogólnie rzecz biorąc, bo też nad tym myślałem, czy to w ogóle umieszczać, to, że to jest, spoko. Wydaje mi się, że oni też poruszają się, podobnie jak my czasami, w obszarze rynków mocno regulowanych. I po prostu możliwość posiadania czegoś takiego, że: ale boimy się Kubernetesa. Ale tu jest taki fajny Kubernetes, który jest ten.

Łukasz Kałużny: Wiesz co, patrząc się na to, jak sobie zobaczymy, czym to jest, to wygląda jak launcher, jak popatrzymy sobie na projekty, które są w środku, z czegoś złożony. I wiesz co, ja mam inne wrażenie, że któryś z klientów im to przyniósł po prostu.

Szymon Warda: Albo któryś z architektów klientów, to też może być ta opcja.

Łukasz Kałużny: Tak, dlatego mówię, że od klientów. No i ostatnia z tego rzecz, to ukłon w stronę WSM-a właśnie, Web Assembly, czyli PGLite, czyli Postgress zbudowany do WSM-a. I to jest taka rzecz, którą będę obserwował, bo jestem ciekaw co się z tym… Tak, dla tych co nie oglądają na YouTubie, mina Szymona jest bezcenna.

Szymon Warda: Znaczy odcinek bez zrobienia czegoś z Postgressem jest odcinkiem straconym, wydaje mi się w tej sytuacji.

Łukasz Kałużny: Ale jest to ciekawe, o tak, odpalenie sobie. Wygląda to ciekawie, o tak.

Szymon Warda: I na ciekawie się powstrzymajmy i skończmy tutaj wszelkie przymiotniki, które można.

Łukasz Kałużny: Raczej nie używajcie tego na produkcji, o, może tak, nie używajcie. To jest jako w ramach ciekawostki i rzeźbienia side PET projectów, side projectów, zabawy.

Szymon Warda: Tak. Dobra, to lećmy do toolsów i ja zacznę, bo mam coś tak, żeby teraz zrobić to dużo bardziej realne - Bruno w adopt’cie. Alternatywa dla Postmana, po pierwsze. Ma SLI-a i to fajny SLI. Nie ma i nie będzie Cloud Synca dla tych, którzy boją się, że Postman się zsynchronizuje i nie ma subskrypcji, jest jednorazowa opłata 19 dolarów. Czy ktoś potrzebuje czegoś więcej?

Łukasz Kałużny: A za co jest te 19? Bo ja na to nie zwróciłem uwagi za co się dopłaca?

Szymon Warda: Wiesz co, jest za pełne, jakiś tam Gold Circle, też nie wchodziłem w szczegóły. Golden Edition. Też przyszłe czy rozwojowe tego typu, jakieś pierdoły.

Łukasz Kałużny: Widzę, że są jakieś developer toolsy, potem gRPC, load testingi właśnie teraz zobaczyłem na Open API Designer. Nawet ta jednorazowa opłata, dużo w tym darmowym potrafi. Bardzo dużo.

Szymon Warda: Ale też jeszcze ładny UI, co też nie jest takie częste w trybach open source’owych zawsze.

Łukasz Kałużny: Ładny, wzięli, kurde, wygląda jak Postman trochę, zminimalizowany.

Szymon Warda: Ale dzięki temu łatwiej będzie to wdrożyć zamiast Postmana. Bo Postman, jak się już kupuje, to on potrafi sporo kosztować i jak się kupuje odpowiednie licencje. Tak że Bruno wygląda bardzo obiecująco, bym powiedział, nawet po tym jak jest rozwijane, jak to wygląda. Ma sporo contributorów, prawie 300. Więc tak, moje go to obecnie zamiast Postmana.

Łukasz Kałużny: O, to ciekawe. Dobra, ja też miałem Bruno wrzuconego właśnie jako ciekawostkę. I dwie ciekawostki Kubernetesowe tutaj. Po pierwsze Szymonie, K9s. Dla tych co nie kojarzą, jest on w adopcie, czyli dla tych co nie kojarzą, to jest jeden z mega dowcipów tego Technology Radara, że command line’owy tool…

Szymon Warda: Nie, Łukasz, Łukasz, Łukasz, to jest Norton Commander dla Kubernetesa.

Łukasz Kałużny: Norton, dobrze. Czyli macie command line’owy TUI, jak to się ładnie, Terminal User Interface, dla Kubernetesa. Druga rzecz już mniej, bez żartów, zastanawiam się kiedy SOPS zacząłeś używać produkcyjnie?

Szymon Warda: Dwa, trzy lata temu.

Łukasz Kałużny: No, to są w adopt’cie.

Szymon Warda: Ale one są tam regularnie. One tak wchodzą, pojawiają się bardzo regularnie.

Łukasz Kałużny: Nie, 21 było assess, 23 było trial i teraz po roku, po półtora roku mamy adopt.

Szymon Warda: Ale wiesz czemu? Bo było, ten projekt przez jakiś czas trochę jakby nie żył, a potem nagle wypaliło, że właśnie do CNCF-u dołączyli. Więc to też z tego może wynikać.

Łukasz Kałużny: No dobra, to jest w tym. Dobra, co u ciebie? Bo masz jeszcze jeden, widzę, że jeszcze jeden chowasz.

Szymon Warda: Tak, jedno ciekawe. Mam jeszcze [niesłyszalne 00:29:55]. To jest znowu, ja tym razem mam rzeczy małe, ale cieszą z tej kategorii. [Niesłyszalne 00:30:02] jest command linem do porównywania różnic w kodzie, który jest świadomy składni. I to jest super, super ważne, bo jak ktokolwiek robi jakikolwiek refactor albo reformatowanie, to potem nagle jest opcja, że nie patrzymy na te różnice, bo to nie ma żadnego sensu. I jak tak chwilę się nim pobawiłem, to faktycznie ogarnia składnię języków. Załóżmy reformatujemy IF-a, żeby było nierozbite, to pokazuje tylko, co się zmieniło w konkretnym kawałku, czyli umie załamywać linię, wyznaczać konkretne fragmenty i tego typu rzeczy. I to naprawdę fajnie wygląda.

Łukasz Kałużny: Ja na to w ogóle nie zwróciłem uwagi. A może się… I kurde, ile ma obsługiwanych języków i oprócz języków ma też HCL-a, JSON-a i YAML-a.

Szymon Warda: Tak, on naprawdę wygląda dobrze. To nie jest taki projekt na kolanie. Tych języków jest tam dużo, z 20… Ich jest więcej, ich jest tak z 50 języków obsługiwanych. To nie wygląda to jak pic na wodę, żeby tylko to zrobili, itd. Co więcej, obsługuje też JSON-a.

Łukasz Kałużny: No właśnie, dlatego powiedziałem, że HCL, JSON i YAML.

Szymon Warda: Więc to naprawdę wygląda dobrze, bym powiedział. Więc to jest coś, co po krótkiej zabawie można nawet zacząć używać.

Łukasz Kałużny: Ma to ręce. Dobra, idąc, ja sobie mam parę takich rzeczy, które się pojawiło. I ciekawostka, na którą zerknę. Linia B i tutaj ono już tam w tym roku pojawiło się jako asset, teraz jako trial, czyli platforma do zarządzania… Inaczej, oni siebie nazywają jako data driven software delivery. I jak sobie popatrzymy, to jest to ciekawe rozwiązanie, bo oni jak popatrzymy na rozwiązania, to mają patrzenie sobie na developer experience, developer productivity. I jedno z takich chyba większych, trudniejszych rzeczy, są Engineering Matrix i między innymi wbudowane rzeczy do zbierania DORA, jak i w ogóle KPI. Więc wygląda to ciekawie. Przy czym cena za kontrybutora - 50 dolarów za miesiąc w biznesowej takiej edycji.

Szymon Warda: Dużo.

Łukasz Kałużny: Dużo.

Szymon Warda: To jest dużo i to jest w opcji Business, bo oczywiście opcja Enterprise jest płatna zupełnie, zupełnie osobno.

Łukasz Kałużny: Jest Contact Us jak zawsze.

Szymon Warda: Tak. Ale opcja darmowa faktycznie jest, Unlimited Contributors, Unlimited Repositories.

Szymon Warda: All for DORA metrics. Nie sprawdzałem czym są faktycznie te DORA metrics, jak są liczone. Można się podpiąć pod GitHuba, Gitlaba, Bitbucket, Jira i Azura, plus jest API do wkładania informacji o deploymentach i incidentach. Potem pytanie jak z prywatnością w tym free i inne takie rzeczy, bo to już jest.

Szymon Warda: To jest z reguły wisienka na torcie. Swoją drogą w obecnej sytuacji, jaką mamy na rynku ekonomiczną, nie wydaje mi się, żeby to narzędzie się za bardzo przebiło.

Łukasz Kałużny: Ale jest dość ciekawe. Inaczej, wcześniej na to nie zwróciłem uwagi, w poprzednim, a teraz tak rzuciłem i raczej obiecuje coś, co jeszcze nawet rozmawialiśmy z, mieliśmy odcinek na temat DORA Metrics z Kingą, jak to wdrażali. Zauważ, że to jest takie odpowiedzenie sobie, że: o, jest jedno narzędzie, żeby to wszystko zebrać i podłączyć.

Szymon Warda: Tak, dość kosztowne, więc to narzędzie może szybko pójść pod młotek.

Łukasz Kałużny: Dobra.

Szymon Warda: Co tam masz dalej?

Łukasz Kałużny: Dalej ciekawostka, pgvector, czyli przeszukiwanie wektorowe, czyli budowanie RAG-a w Postgressie. Tu jest na trialu, to działa, to po prostu działa. Przy czym ciekawostka, jak znajdę to wrzucę linka, przeszukiwanie wektorowe nawet da się zrobić w zwykłym SQL-u, SQL Serverze.

Szymon Warda: Tak, jak najbardziej.

Łukasz Kałużny: I to działa. Dobra i dwie rzeczy z kodowania. Cursor, czyli IDE na bazie VS Code’a, które ma dość zaawansowany model Autocompletion. Czyli jak dobrze napiszesz komentarz to leci sztabem i rozumie większość Twojego codebase’u. I mają swojego małego LLM-a, który podpowiada szybko, plus można użyć innych API. To jest ciekawostka. Da się to zrobić, też przerobić, są pluginy do Visual Studio Code. Zostawię też link jak można sobie zrobić podobny setup w oparciu o Claude, o Anthropic API.

Szymon Warda: Z ciekawostek, wersja darmowa ma 2000 uzupełnień. Wersja płatna 20 dolarów miesięcznie.

Łukasz Kałużny: Tak, ok. Druga rzecz, która się pojawia, to JetBrains AI Assistant. I tutaj mocno to rozwijają. Teraz był release, parę dni temu był release ich własnego LLM-a pod to, więc zobaczymy jak to będzie wyglądało. I patrząc się, to może być akurat ciekawe, patrząc na JetBrainsy. Poprzednia wersja, która tutaj pewnie jest opisywana, to komentarze, które są, i issue’sy, to jest tylko popcorn, nic więcej.

Szymon Warda: Znaczy JetBrains robi dobry soft dla developerów i mają kulturę robienia dobrych rzeczy. Więc tak, wydaje mi się, że ze wszystkich assistantów oni mogą być takim top 3, top 4.

Łukasz Kałużny: Tak, tylko muszą się ogarnąć. I pewnie to, co teraz się pojawiło, pozwoli im. Dobra, języki i frameworki. Więc zaczynamy, bo mamy to samo na start.

Szymon Warda: CAP.

Łukasz Kałużny: CAP. Czym jest CAP?

Szymon Warda: CAP jest outboxem dla .Netu, mówiąc bardzo prosto. Wsparcie dla Rabbita, dla Kafki, wygląda całkiem ciekawie. I co, właściwie to brać i używać, bo to właściwie z tej kategorii można powiedzieć.

Łukasz Kałużny: Tak leży w organizacji .Net Core, więc trochę ułatwia popatrzenie na to. Czyli implementuję sobie Outbox Patterna. No i pytanie jak potem z MassTransitem i innymi rzeczami, czy nie lepiej pójść tamtą drogą? Jak zawsze jest to pytanie, bo z innymi rozwiązaniami.

Szymon Warda: Jak patrzyłem na konfiguracjach jak to wygląda, to też jest dość przyjemne i…

Łukasz Kałużny: Jest proste.

Szymon Warda: Jest proste, tak. To jest najważniejsze właściwie, żeby działało.

Łukasz Kałużny: Mnie najbardziej zaskoczyło, że jest dashboard.

Szymon Warda: A ja właśnie na to nie zwróciłem uwagi. To by faktycznie dobrze wyglądało. Faktycznie jest dashboard.

Łukasz Kałużny: To taka ciekawostka z tym. Ale jest. Dobra, z rzeczy ja mam jeszcze tylko jedną, czyli LlamaIndex. LlamaIndex czyli biblioteka do podpinania sobie LLM-ów naszych i budowania rozwiązań w naszych aplikacjach. Jest tutaj na trialu, wcześniej też gdzieś tam był u nich LangChain i mam wrażenie, że rozwój LlamaIndex poszedł w lepszym kierunku niż LangChaina. To jest moja perspektywa tutaj i jak przy okazji o tym gadamy, to stwierdziłem, że warto to zahaczyć. Mają więcej przykładów, jest to bardziej ustrukturyzowane w tym momencie.

Szymon Warda: To teraz ja wrzucę bombę, bo za to może się wylać trochę hejtu na nas, na mnie. Flutter for Web w assessie. Dla mnie jest… W ogóle dla kontekstu, jak się wpisze Flutter, to Google robi autocomplete is dead. Poważnie, nie robię sobie żartów. Faktycznie. Google parę miesięcy temu, na start jakoś tego roku, dzień przed konferencją Flutterową wywalił większość ludzi od Fluttera. Super. Flutter niby dalej jest utrzymywany przez [niesłyszalne 00:38:43], jak to zostało ładnie nazwane. Ja osobiście, gdybym miał wybierać jakikolwiek projekt i patrząc, bo wybór to nie jest tylko wybór techniczny, to jest wybór ekosystemu, wybór też polityczny w jakimś pewnym stopniu, itd. To pójście teraz we Fluttera pod tym wszystkim, co tam jest, zamieszania, itd., jest trochę niezrozumiałe jak dla mnie, naprawdę. Dla mnie to powinno po prostu trochę odczekać, zobaczyć jak to się będzie zachowywało, jak będzie dalej rozwijane, bo z reguły jest jakieś tam powiedzmy opóźnienie zanim projekt będzie porzucony albo będzie dalej rozwijany, żeby udowodnić, że faktycznie mamy kontrybutorów i że to jest zdrowy ekosystem. Ale to jest ciekawostka. Flutter w ogóle jest fajną technologią, tego nie kwestionuję.

Łukasz Kałużny: Ale jest ciekawostką.

Szymon Warda: Tak, jeszcze wiesz, w wersji webowej, gdzie to śmiga właśnie po Web Assembly oczywiście, a nie na urządzenia przenośne powiedzmy sobie, odważnie, bym powiedział.

Łukasz Kałużny: Raczej nie wiem po co się tu znalazło tak szczerze. Raczej mogli po prostu tego nie wrzucać.

Szymon Warda: Mogli, albo nie na assess tak naprawdę. Sorry, to trochę za wysoko. Masz coś jeszcze?

Łukasz Kałużny: Nie, ja już skończyłem swoje, więc dajesz swój ostatni.

Szymon Warda: Kolejna ciekawostka, też do końca trochę wydaje mi się trochę przekombinowane. Score w assess też. Czym jest Score? Score jest takim, tworzyć YAML-ową konfigurację aplikacji, która jest przenośna i możesz potem ją deployować załóżmy, tą aplikację, na Docker Compose albo na Kubernetesa, albo na Twoją własną platformę. Po co? Czemu? Po pierwsze, bo generalnie jeżeli mamy ten wspólny element między dwoma platformami typu Docker Compose a Kubernetes, które mają ze sobą niewiele wspólnego poza tym, że uruchamiają kontenery, bo mają swoje porty, wolumeny i właściwie, co tam, nazwy właściwie. No i tyle. Więc realnie to jest po prostu narzędzie, które przepisuje Docker Compose’a na Kubernetesa. Takie narzędzia już są. To jest po prostu narzędzie do transformat. Do własnej platformy już jest ciekawe. Pytanie, jak dużo osób potrzebuje i gdzie jest tam sensowność tego? Ja trochę nie rozumiem pomysłu. Dla mnie warstwa abstrakcji jest warstwą abstrakcji.

Łukasz Kałużny: Kończysz jakimś helmem, customizem i innymi rzeczami na produkcji.

Szymon Warda: Dokładnie, a to tak przyjmuję, że niby przykryjemy i będzie wszystko fajnie.

Łukasz Kałużny: Tak.

Szymon Warda: Nie.

Łukasz Kałużny: Oni jeszcze wspominają o tym takim starym, pewnie pamiętasz, Open Application Model, który się nie przyjął. Raczej te wszystkie produkty, sorry, Microsoft teraz ma tego Radiusa, który zginął śmiercią… Inaczej, zobaczymy za 6 tygodni, pewnie usłyszycie nasze komentarze po Ignite’cie, zobaczymy czy Radius tam będzie występował.

Szymon Warda: Dla mnie narzędzie, które po prostu po co właściwie? Zasypuje jakąś niszę po to, żeby mieć warstwę abstrakcji nad warstwą abstrakcji. Nie ma to sensu ogólnego.

Łukasz Kałużny: Wiesz co, i tak ja mam, na koniec podziękujmy ThoughtWorksowi za dawanie nam miejsca do tworzenia contentu.

Szymon Warda: Trochę tak.

Szymon Warda: Dobrze. To co?

Łukasz Kałużny: To co?

Szymon Warda: Tyle właściwie.

Łukasz Kałużny: Tyle. Trzymajcie się, na razie.

Szymon Warda: Na razie. Hej.