Łukasz Kałużny: Cześć, słuchajcie Patoarchitektów Short! prowadzą Łukasz Kałużny.

Szymon Warda: i Szymon Warda. Wszystkie linki do tego odcinka góra dół, pewnie na dole albo na patoarchitekci.io, więc poradzicie sobie. Dziś temat fajny, taki trochę powtarzający się kwartalnik, można powiedzieć. Mianowicie przegląd technologii Radaru od Thoughtworksa. Tak w ramach przypomnienia czym w ogóle jest, jak się dzieli itd. Łukasz.

Łukasz Kałużny: Dobra, to zacznijmy od obszarów. Mamy cztery techniki, czyli ogólnie jak wytwarzamy, budujemy infrastrukturę, projektujemy następnie narzędzia, czyli ogólnie rzeczy, które nam pomagają to zrealizować, potem platformy. I możecie mieć wrażenie, że to się miesza z narzędziami. I słusznie, bo tutaj podejście bardziej takie wysoko poziomowy, platformowe do tego. No i na końcu języki i frameworki, czyli część najbardziej zazwyczaj programistyczna, w tym taka deweloperska bardziej.

Szymon Warda: Te wszystkie cztery obszary są podzielone też na cztery poziomy dojrzałości. Można trzy, cztery poziomy rekomendacji mamy Adopt, gdzie Thoughtworks mówi wyraźnie korzystaj po prostu wdrażać, bo to jest na tyle dojrzałe i na tyle fajne, że jak najbardziej. Potem jest Trial. To jest poziom, na którym Thoughtworks rekomenduje: spróbuj, zrób faktyczną próbę, czy Tobie się to przyda? Jest Asses. To jest takie trochę estymacja na sucho De facto. Przejrzyj dokumentację, zobacz co to oferuje, przyjrzyj się. Może niekoniecznie jeszcze rób of concept de facto. I Hold, które oczywiście jest ciekawsze, bo to jest gdzie Thoughtworks mówi, że nie korzystaj, my tego nie rekomendujemy.

Szymon Warda: Z reguły tu jest dość mało, ale te wybory jak nawet będziemy mieli w tym odcinku są dość ciekawe i pokazują jasne rekomendacje, że nie. I wiecie co?

Łukasz Kałużny: Jedną rzecz dla osób, które nie są zaznajomione z Thoughtworks i Technology Radarem to Technology Radar wynika z ich projektów w tym czasie, czyli zazwyczaj to jest pomiędzy kwartałem a 6-9 miesięcy. To wychodzi w zależności jak to było w czasie. I to polega z projektów, w których Thoughtworks bierze udział i pomaga swoim klientom. Więc to jest takie bardzo mocno ponadto przez nich z ich życia i z tym możecie się nie zawsze zgadzać i będzie to poprawne, a czasem stwierdzicie, że odkrywają coś na nowo I to też będzie bardzo dobre spostrzeżenie.

Szymon Warda: Ja też nie jestem pewien, czy to zawsze jest takiego z realnego użycia, bo wydaje mi się, że niektóre punkty są na zasadzie generalnie też taki trochę reklamowy, no ale to jest bardzo zaopiniowany radar jak najbardziej, czasami jest bardzo z tyłu technologicznie, a czasami jest przyhypowany, różnie bywa. Bardzo dobra to na start. Jakie opinie? Dla mnie opinia jest taka, że jest Zaczęła się wojna dusz jak to nazywał to kto będzie wdrażał AI tak naprawdę i kto umie to robić, bo jest dużo bardzo elementów. Zaczęły pojawiać się konkretne opinie, które są gdzieniegdzie trochę nawet zabawne bym powiedział i widać, że LLM-y jako tako przykryły wszystko inne. W Tools i Languages and Framework po prostu jest niewiele tego bym powiedział.

Łukasz Kałużny: Raczej ja mam, słuchaj całość rzeczy. Ja widzę taki podział dwojaki tego. Jedno tak jak powiedziałeś element LLM-y i tego nie zabraknie dzisiaj u nas. A drugi podział to jest część troszeczkę platformowa narzędzi wokół budowania platformy IDP.

Szymon Warda: Ale wydaje mi się, że on tam powiedział rzeczy nowe. Tam jest parę fajnych rzeczy, faktycznie o tym powiemy, to, co jest wokół,

Łukasz Kałużny: Bo próbuje złapać, bo część jest wokół układania SLC Software Defined Vehicle.Z drugiej strony część jest wokół układania Vipry

Szymon Warda: I z tym bym się zgodził. Wydaje mi się, że pojawiły się realne problemy i oni chcą to jakoś rozwiązać. Tych narzędzi, jak już opowiem za chwilę, jest tyle, że to jeszcze nie jest takie w pełni dojrzałe. Ale faktycznie jest. Masz rację, wysypało tych narzędzi trochę, jak najbardziej. To może przejdźmy już po raz kolejny.

Łukasz Kałużny: Dobra, no to co? Lecimy z technikami na początek?

Szymon Warda: Zaczynaj pierwszy, bo wiem od czego zaczniesz. Go for it Łukasz!

Łukasz Kałużny: Lecimy z pierwszego adopta czyli LLM-y. I tutaj to co się pojawiło to Retrieval Argumentation Generation, czyli de facto pobieranie danych do naszego LLM-a. Używanie LLM-a też mnie już nudzi, bo de facto w większości przypadków będzie to OpenAI i jeżeli popatrzymy tak realnie i całość jest na Adopcie i tutaj trudno się nie zgodzić, że jest to prawidłowa rzecz i to co zauważam to też pokazuje rynek teraz praktyka, którą mamy. Zobacz od razu, że na holdzie pojawiły się Rush to find you LLM’s.

Szymon Warda: Też to zauważyłem. Bardzo ładnie się to łączy.Mnie całe podejście cieszy. Z tego prostego punktu widzenia daje lepsze wyniki, jest łatwiejsze i pod każdym względem po prostu jest przyjemniejsze w korzystaniu. Tak naprawdę więc pójście w tym kierunku jest fajnie, że to podejście wypaliło i stosowanie tego staje się dużo, dużo łatwiejsze.

Łukasz Kałużny: Tak, a wchodzi tu FineTune. Ludzie myślą, że posiadają, bo to jest takie coś. W szczególności chyba biznes wyobraża sobie, że posiada dane żeby nauczyć tego LLMa i go sfinetunować,

Szymon Warda: Wiesz co, to bardziej wynika z tego jak podchodziliśmy do LLM-a i w ogóle do wcześniejszych rzeczy, że mieliśmy model, który potem musieliśmy Finetunować do naszej kppii danych, albo budować go od zera. Tak, szaleńcy budowali od zera De facto, ale większość ludzi brało jakiś tam pre-nauczony model i potem go finetunowało do swojego zbioru danych. I wydaje mi się, że to bardziej jest kwestia, że to podejście trochę pokutuje. Dalej istnieje i aplikujemy stare podejścia do nowych modeli, które mają trochę inne charakterystyki.

Łukasz Kałużny: Tak, i to fajnie zauważyli, że ludzie sobie właśnie wyobrażają, że finetuning służy, żeby nauczyć wiedzy i faktów na temat procedur i działania organizacji.Więc tutaj rzeczy, z którymi się nie kłócę, tutaj się z tymi dwoma punktami można zgodzić.

Szymon Warda: Dobra, tak dalej kolejny. W ogóle trzeba zauważyć, że bardzo dużo rzeczy wybraliśmy razem De facto mamy dubli i mamy kolejny test na trial, czyli spróbujcie Continuous compliance. I to jest rzecz, którą ciężko jest się nie zgodzić, ale dla mnie jest życzeniowe. O co w ogóle chodzi? Chodzi o to, żeby w ciągły sposób badać naszą zgodność z wymaganiami. Jakoś tak dalej i ok, żeby nie robić tego formie takich skoków, że teraz musimy ogarnąć coś temu, teraz to już taka regulacja itd. Żeby to był proces ciągły wbudowany w nasz cały proces wytwarzania oprogramowania, budowania platformy i tak dalej. Zgadzamy się jak najbardziej, ma to sens. Dla mnie problem jest z tym, co już mówiliśmy wcześniej, nawet we wcześniejszych odcinkach tak naprawdę niekoniecznie o technologii radarze, że narzędzi wokół tego nie ma jeszcze aż tak dużo. One powstają jak najbardziej. Ten shift left się dzieje super, ale dla mnie to jest obecnie jeszcze trochę bardziej życzeniowe.

Łukasz Kałużny: Wiesz co, tak jest to takie życzeniowe, ale to jest rzecz, w stronę której powinniśmy patrzeć. Wiesz co, ja bym tutaj dorzucił drugą rzecz, która mi się świetnie przypomina z rozmową z Andrzejem na temat bezpieczeństwa, którą mieliśmy DevOps, Continuous Compliance i następna rzecz, czyli security champions. One świetnie się ze sobą łączą, czyli powiedzenie sobie, że mamy security champions to jest też trial, czyli członek zespołu, który myśli krytycznie na temat potrzeb od strony właśnie decyzji na temat bezpieczeństwa, od strony technicznej i nie technicznej, w jaki sposób do tego podchodzimy i to jest takie. Świetnie się łączy z tym continuous De facto compliance,

Szymon Warda: A to ja mam zupełnie inne zdanie odnośnie właśnie security champions, bo jak przeczytałem ten element to mi się zaraz zapaliła taka żółto czerwona lampka. Bo ogólnie zgodzę się, że takie myślenie krytyczne jest ważne. Dla mnie problem jest taki, że sposób w jaki to implementujemy może być bardzo zły, bo teraz jak można to zgwałcić? De facto ten cały pomysł to jest to, że po prostu nagle wyznaczymy Ty jesteś, ty myślisz krytycznie w systemie.

Szymon Warda: Problem jest taki, że jak tych ludzi wdrożymy do zespołów albo namaścić tą rolą w zespołach, to to będą ludzie, którzy będą szukali dziury w całym De facto i będą zgłębianie. Po prostu szukali. Tylko co można zrobić, co jeszcze zrobić, co robić. Ale problem dla mnie, który jest, to jest to, że na bezpieczeństwo trzeba patrzeć w kontekście globalnym organizacji. Nie każdy system będzie miał te same wymagania bezpieczeństwa i generalnie takie szukanie dziury w całej infrastrukturze systemu nie ma sensu, bo one są w takim zamkniętym mikro środowisku, że po prostu nie ma sensu ich utwardzać. Więc dla mnie okej, wyznaczenie myślenie jest w porządku. Wdrożenie tego pomysłu jest tutaj najważniejsze, bo można go po prostu wdrożyć bardzo, bardzo źle. Gdzie będzie przeszkoda do implementacji?

Łukasz Kałużny: Powiem Ci tak jednym słowem bym Ci powiedział, można wdrożyć Scruma albo Sapa i dokładnie to samo. Więc raczej mówię jako koncepcja jest to świetne. Tak jak mówisz, zgwałcenie tego jest mega mega proste.

Szymon Warda: Dlatego ja bym się do tego nawet nie przychylił do tego stopnia, że zbyt łatwo popełnić tutaj bardzo poważny błąd i ci ludzie po prostu będą bez kontekstu szukali dziury w całym.Więc ja bym wiedział, że niekoniecznie. Dobra, lecimy dalej jako jedną rzecz, ponieważ wiem, że słuchają nas osoby, które zajmują się bazami danych i tak dalej, i tak dalej. A jak zobaczyłem ten wpis, to w ogóle nie można było go ominąć. Mianowicie chodzi o test SQL, czyli wykorzystanie czego LLM-ów do generowania SQL. Więc teraz te wszystkie lata marudzenia na ORM nagle przebiły nową wartość. Tak żartem właściwie, ale na serio o generowaniu SQL u, bo tu mówimy głównie do aplikacji, tylko bardziej w kontekście do analityki. Tam to ma naprawdę sens. Czy to jest kwestia tego, że nagle eksperci od baz danych zostaną bez pracy? No bo w sumie powiedzmy to SQL jako język jest prostszym językiem niż te wszystkie języki programowania typu tam obiektowe i tak dalej. Zbiór danych mamy, Większe jest ryzyko, że nagle oni będą bez pracy. Nie no, pozostaje wieczny problem, mianowicie która tabela, co znaczy i gdzie dane połączyć, żeby to miało sens. To jest cała wiedza biznesowa, która jest i tak samo istnieje w każdym systemie w programie piszemy de facto.

Łukasz Kałużny: I teraz, co ważne, takie rozwiązanie nie jest trudno zbudować.

Szymon Warda: Nie jest trudno, ale też co ważne takie zdanie wymaga szkolenia i nauczenia tego modelu właśnie co znaczy. Więc obstawiam, że jako start na teraz do prostych rzeczy tak. Spróbujmy raz, żeby to było w pełni użyteczne, żeby zastąpiło interfejsy do analityki itd.

Łukasz Kałużny: No to długa droga

Szymon Warda: Długa droga.

Łukasz Kałużny: Wiesz co, ja mówię: nasz schemat zazwyczaj przypomina, w szczególności jak oglądam niekiedy hurtownie. To nie ma nic wspólnego z rzeczywistością. którą ma biznes.

Szymon Warda: Ten schemat masz analityczne. W ogóle te bazy rosną po prostu przez całe lata, nawet dziesiątki lat. To jest po prostu zbiór mapowań jak organizacja się zmieniała i tam kluczowym elementem jest wiedza de facto co skąd wyciągnąć, jak wygląda i co więcej, że ta wartość w tym polu wyglądała kiedyś tak, teraz wygląda tak i mamy wiele zestawów wartości w tym samym polu.

Łukasz Kałużny: Albo wiedza plemienna, bo kiedyś ten proces działał. Tak, ale nie zmieniliśmy struktury, tylko raporty.

Szymon Warda: Dokładnie. Znowu wchodzimy w ten problem z de facto, że do generowania SQL. A tak posiadanie tej wiedzy plemiennej może z tym być gorzej. Znowu to jest zdanie takiego junior developera do analityki tak naprawdę i ok, fajnie, próbujmy według mnie mamy tu jeszcze do tego daleką drogę.

Łukasz Kałużny: I wiesz co? Kolejna rzecz tu się pojawia w Assesie, czyli LLM based chat ops.

Szymon Warda: Czekaj Łukasz, wrócę jeszcze jako przykład narzędzi, które to mają robić. Ona właśnie służy. Żeby nie było, że mówimy o czymś, co nie ma implementacji, to właśnie vanna umie generować SQL.

Łukasz Kałużny: A tak lecimy dalej. Jasne, ja jeszcze podrzucę inny przykład. Jeżeli jest na GitHubie, który widziałem ostatnio na konferencji, muszę tylko go poszukać. Zrobiony bardzo prosto w necie z Symantec kernelem. Tak naprawdę super prosto. Następna rzecz, która mi się z tym łączy to są LLM backend Chat Apps i tu jest akurat podane w ogóle w kontekście de facto bardziej Slackowców i innych takich rzeczy, a ja patrzę na to w kontekście w ogóle patrząc się jako taki user friendly interfejs, który jak powiedziałeś sprawdź mi dane tak jak powiedziałeś o tym SQL tekstu SQL, Sprawdź mi dane to tutaj np.pokaż mi wszystkie dane na temat klienta X, Y, Z czy dodaj coś w systemie i patrzą Ci się, że czat może zacząć być naturalnym interfejsem do systemu?

Szymon Warda: Czyli co to jest? To jest kolejna analityka na bazie metryk i logów opsowych, więc do takich rzeczy czat się nadaje fenomenalnie, bo nie będziemy mieli do tego jednego języka kodowania raczej.

Łukasz Kałużny: Ja patrzę też pod system biznesowy, bo zobacz, że jak masz API do systemu dobrze udokumentowane, to już operacje na tym nie są aż takim wyzwaniem.

Szymon Warda: W kontekście takich zapytań szerokich jak najbardziej te LLMy i interfejsy gotowe mogą mieć sens, że tak powiem, zgodziłbym się z tym. No to teraz lecimy do kolejnego, który dla mnie był trochę zabawny, bo chciałbym kolejny punkt, który jest co jest ważne, on jest Hold, czyli nie korzystajcie z tego. Nazywa się to ładnie Overenthusiastic LLM Usage. Biorąc pod uwagę, że spora część punktów Technics jest o elementach, to danie takiego punktu i jest takie trochę. Wydaje mi się, że Radar chciał żeby to nie było przyhypowane

Łukasz Kałużny: Raczej wiesz, tylko z drugiej strony bardzo dobrze i trudno się z tym nie zgodzić punktem.

Szymon Warda: Tak czy tak trudno się z tym nie zgodzić, ale sami trochę gdzieniegdzie hypują tak naprawdę.No więc tak, mają rację. Tylko że to ich zachowanie nie świadczy o tym co mówią, że powinno się robić tak dobrze. Ale idźmy dalej. Jeszcze ostatni Twój

Łukasz Kałużny: W technikach,

Szymon Warda: A jeszcze faktycznie dziękuję za uwaga jeden wpis, który jest na trialu Edge Functions Funkcje krawędziowe Edgowe, Cloud Workera, CloudFlare itd. Czyli wykonywanie pewnych operacji na samej krawędzi, czyli de facto na tych punktach wyjściowych z chmury albo z jakiegoś tam CDN-a. I żeby nie było to ma sens i to jest super fajna opcja, że to robimy, bo to zmniejsza czas odpowiedzi i możemy uzyskać naprawdę super właśnie taki user experience do naszych stron internetowych itd. Mój problem z tym jest taki, że to jest coś co ma realne wykorzystanie, gdzie realna wartość kontra koszt utrzymania i wdrożenia tego to jest dla promili organizacji de facto, no bo realnie wykonujemy funkcje na jakimś tam cashu tak naprawdę. Więc fajnie, że w trialu. Ja się boję tego szerokiej adopcji, bo to po prostu nie ma sensu.

Łukasz Kałużny: Znaczy to nie jest szeroka. To jest offloading wiesz co, ja zawsze będę mówił, że to jest offloading. Po prostu. Jeżeli tworzymy aplikację internetową taką dosłownie coś, co jest wystawione do świata, bądź robimy jakiegoś małego toola, który jest wystawiony do świata to ma to rację bytu. Tak jak musiałem zrobić na jakąś na architektury kontenery stronę do konferencji gdzie będą się streamy pokazywały i inne takie rzeczy To po co w ogóle było? Wiesz, napisanie kodu, wrzucenie go na worker CloudFlare a od strzała, ale budowanie całego systemu i przekombinowanie - no nie tędy jeszcze droga.

Szymon Warda: Ja bym powiedział inaczej. Mieszanie systemów, który ma back end, normalny back end i jeszcze do tego dorzucanie funkcji krawędziowe edge functions. Dla mnie tu jest większe ryzyko, że to będziemy robili operacje na cashach. Będziemy to rozproszenie tego ma sens dla małej ilości organizacji takich stronek. Bo sorry Łukasz tu nie uwłacza, ale są stronki małe

Łukasz Kałużny: Tak, ale to jest świetna rzecz.

Szymon Warda: Świetna rzecz, ale dla stron i aplikacji to nie ma żadne wartości. Wartość jest kiedy chcemy optymalizować te 99%, czyli de facto czas odpowiedzi. Dobra, fajnie, lecimy dalej. Platformy platformy. To ja bym zaczął od jednej rzeczy, bo ostatnio zjadłem trochę na tym zęby kontener appsy, czyli tak zwany aplikacyjny Kubernetes, czyli mamy ww chmurach takiego AKS-a.

Łukasz Kałużny: Zarządzane Kubernetesy.

Szymon Warda: .Zarządzane chmury z którymi i tak się musimy męczyć. Musisz się męczyć, musisz wszystkim wiedzieć, a poziom wyżej De facto tego mamy. My nazywamy aplikację mini Kubernetesami. Nie wiem, czy to jest ogólnie przyjęta, ale

Łukasz Kałużny: Raczej dobrą też określeniem jest namespace SSRX.

Szymon Warda: Też może być faktycznie, chociaż naszą nazwę chyba trochę bardziej wolę i jest. W trialu pojawiło się już nie jeden raz, o ile pamiętam.

Łukasz Kałużny: Chyba omawialiśmy też na zeszłym.Tak, bo już było

Szymon Warda: Tak, bo się bardzo mocno rozwinął ten rynek. On ma sens, bo nie wszystkie organizacje mają potrzebę i potrzebują zaczynać od Kubernetesa albo mieć w ogóle Kubernetesa w każdej sytuacji. Ostatnio właśnie budujemy platformę dla jednego z klientów opartą o Container Appsy. I o ile początek tej znajomości powiedzmy sobie był ciężki, bo ta warstwa abstrakcji jest kulawa, miejscami widać, że to jest przykrycie Kubernetesa dość proste i np. montowanie wolumenów jest, trzeba się tam napisać, powiedzmy sobie nie jest takie super intuicyjne, parę rzeczy tam jeszcze trochę kuleje, ale jak buduje się to ładnie, co zajmuje trochę czasu to faktycznie działa i to działa dobrze. Na tyle dobrze, że wydaje mi się, że dla sporej grupy organizacji to powinno być jedno z głównych narzędzi, jako że kierujemy nie kupując, tylko właśnie aplikacji Kubernetes, a dla reszty to powinno być narzędzie, które istnieje jako opcja, żeby nie hostować wszędzie Kubernetesów, tylko żeby mieć Container Appsy, żeby zmniejszyć koszt utrzymania klastrów, bo nie każdy musi mieć 40 klastrów, które chodzą w organizacji po prostu, bo to nie ma większego sensu. Także fajna usługa. Nie nosimy tam super różowych okularów, ale idzie to zdecydowanie w dobrym kierunku. Tak jakby ktoś był zainteresowany budową czegoś i poznania lepiej COntainer Appsów, to może szkolenie będzie albo też w kontekście może naszej firmy Protopii też zgłosić się i chętnie postawimy, podzielimy się wiedzą jak to zrobić, żeby działało i żeby działało ładnie.

Łukasz Kałużny: Dobra, kolejna rzecz z naszego podwórka prototypowego, czyli Azure OpenAI Serwis, który jest tutaj na trialu. Nie wiem czemu, po prostu niech wpiszą to w Adobe i zakończą.

Szymon Warda: Tym bardziej, że opis co opisują w kontekście uzasadnienia czemu to jest trialu wskazuje jednoznacznie, że to powinno być w Adopcie.

Łukasz Kałużny: Tak, więc dla tych, którzy nie wiedzą, być może nie interesowali się LLM-ami to Open Azure OpenAI Serwis to jest po prostu z Enterprisowwiony OpenAI API po prostu hostowane w Microsofcie, które ma parę ciekawych funkcjonalności, takich właśnie tak zwanych Enterprise Grade. Powiedziałbym, że są ciekawe, potrafią kopnąć w tyłek również. To jest druga strona całości i też nie pędzą aż tak za pewnymi funkcjami, które widzimy w publicznej tej części OpenAI-owej,

Szymon Warda: Czyli też powiedzmy sobie szczerze, że też to jest serwis, który też się rozwija, ma swoje braki, nie jest super różowy i tam nie wszystko jest z pudełka de facto, ale tak, że jakaś organizacja, która jest jakkolwiek wymaga. Albo chciałbyś jakiegoś poziomu bezpieczeństwa tudzież zarządzania całą swoją infrastrukturą myśli o open jaju to Azure OpenAI nawet cytując Thoughtworksa jest kierunkiem jaki powinien być wykorzystany de facto

Łukasz Kałużny: Lecąc nasze doświadczenie projektowe, a Adopt, nie Trial, mimo to. Druga sprawa, którą wiesz jak sobie popatrzysz to tak kosztowo wychodzi. W sensie jeżeli ktoś ma się ładować w opensourceowe LLM i inne takie rzeczy w większości firm tego nie potrzebuje.

Szymon Warda: To jest tak samo jak budowanie własnej chmury nie ma sensu. Naprawdę trzeba mieć super wielką skalę, żeby budowanie własnych modeli miało sens.

Łukasz Kałużny: Tak w kontekście LLM to jest bardzo ważne w kontekście LLM-ów. Dobra, dobra, lecimy następne.Kolejny obszar platformowy. Dlatego zgodził się z Tobą, że faktycznie tu platform jest sporo. Interactive Organisation Platform, czyli platformy do orkestrowania infrastrukturą. I założenie jest takie tych platform, że zarządzanie kodem i Jacobem Account jest trudne. To się rozjeżdża, powoduje długi czas odpalenia. Nagle mamy sporo tych narzędzi. W ogóle jest budowanie wokół TerraForma żeby było powoduje, że potem mamy do wykonania, mamy zarządzanie plikiem stanu, kłopotliwe mamy problemy z rolami. Jest tego dużo. I teraz, żeby dać skalę, ile tych narzędzi wyrosło, to teraz listując: TerraGrant, teraz Terraspace, TerraForm Cloud Plum i Cloud F0 Space Lift, TakOS, Atlantis Digger, Skaler TerraMate, TerraTeam.

Łukasz Kałużny: Raczej wiesz co, jak popatrzysz to one nic realnie nie wnoszą.

Szymon Warda: Czy to dla mnie to jest tak?

Łukasz Kałużny: W sensie pozwól jedną rzecz realnie nic nie wnoszą, bo dają Ci jakieś uporządkowane podejście do CICD z lekkim wzięciem stanu względem innych narzędzi CICD nic nie wnoszą takiego super nowego.

Szymon Warda: To ja Ci powiem co one wnoszą, bo dla mnie moja reakcja na to jest taka, że ale ok, mamy narzędzia. Dobra, spoko, faktycznie realizujemy jakieś problemy, które istnieją, bo widocznie aplikowanie np. mieliśmy innego klienta, który miał jedno absurdalnie wielkie repoTerraFormowe,wiesz o którym mowa i tam faktycznie apply tego Terraforma to był kwestia godzin. No nie i to jest realny problem, ale mi się włącza czerwona lampka, że ale chwila, sekundę. Ten sam problem mamy i mieliśmy i nawet mamy w dużych monolitach de facto, że mamy wielkie repo i cały problem wychodzą ogarnięcie PR-ów, ról, dostępów itd itd. Ten plan już rozwiązaliśmy. Nie mówię, żeby dzielić te na mikro serwisy, bo to jest głupota de facto, ale nie podzielenie tego na moduły tylko na części związane z aplikacją, wydzielenie modułów platformowych, gdzie będą używały tylko modułów. Nie będę musiał mieć całej wiedzy o tym jak to jest hostowane. Mamy całe landing zone happen itd. Mamy na to rozwiązaniem na te problemy nie są kolejne narzędzia, tylko jest inne podejście do modelowania swojego kodu infrastrukturalnego. Zbudowanie platformy wokół tego wszystkiego będzie procesów co wykorzystywać, pewna standaryzacja, wypychanie modułów do wersjonowania, żeby to było zarządzane de facto przy pewnej skali, kiedy się to opłaca itd. Nie kolejne narzędzia to jest zmiana procesu i uporządkowanie organizacji de facto, a nie do kolejnego narzędzia.

Łukasz Kałużny: Wiesz co właśnie wiesz. Jak popatrzysz sobie porządkowanie i to promuje taki silosy centralne niby platforma, ale promuje silos. Takiego tutaj zaraz Cloud Center of Excellence będzie pokryte negatywnymi słowami i będzie miał negatywne konotacje, bo nagle się okaże, że jak zrobimy jedno CICD do części chmurowej do infry to co z częścią aplikacyjnym? Bo widzę już takie implementacje na rynku, że jest sobie Infrastructure as Cloud i to jest infra, jest usztywnione, ale drogi developerze, technicznie jeżeli chodzi o tą część aplikacji. To jest Twój problem. My tego tutaj w tym pudełku nie mamy.

Szymon Warda: To jest totalna odwrotność wartości platformy de facto. No tak też jest ciekawe czy dla mnie też 1 takie wrażenie można powiedzieć się nasunęło potem. Pamiętam rozmowę z taką osobą, która była bardzo mocno za Terraformem, taki religijnym powiedział nawet i po jakimś czasie właśnie wdrożenia Bicepa i przejęcia zespołu itd, itd. Stwierdził, że nie no w sumie to tTerraform jest fajne. Do środowisk nie musimy się utrzymywać, cały czas żyją de facto, ale takich on demand środowisk to Bicep jest fenomenalny, bo nie trzeba się stanem martwić w ogóle.

Łukasz Kałużny: Czy wiesz co? Wszystko ma wady i zalety

Szymon Warda: Ma, ale o co mi chodzi? Zauważmy, że de facto sporo tych platform wyrosło wokoło Terraforma, a one nie wyrosły wokoło takich narzędzi, które nie mają, nie zarządzają stanem. I ten stan jest świetny. Fajnie brzmi. Czym więcej wokoło tych tematów siedzę i wokół tych utwardzamy to się dzieje itd. I dojrzałości narzędzi właśnie typu Bicep, takich natywnych bez stanu tym mniejsza. wartość jest pliku stanu dla mnie..Dla mnie tak naprawdę on jest fajny, problemy z nim są naprawdę duże.

Łukasz Kałużny: Czy wiesz co jest fajne jak popatrzysz po moich rzeczach ten plik stanu i to sprawdzałem to jest fajne w części twardej platformowe gdzie masz tą część, taką twardą platformę? Oczywiście, że tam inne rzeczy, ale nie gdzie masz systemy, bo to się robi już problematyczne. Dobra, pójdźmy dalej. Teraz taka rzecz. Ashortowa de facto Cloud Events na Adopcie Patrząc się po projektach jakoś mnie nie dziwi. Po prostu. Dla przypomnienia Cloud Events to jest de facto skima eventów cloudowych, którą zapoczątkował De facto Microsoft oddał do CNC tą specyfikację i się rozeszło po rynku. Jeżeli chodzi o cloudach to z drugiej strony SDK dla różnych języków jak to obsługiwać? I nawet się zdziwiłem. Ktoś ostatnio do mnie dzwonił po poradę i się okazało, że przyjęli np. właśnie do przyjmowania eventów w firmie do swojego systemu przyjęli cloud event jako standard.

Szymon Warda: To ciekawe, bo to tak trochęunder the radar było. Przez jakiś czas powiedzmy sobie nie jest o tym głośno.

Łukasz Kałużny: Ale wiesz co, jak zobaczysz na konferencjach regularnie ktoś z tym występuje na temat cloud eventów to wiesz. W sensie to taka funkcjonalność. Jak popatrzysz sobie to w Google Cloud gdzie jest przekazuję Ci Azure Events i też lecą w schemacie cloud eventowych

Szymon Warda: standard bez żadnego wielkiego opóźnienia.Po prostu to się przyjęło.

Łukasz Kałużny: Tak i dobrze to wiesz i całościowo dla mnie ta specyfika jest dobra. Nie ma tutaj co robić. Jeszcze nawet chyba obawy. Z tego co kojarzę się wprowadziły schemat do pracodawców na bazie cloud eventów.

Szymon Warda: Tak, to kolejny element, który po prostu się przyjął. Można powiedzieć dobrze. Pulsy?

Łukasz Kałużny: Jeszcze w platformie ci dwie rzeczy zostały mój drogi Ice panel.

Szymon Warda: A to to to są twoje. Myślałem, że Ty wybrałeś też

Łukasz Kałużny: bo dzisiaj Szymon mi nie wkleił, więc..

Szymon Warda: Przepraszam najmocniej. Tak, faktycznie i w panelu dużo mówimy o C4 i czym jest C4? Podejście do architektury oczywiście 4 poziomy poziom całej ziemi, poziom kontynentów, poziom powiedzmy kraju i potem poziom powiedzmy ulicy. Czyli schodzimy. To, że nasze rysunki architektury na różnych poziomach mają różny poziom szczegółu, żeby nie mieć takiego pierdolnik w tych rysunkach problem z C4 zawsze był taki, że trochę nie było narzędzi wokół tego były narzędzia do rysowania, ale pojawiał się taki problem scalenia tego w jedną całość i wszedł właśnie Ice panel, który fenomenalnie pozwala na.Klikając zagłębimy się w schemat kolejnego modelu, kolejnego modelu, kolejnego modelu. Czyli możemy schodzić, wchodzić w górę i schodzić w dół. Bardzo to fajnie wygląda. Spróbuję, bo nie korzystałem jeszcze, przyznaję się,

Łukasz Kałużny: Więc zobaczymy. Cena droga jak za kolejny tool.

Szymon Warda: A nawet nie patrzyłem ile kosztuje.

Łukasz Kałużny: A wiesz co? Właśnie dlatego patrzę tam Darmowa jest spoko, bo jest do 100 modeli linkowanych, a jeżeli chodzi o wersję płatną to 40 dolców Za miesiąc, za kontrybutora jednego,

Szymon Warda: Za jednego kontrybutora. Tak to tak. I to jest wersja jeszcze nie izolowana de facto.

Łukasz Kałużny: No wiesz, ale dobra, to wiesz, tak sobie popatrzymy przy cenie miesięcznej to jest 50 dolców. Jak nie chcesz płacić pierwszych, tam 5 tam popatrzymy, to. No właśnie, bo sama koncepcja jest bardzo spoko. Czyli, że dostajemy software do zarządzania tymi C4 modelami w jednym miejscu. To może moje wrażenie takie ktoś wziął Enterprise architekta i chciał go zrobić po nowemu na C4.

Szymon Warda: Tak jedną rzecz powiem odnośnie tego poziomu darmowego to jest do 100 obiektów w modelach czyli to jest bardzo niski limit. No nie, faktycznie, bo może to jest twoje rozumowanie jest dobre w kontekście tego, że to jest konkurencja dla Enterprise Architect

Łukasz Kałużny: I innych tego rozwiązań Enterprise Architecture, które trącą myszką, rynkowo.

Szymon Warda: Tak, wygląda fajnie. Wydaje mi się, że jakieś alternatywy powstaną. Coś, bo ideowo to nie jest trudne, naprawdę nie jest trudne do implementacji.

Łukasz Kałużny: Ale w sensie wiesz też, że z drugiej strony dokumentacja ISD.

Szymon Warda: Też to jest o tyle fajne, że te pierwsze trzy poziomy mają sens, ten najniższy to w ogóle zapomnijmy o nim. Ten poziom, powiedzmy, to jest poziom aplikacji, de facto tam podział, które klasy, co robią, to to w ogóle nie ma sensu, ale te pierwsze trzy poziomy naprawdę mają sens. Czy bym płacił 40 dolarów za kompilatora? Nie, ciężko, Nie.

Łukasz Kałużny: Dobra, lecimy. Ostatnia rzecz z platform Fokus. I to jest ciekawa rzecz. W ramach Fundacji Fine OBS powstało właśnie Fokus,Fine OBS Cost and Used Specification. I teraz co jest ciekawe, czyli pomysł tutaj jest patrząc na całość jest na normalizację danych bilingowych z Cloud.

Szymon Warda: To ciekawe podejście

Łukasz Kałużny: Jako specyfikacje, czyli żeby to była specyfikacja.

Szymon Warda: Jestem mocno za, bo naprawdę ten obszar widzimy w sumie nawet, że już od dwóch lat sporo się dzieje wokół właśnie całego Tin-opsa. Ale działo się. Kubernetes plus duże platformy ludowe, ale to będzie wyrastają takie pojedyncze toole w różnych miejscach, które nie są ze sobą za bardzo powiązane. Fokus może to uzupełni. Zobaczymy, jaka będzie ta adopcja

Łukasz Kałużny: Tak, i co mnie cieszy w ogóle z tych jak popatrzysz sobie kto tam jest, no to mamy ten mamy, AWS-a Microsoft, Googla, Walmart, Salesforce, Oracle,

Szymon Warda: Więc Orban sax Facebooka

Łukasz Kałużny: Tak jest. No i jeszcze Accidenture. Patrząc na całość tutaj wyróżnionych Members i paru innych, których można byłoby podobnymi określeniami wrzucić. Wiem, że tłumaczenie to nie jest dobre, ale

Szymon Warda: Łukaszowi chodziło o Accenture

Łukasz Kałużny: I bardzo dobrze. Tak więc całościowo sama idea jest super.

Szymon Warda: Zgodziłbym się. Dobrze, że to złapałeś

Łukasz Kałużny: I patrząc się ten. Wiesz jedno, czyli jest dużo vendor ów, którzy powinni być z drugiej strony starting Komitet jest o tyle dobry patrząc się, że są ludzie z właśnie z Microsoftu od Pricingu z Googla i z Alvesa w komitecie sterującym. To też jest ważna sprawa. Inaczej tak narzucą standard. Ktoś może się będzie obrażać, że znowu BigTechowych narzucą standard do open source, ale o to chodzi żeby go potem spełniali tymi danymi.

Szymon Warda: Sorry, ktoś musi za godziny i dni pracy tych ludzi płacić, Ale to samo z cloud eventami. Tak czy mnie w ogóle zaskoczyło, że poszli w tym kierunku? No bo takie uspołecznienie będzie dobre dla rynku. Zobaczymy jak to będzie dalej.

Łukasz Kałużny: Dla klientów jest to świetna sprawa. Świetna. Tylko słuchaj, wiesz ile można się bronić przed tym? Bo zobacz, że z drugiej strony dla dużych dostawców Cludowych spowoduje to, że ich Cost Explorer będą mogły zaciągać dane z innych chmur.

Szymon Warda: Dokładnie. Dobra, lecimy?

Łukasz Kałużny: Tak dalej. Toolsy

Szymon Warda: Ja tu znalazłem kilka ciekawych rzeczy, bo tu jest dość dużo. W ogóle czy w Adopcie poza narzędziem do zarządzania zależnościami w C i C++, które ominiemy? Nie moja bajka, ale zaciekawiło mnie w ogóle, że tam jest mowa o Conanie co prawda, więc nie wiem co co tam się zadziało.To mnie zaciekawiło. Po pierwsze, że to jest generalnie Carpenter. Czym jest Carpenter? Carpenter jest auto skanerem klastra, Kubernetesowego. Tak, dokładnie. Dziękuję za uzupełnienie. Czy wiecie on skaluje ilość node ów jakie mamy nie pod ów notebook, czyli tych fizycznego obszaru takie auto, ale również trochę jak chociażby w AKS jeśli mamy klaster auto. Carpenter tym się różni, że on umie też skalować w dół w zależności od wymagań aplikacji. Czyli mówiąc prosto patrzy na machine resources i umie ten update skalować, co jest fajną opcją, bo nie trzeba będzie siedzieć z kalkulatorem i liczyć ile te aplikacje faktyczne potrzebują i czy nie mamy over powyżej ringu.

Łukasz Kałużny: Czyli tak w locie dobiera rozmiary maszyn wirtualnych. To co Szymon próbował przekazać czyli nagle z 8 Karowej zrobi ci cztero.

Szymon Warda: Jasne, tak. Co jest też ważne, to jest to, że ma już połączenie z większością vendorów chmurowych, łącznie z AKS-em, więc to fajna opcja, Zdecydowanie.

Łukasz Kałużny: Dobra, wiesz co, tak, jest to fajna. Tylko z drugiej strony Szymonie nie przeskoczysz odpowiedzialności autoskalowania albo wertykalnego skalowania.Vertical AutoSkalera wojej Twojej aplikacji. Bez tego to nie ma sensu.

Szymon Warda: Zgodzę się, nie przeskoczysz. To jest narzędzie, które ułatwia to, co jest ważne. Patrząc na raport, który mieliśmy parę odcinków temu odnośnie tego, że większość klastrów ma zbyt dużo zasobów, nie wykorzystuje ich dobry ruch w dobrym kierunku.

Łukasz Kałużny: Wiesz co, to jest nawet analiza, którą miałem dwa tygodnie temu z klientem na temat kosztów AKS-a. Okazało się, że usage CPU na klastrze 30nodowym wynosił 11% albo 12, coś takiego średni usage noda na CPU.

Szymon Warda: No właśnie tego to cieszę zdecydowanie.

Łukasz Kałużny: Dobra, polecimy dalej. U mnie Github Copilot, jest w Trialu i kurde tutaj z jednej strony korzystam na co dzień bardzo mocno i z drugiej strony w zależności od funkcji okazuje się, że Chat GPT-4 na zewnątrz potrafi lepiej odpowiedzieć nie oglądając mojego code base-u. I to jest tak, że niektóre funkcjonalności takie jak tam inline czaty gdzie mam tam slashdock do auto dokumentacji - świetnie, ale jeżeli wkleję ten sam przykład kodu i powiem co ma zrobić, a zrobię go w inline chacie np.to inline chat przekombinowane.

Szymon Warda: Czyli moje wrażenia w ogóle z takim juniorem do kodowania do pewnych zastosowań, a szczególnie tam gdzie nie znamy API, albo musimy zrobić coś w języku, w którym się nie poruszamy normalnie - świetny.

Łukasz Kałużny: Ale z drugiej strony np. to co jest auto competition z AI-em, czyli że generuje Ci większy kawałek kodu działa dobrze i to jest takie moje. Widzę w tym wartość. Nadal uważam, że za 100 dolarów rocznie za developera to jest niewiele, to jest niewiele i zwraca się o tak, ale z tym kurde trochę się zgadzam, bo można być, trzeba się do tego przyzwyczaić.

Szymon Warda: Dobra, to rzeczy jak mówimy o rzeczach, które nas cieszą, de facto ucieszyły. To mnie ucieszyło to, że pojawiło się GitHub actions runner controller dla Kubernetesa. O co chodzi? Będziemy mieli przypadki, kiedy potrzebujemy, żeby agent nasz siedział w wewnętrznej sieci de facto, może naszej wewnętrznej sieci, w której operujemy testów end-to-end wydajnościowych itd. Czasami chcemy tego puszczać na zewnątrz de facto, migracje bazodanowe itd. Więc tu nam wchodzą oczywiście agenci hostowania i samodzielnie. Jest większość narzędzi i większość systemów DevOps ma tą możliwość praktycznie, ale utrzymywanie ich to jest taki ból dupy po prostu. Jeżeli ja to mówię z pewnymi emocjami, bo to jest po prostu upierdliwe jak nie wiem co. Tym bardziej jeśli kustomizuje jakkolwiek. GitHub podbija wersje agentów bardzo często i jak nie będą utrzymywanie odpowiednio i będą aktualizowanie odpowiednio szybko to po prostu powie, że sorry, nie odpalę. I to wcale nie trzeba dużo czasu, żeby agent się zdezaktualizował. Tak naprawdę to naprawdę jest ból dupy. Tu wchodzi właśnie Action Controller dla Kubernetesa, który umie sam ich tworzyć, umie zwiększać ilość i ułatwia ogólnie zarządzanie tymi agentami. Jeżeli ktoś ma Cluster AKS, ma Cluster Kubernetesa, korzysta z GitHuba to to jest taki numb Raider. Po prostu korzystajcie i ciesz się.

Łukasz Kałużny: Ja bym dorzucił jeszcze jedną rzecz, a nawet dwie. Jesteś do tego zmuszony jak nie korzystasz z cloudu Microsoftu. Trochę tak, tak, tak, bo w wersji cebula pojawił się, ale to jest w gorszej funkcjonalności, bo można odpalać sobie na container Appsach.Tylko że niestety z Imiilem to jest problematyczne. To jest jedna rzecz, a druga fajna funkcjonalność. Można. Jeżeli płacisz za GitHub Enterprise to Worker ze swojej organizacji można wstrzyknąć do Winetu Azurowego i to jest taki feature, który tam się gdzieś nie przewijał się za szeroko, że powstał, ale jest spoko elementem inaczej. Ja z tym mam jeden problem samym tym, bo to bardziej jest do Continuous deployment tu agent teraz jeżeli jeszcze kompiluje inaczej jak chcemy robić CI-a bez wyrzucania poczekaj Szymon, nie kręć głową, chcemy robić Ci CI-a, w którym nie publikujemy kontenerów pokerowych to jest spoko. W szczególności jak mamy duże potrzeby. Dynamiczność tych worker ów to jest to spoko.

Szymon Warda: Czyli stwierdzisz, że generalnie budowanie aplikacji w klastrze AKSowym jest spoko

Łukasz Kałużny: Jeżeli klaster jest tylko posiada na zasadzie zamiast utrzymywania własnych VMek bo mamy np. jakieś rzeczy u siebie w sieci, do których musimy sięgnąć w trakcie sesji i inne takie rzeczy

Szymon Warda: To ja mam inne podejście. Ja mam podejście i lubimy continuous integration czyli budowanie aplikacji, testowanie kodu, czyli takie deweloperskie. To ja bym bardziej szedł w kierunku takim, że to wybitnie chciałbym mieć na tych właśnie maszynach zarządzanych przez GitHuba, DevOps czy czegokolwiek innego, żeby się nimi nie martwić.

Łukasz Kałużny: Teraz zobacz, że masz sytuacja nie masz Azure czy chcesz to zrobić w Onpremie? Masz np. jakieś prywatne Feedy?

Szymon Warda: A ok, w takim przypadku w takich.

Łukasz Kałużny: Czyli zgodzę się z Tobą, że jak możesz pozwolić sobie do budowania na hostowane githuba? Róbcie to od razu. No tak, tutaj w ogóle w sensie zarządzany worker nie utrzymywany przez nas to jest złoto, tak? I z tym się będę zgadzał. Ale jak nie masz takiego wyboru, to do Continuous Integration jest naprawdę spoko żeby osiągnąć jakieś tam cele, że ma się gdzieś to wewnętrznie, albo potrzebujemy naprawdę dużych workerów, bo też się takie przypadki zdarzają.

Szymon Warda: I jeszcze taki case. Może być też taki przypadek, że potrzebujemy jakichś narzędzi, których po prostu nie ma zainstalowanych i ich instalacja trwa długo, bo na workerach tych stawianych przez GitHuba też można jeszcze doinstalować, to to będzie uruchomienie i te cechy wolne, więc są przypadki. Ale ja tylko bym chciał, żeby to wybrzmiało było bardzo głośno. Jeżeli możemy korzystać z Workers, które są zarządzane przez GitHuba, korzystajmy z nich.Jakkolwiek łatwiejsze stało się utrzymywanie tych samo hostowane agentów, to dalej jest ból dupy. Mniejszy, ale ból dupy.

Łukasz Kałużny: Dobra i lecąc tym Kaniko, czyli budowanie kontenerów w kontenerze na Kubernetesie.

Szymon Warda: No dajesz. Ja mam co do tego dość konkretne uwagi

Łukasz Kałużny: inaczej, nienawidzę idei budowania kontenera w kontenerze.

Szymon Warda: Uważam, że to jest utrudnianie sobie życia de facto.

Łukasz Kałużny: Jest to nieprzyjemne, patrząc się, w jaki sposób ludzie mają z tego skorzystać. Więc uważam, że to jest nieprzyjemne jak ktoś nie ma życia.

Szymon Warda: Dla mnie to też średnio takie narzędzia jak Container Registry Azurowe ma możliwość budowania w sobie.

Łukasz Kałużny: Każdy container registry de facto jak sobie popatrzymy czy tak jak powiedzieliśmy, powtórzmy to co przy GitHub Actions. Jeżeli możesz robić to na zarządzanym worker, to rób to na zarządzanym worker.

Szymon Warda: Dla mnie Kaliko to jeden wielki problem. To jest narzędzie od Googla, które ma kolory Googla. Mamy ładne logo Google w ładnych kolorach, gdzie jest wyraźnie, że jest to narzędzie od Googla bez supportu od Googla.

Łukasz Kałużny: Tak oficjalnie leży sobie i to jest słuchajcie node.To jest pierwszy paragraf w repo po nazwie narzędzia.

Szymon Warda: Więc dla mnie to jak często Google ubija produkty to jest. Kurcze, ja bym się chyba nie zdecydował na to.

Łukasz Kałużny: Przy czym ma parę fajnych rzeczy np. zrzucanie sobie na różnego rodzaju blob storage, Azure, blob, zrzucanie sobie cache, layerów i innych rzeczy, więc narzędzie jest dorobione, ale może być upierdliwe w całości. Dobra, polecimy sobie do następnego. Do kolejnego toola to słuchajcie Open Policy Agent czyli dla Kubernetesa jak popatrzymy i też można poza Kubernetesem. To jest OPA. To jest wymuszanie na API jakiś zachowań czyli polityki po prostu. W Kubernetesie mówię, że nie wrzuć tego czy tamtego do całości, czyli do deklarowania i wymuszania polityk. I jak sobie popatrzymy z tym to pojawiły się alternatywy typu zawsze źle to wymawiam Havro bodajże, jako jedna z takich alternatyw do pisania w prostszy sposób tych polityk, bo jednak ten język, który jest pod spodem nie jest przyjemny do utrzymania i tego co powstało za OPO pod spodem. I tutaj on jest w trialu i de facto patrząc się, jeżeli całości nie potrzebujesz i chcesz robić to na nowo na Kubernetesie to są lepsze prawdopodobnie podejścia w tym momencie.

Szymon Warda: Ja się tylko dorzucę, że OPA czy Open Pulse Agent jest w CnC też element

Łukasz Kałużny: Jest używany też przez vendorów cloudowych pod spodem jako właśnie ten gate Keeper jest używany, że tak powiem przez innych.

Szymon Warda: Albo na bazie niego są kluczowe rozwiązania zbudowane tak, ale tak jak jest prostsze.

Łukasz Kałużny: Tak jak wcześniej byłem fanem, bo to CnC w ITN, no nie. Jak trzeba potem utrzymywać te polityki to lepiej mieć coś prostszy język do deklarowania tego.

Szymon Warda: Dobra, to ode mnie dużo mniejszy tool, ale ucieszyłem się bardzo, że to w tym kierunku idzie. Microsoft SBom Tool narzędzie, które umie wypluć z SBomba, czyli Software Bill of Material, czyli zestaw z czego nasz aplikacji korzystają czyli biblioteka, licencja, link itd. To jest o tyle fajne, że dzięki temu możemy wypluć do SPDX i to jest format, który przyjmuje inne narzędzia do zarządzania licencjami u nas w kodzie i do raportowania wokół tego mały tool jak ktoś potrzebuje korzystajcie. GitHub ma swojego, który też umie wypluwać. Czemu mnie to cieszy? Narzędzia, które automatycznie skanują nasze repo i monitorują biblioteki są absurdalnie drogie względem tego, co one robią.Można łatwo za pomocą właśnie takich niszowych narzędzi budować coś własnego, ale ogólnie mieć też governance wokół licencji, które stają się coraz ważniejsze, bo coraz częściej widzimy, jak rzeczy opensourceowe nagle mają zmianę licencji i to wszystko się trochę krzyczy. Mały a cieszy. Korzystajcie!

Łukasz Kałużny: Kolejny tool. W sumie tu jest w trialu.Backupowanie Kubernetesa, czyli Velero inaczej tu jest trialu. To takie podsumowanie tego. De facto, jeżeli potrzebujesz backupu Kubernetesa, czy nie potrafisz przenieść swoich aplikacji z jednego Kubernetesa na drugiego, bo ci CICD jest rozwalony i ktoś robił to z palca. Ale tak jest. Szymon wiesz o czym mówię.

Szymon Warda: Ja wiem, że tak jest, ale to mi przypomina sytuację jaką mieliśmy z maszynami fizycznymi de facto.

Łukasz Kałużny: Bo tak, pięknie to przenosi. O tak, działa super. Tu wykorzystujemy go z klientami tam gdzie się nazywa potrzeba backupu i też jeżeli macie support własne rozwiązania volumenowe u dostawców cludowych to również robi snapshot wolumenów, co jest już akurat genialną rzeczą razem z tym backupem.

Łukasz Kałużny: I to jest akurat bardzo clue. Jeżeli ktoś już się zdecydował, że potrzebuje tych nieszczęsnych wolumenów.

Szymon Warda: Nie uciekniesz od nich tak naprawdę. Mimo wszystko dobrze, idziemy dalej.

Łukasz Kałużny: To co języki i frameworki to Ty zaczniesz, bo chyba masz jeden tylko punkt.

Szymon Warda: W sumie, dwa na jednym się pokrywamy. Mnie zaciekawił ConcreteML. Czym jest ConcreteML? ConcreteML jest zbiorem narzędzi do machine learningu wykorzystujących konkrety. Czym jest Concrete? Podejście jest fajne, bo konkret jest. To się nazywa full homo morfic encryption, czyli szyfrowanie homo morficzne. Na czym to polega? Idea jest taka mamy zbiór danych, który jest zaszyfrowany, ktoś nam go wystawia, my na nim odpalamy nasze operacje ML-owe, robimy de facto nie mając klucza. Czyli ten zbiór jest cały czas zaszyfrowany. Dostajemy raport z tego, dostajemy wyniki i dopiero w tym momencie aplikujemy klucz na te same wyniki, czyli nasz. Operacje MLowe na naszym zbiorze zaszyfrowanym będą dawały takie same wyniki. Jednego się mapowały de facto pewien sposób co na zbiorze odszyfrowanym, czyli nie musimy danych odszyfrować. Jest to super w kontekście tego, że coś nam leży w chmurze nie musimy tego pobierać, bo tam wykonujemy te operacje zaszyfrowane i potem dopiero same wyniki odszyfrowujemy. Bezpieczeństwo fajnie jest to piekielnie wolne.

Łukasz Kałużny: Hahahahahahaha. No właśnie, bo wiesz coś za coś.No właśnie to jest problem.Co z danymi wrażliwymi? Jak do tego podejść?

Szymon Warda: I teraz problem drugi, który jest tym, że Concrete ML to nie jest to, że użyjemy zwykłego, tylko mają własne implementacje bo muszą na tych danych operować i wykonać komendę. Ja to wrzuciłem jako pomysł. Pomysł jest świetny, to nie wypali jak na mój gust, bo nie dość, że oni muszą mieć to będzie dużo wolniejsze. Muszą samemu pisać biblioteki, które mają takie same API jak popularne biblioteki Pythonowe. Naddganiać je trzeba cały czas, gonić w różnych wersjach, trzymać zgodność. Nie ma opcji sorry.

Łukasz Kałużny: Raczej sam koncept jest świetny.

Szymon Warda: Koncept jest przegenialny, wydaje mi się. Może w wąskich zastosowaniach, stricte medycznych jakiś takich bardzo, bardzo wąskich.

Łukasz Kałużny: Kurde, ale tam też nie możesz sobie pozwolić. Jak popatrzysz na przykład na Vision np.jak masz rentgen analizować albo tomografię.

Szymon Warda: Pomysł świetny, nie wydaje mi się, żeby wypaliło.

Łukasz Kałużny: Dobra, no to lecimy. Pierwsze Astro na trialu i patrząc się gdzieś w rozmowach w kuluarach to jest framework, kolejny framework Javaskryptowy i patrząc się całość gdzieś tam jakby to określić pojawia się, że nie jest upierdliwy. O tak, tylko ja już mam dosyć kolejnych. Patrząc się to już wyrosło jakiś czas temu, ale ciągle coś dochodzi w tym ekosystemie frontendu. Po jaką cholerę?

Szymon Warda: Dla mnie opis ma tyle hypewordsów, że ja przestałem czytać po kilku zdaniach o czym jest astro content website web application. IPI, stacki, internet, dobra. Dla mnie najciekawszy w dziale był generalnie long chain. A mianowicie to, że long chain jest na onholdzie i sytuacjach gdzie CloudFlare mówi offwork jest generalnie liderem, taką platformą frameworkiem, coś w tym stylu.

Łukasz Kałużny: No raczej frameworkiem. To można określić jasno.

Szymon Warda: Budowania LLM-ów gdzie prosto łączą dokumenty, wyszukiwanie z konkretnym modelem właściwie może tak to powiedzieć.

Łukasz Kałużny: Raczej tak, pozwalają zbudować całość.I teraz jak popatrzysz sobie podali np. Symantic Kernel i Microsoftowy, który jego mać 3 razy zmienił API w tym samym okresie życia, 3 razy zmienił API i koncepcje podane są tutaj właśnie alternatywy jaklight LLM i inne. Tylko ja patrząc się na ilość wiedzy na temat long chaina i na tego co się pokazuje, tego jak rozmawiamy z klientami przy tego typu projektach LLMowych to jest to jeden z dwóch opensourceowych narzędzi, które się przejawia w całości i wiedza na rynku jest dość spora.

Szymon Warda: Tylko że to jest bardzo mocna opinia o dość popularnym produkcie, więc ktoś tutaj komuś mógł zajść za skórę bym powiedział tak.

Łukasz Kałużny: I wiesz, pytanie albo ktoś się wyłożył na projekcie.

Szymon Warda: Tak, to może być też ten element de facto. Więc ciekawostka bym powiedział coś jeszcze Łukaszu?

Łukasz Kałużny: Ostatni punkt na dzisiaj w ramach, który pojawił się w trialu. Widziałem to na żywo już z 3-4 lata temu, czyli Rust for UI.

Szymon Warda: Słyszałem, widziałem, nieeee.

Łukasz Kałużny: Pokazany w Web Developmencie . Tu jest w trialu i sorry, czyli że w raście mamy pisać frontend? Kurde, naprawdę?

Szymon Warda: Rast nie jest do tego naprawdę.

Łukasz Kałużny: No właśnie i tutaj jak o tym myślę, nie rozumiem tej miłości do Rusta. O tak, to jest moje.

Szymon Warda: Ja ją rozumiem w kontekście rzeczy niskopoziomowych.

Łukasz Kałużny: W sensie dla mnie to jest idealny następca C++.

Szymon Warda: Tak, co pokazuje użycie rastra w kernelu linuksowym. Jak najbardziej. Poszedł sobie gdzieś tam do Windowsa również do tych elementów Security więc jest w tle, że jak to wszystko budują to tak samo jak byśmy pisali niskopoziomowe operacje na GPU w kodzie to na koniec będzie C, więc korzystajmy z języków tam gdzie one mają realną wartość, a nie wpychają wszystkiego wszędzie.

Szymon Warda: Tak, ale Rustowcy tak lubią. Więc tak, chyba każdy lubi De facto wciskać ten swój język wszędzie. Popatrz, na noda jest absolutnie wszędzie. Microsoft z dotnetem też próbuje.

Szymon Warda: No.

Łukasz Kałużny: Dobra, no to co? Kończymy?

Szymon Warda: Kończymy.

Łukasz Kałużny: Na razie. Trzymajcie się. Hej!