W najnowszym odcinku wkraczamy do świata, gdzie hardware goni za software’m, a sztuczna inteligencja wkracza na scenę z pompą.
Zastanawialiście się kiedyś, jak Discord radzi sobie z milionami użytkowników? Albo co się kryje za kulisami projektowania API, które łączy światy asynchroniczne?
Rozmawiamy o tym, jak duże firmy jak Microsoft stawiają na AI, przekraczając granice wyobraźni (i budżetów). A po drodze? Kubernetes bez tajemnic i dlaczego każdy developer powinien mieć swojego dev-proxy. Włącz się, bo dzisiaj technologia spotyka się z przyszłością… i to na naszych zasadach!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka na Patoarchitekci.io albo gdzieś lewo, prawo, góra, ogarniecie. I co Łukaszu, pochwalimy się też naszymi szkoleniami. Zaczynam ja. 21 lutego rozmowa i szkolenie o tym właściwie jak modelować bazy nie tylko w NoSQL-u. A czemu nie tylko w NoSQL-u? Bo modelowanie danych de facto to jest układanie danych pod nasze wymagania albo ograniczenia systemu, które mamy. Tak że trochę przejdziemy przez NoSQL-a, tam sobie zamodelujemy parę rzeczy, a potem przełożymy to bardzo ładnie na bazy relacyjne, z których i tak najwięcej korzystamy. A dzień później Ty ciśniesz ludzi z Kubernetes The Hard Way, czyli jak postawić Kubernetesa od zera i żeby zrozumieć jak to działa. Tak? Zgadza się?
Łukasz Kałużny: To tam wszystko jest, tak. Więc dwa całodniowe szkolenia na żywo online’owo. Dobra, lecimy Szymonie. To co Ty dzisiaj masz?
Szymon Warda: Pierwszy link jest dość ciekawy, bo on pokazuje bardzo ładnie przesunięcie, które się wydarzyło w zeszłym roku. Na bazie wyników finansowych wychodzi to, że Qul po raz pierwszy będzie wydawał więcej na hardware niż na ludzi. I to jest ciekawe, ponieważ jeżeli byśmy zobaczyli nawet wydatki państw, czegokolwiek, firm, to największym kosztem z reguły właśnie są płace, szczególnie przy takich wysokoumiejętnościowych zawodach, typu właśnie IT, żeby włożyć to w liczby. W tym momencie mówimy, że Qul planuje w przyszłym roku kupić 2 miliony jednostek TPU piątej generacji, każdy za 12,5 tysiąca dolarów. To daje 25 miliardów dolarów. Do tego dochodzi 30 miliardów innych wydatków na hardware. Więc mamy ile? 55. Microsoft planuje wydać 50 miliardów dolarów, jeżeli chodzi o chipy w przyszłym roku. Więc to pokazuje bardzo jak ten cały piękny wyścig, jeżeli chodzi o AI-a, będzie wszystkich dużo kosztował. Ja tu będę pesymistą. Dla mnie to mówienie, że a tak, bo może opensource’owe LLM-y tu coś jeszcze zawojują, albo będą alternatywą. Nie, nie będą. Nie przy tej skali pieniędzy.
Łukasz Kałużny: Skala kasy, to jest pytanie ile z tego jest na modele, trenowanie modeli, a ile też idzie w użycie przez innych klientów. Bo to jest taki ciekawy problem z tą infrą. Bo zobacz, że tak jak mówisz też w Microsofcie jest dokładnie ten sam problem, że Nvidie jest kanibalizacja pomiędzy ich użyciem a użyciem mocy obliczeniowej przez klientów.
Szymon Warda: Tak, natomiast budowanie generalnie możliwości tego, co będą odsprzedawali, ale to jednak pokazuje generalnie jak ogromne pieniądze wchodzą tutaj do gry. To jest jednak potężne.
Łukasz Kałużny: Wiesz co, jedna rzecz. W Google’u jest najciekawsze, że jednak TPU to jest, można powiedzieć, że ich autorska rzecz, więc i tak robią to właśnie, kupują, budują, to jest też dobre określenie, chyba lepsze w tym, że budują. I jestem ciekaw, ile by to kosztowało, gdyby tego sami nie projektowali.
Szymon Warda: Patrząc jak wystrzeliła Nvidia i akcje, to wydaje mi się, że dużo więcej mimo wszystko.
Łukasz Kałużny: Tak, zdaję sobie sprawę, że w tym, bo nawet nie wchodziłem nigdy kto dla nich to tak realnie produkuje, ten krzem pod spodem, bo to jednak są wygrzane ASIC-i, więc jestem ciekaw, bo sam TPU nigdy nie podali rozmiaru ile nanometrów jest, w jakiej technologi jest produkowane. O czwórce wiemy, że zakończyła się na siedmiu nanometrach i też tam, jak popatrzymy, np. clock speed nie był jakiś super porażający, bo 1000 MHz. Jestem ciekaw jak to wygląda i kto to produkuje.
Szymon Warda: Ale pamiętaj o jeszcze jednej rzeczy, to są dedykowane procki pod jeden konkretny cel. One muszą być superszybkie, bo one z definicji są bardzo mocno zoptymalizowane.
Łukasz Kałużny: Wiesz, ja sobie zdaję sprawę, po to robisz ASIC-a, żeby jak najtaniej wyprodukować wyspecjalizowany chip.
Szymon Warda: Dokładnie tak, żeby był cholernie szybki.
Łukasz Kałużny: Ale jestem ciekaw takich detali. Może sobie potem pogrzebię i się z Wami podzielę, bo w sumie dobra część, żeby zobaczyć. I wiesz co, jedno z tego Twojego linka, co jest śmieszne, chyba się nie nabijaliśmy z projektu Gemini?
Szymon Warda: Wydaje mi się, że nie.
Łukasz Kałużny: Wydaje się, tak, ale wiecie co, można to porównać, to jest moja perspektywa, na którymś Next’cie Google’owym był pokazany wirtualny asystent, trzy, cztery lata temu, umawianie wizyty do barbera.
Szymon Warda: Który oczywiście był fakiem.
Łukasz Kałużny: Tak. I tak samo wyglądają dla mnie aktualnie dema, które się pokazują w Gemini, że są dobrze wyreżyserowane.
Szymon Warda: Dla mnie to jest o tyle ciekawe generalnie i też jak Google będzie chciał umiejscowić swoje usługi AI-owe, bo MS od razu korporacje, itd. A Google jest firmą, która z reguły sprzedaje mniej do biznesu, a bardziej do indywidualnych osób.
Łukasz Kałużny: Wiesz co ja bym powiedział, że nie indywidualnych, a w tej części cloudowej do biznesu SaaS-owego.
Szymon Warda: Cloudowej tak, ale pewne, że też będzie wykorzystanie generalnie też jako SAS-y do ludzi. Więc Google stoi, bardziej klientami tego clouda budują dopiero.
Łukasz Kałużny: Jestem ciekaw co z tego zrobią.
Szymon Warda: Co tam masz?
Łukasz Kałużny: Ja pierwszy taki luźny link. Zawsze mi się morda cieszy jak widzę keep it simple.
Szymon Warda: To jest zawsze wesołe.
Łukasz Kałużny: Tak i teraz jest Keep it Simple Frameworks.
Szymon Warda: Trochę odwrotnie niż powinno być, ale niech będzie.
Łukasz Kałużny: Ale całość jest, jeżeli tam popatrzymy sobie, prezes Netflya tam w trakcie jakiejś konferencji, już nawet nie wchodząc z tym, mówił, że ten Jamstack cały do budowy tych aplikacji webowych za bardzo się rozrósł. Tak można byłoby to podsumować troszeczkę. Czy nie pora na upraszczanie w tym.?
Szymon Warda: W końcu dobra perspektywa, bym powiedział.
Łukasz Kałużny: Sądzę, że i tak przesadzą ze sposobem konfiguracji i innych elementów, które są, ale zobaczymy jak to będzie wyglądało.
Szymon Warda: Ja w kontekście w ogóle upraszczania, itd., to ja będę miał całkiem fajny link dalej, ale też nie teraz. To ja jeszcze inny, znowu będzie społeczny, jest całe zamieszanie wokół Poczty Brytyjskiej. I o co tam chodziło? Tam chodziło o to generalnie, że kierownicy poczty, tych oddziałów byli skazywani i nawet były samobójstwa, ponieważ byli ścigani za braki, błędy finansowe w sofcie Fujitsu, który generalnie był wdrażany. I wyszło na jaw, że Fujitsu wiedziało o tym, że soft zawiera błędy, więc cała sprawa jest dość rozdmuchana generalnie. Ale Fujitsu przyznaje, że faktycznie popełnili błąd i że będą chcieli wziąć udział w rekompensatach i generalnie w całym procesie. To bardzo fajnie pokazuje w kontekście odpowiedzialności za bugi i za jakość software’u, bo to się powoli zmienia, wydaje mi się, mentalnie. Kiedyś to była taka dzika bonanza, a coraz więcej ostatnich wydarzeń pokazuje, jak ściganie ludzi, też z innych organizacji, że jednak nasz przemysł dorasta i jednak będzie wyciągał odpowiedzialność za błędy, bo ten software to już nie jest prosta kalkulacja albo gry, to są rzeczy, które decydują o życiu ludzi. Naprawdę jestem bardzo ciekawy, jak to się dalej rozwinie, bo ok, Wielka Brytania może nie jest już w Unii Europejskiej, ale to są kolejne przykłady na nieamerykańskim prawodawstwie. Czyli bardzo różne prawodawstwo do polskiego, europejskiego, tak że wydaje mi się, że jakimś tam precedensem to mimo wszystko będzie. Może nie stricte prawnym, ale będzie jakimś tam społecznym.
Łukasz Kałużny: Raczej inaczej jest pokazywanie, że wdrożenia super dużych systemów zawsze są porażką, w szczególności pudełkowych.
Szymon Warda: Może tak, trudne są generalnie, niekoniecznie porażką, ale są trudne.
Łukasz Kałużny: Dobra, z mojej strony coś, co w ogóle przegapiłem, że Microsoft wydał. Słyszałeś o czymś takim jak dev-proxy?
Szymon Warda: Nie, nie, przyznaje się, nie.
Łukasz Kałużny: I słuchaj i dobrze, bo mamy co? Dev-proxy to jest proxiak do… Poprzednio to było 3.6.5 Developer Proxy, Microsoft 3.6.5 Developer Proxy, żeby mockować. I zrobili teraz z tego uniwersalne narzędzie, żeby zrobić po prostu proxy server do mockowania, czy z nowym realisem, co mi się spodobało i na to zerknąłem. To też jest opensource. Są przykłady np. wstrzykiwanie failure rate, błędów i innych takich rzeczy w trakcie developmentu.
Szymon Warda: Widzę właśnie, że MS coraz mocniej idzie w ogóle w chaos engineering, bo tych ogłoszeń odnośnie tematów wokół chaos engineeringu w ciągu ostatniego pół roku trochę było.
Łukasz Kałużny: Tak, ale jest właśnie ciekawe, bo masz tak symulacje błędów, throttlingu, rate limitingu, tam oczywiście mockowanie i inne takie elementy. Fajną rzeczą jest dla kogoś, kto pisze gdzieś tam na stos Microsoftowy, to jest te Graph API, pozwala fajnie sproxować to. Ale z drugiej strony coś, co mnie urzekło w tym, trochę patrząc takiego dev experience, że ma abstrakcję presetów. Czyli tak jak masz w Postmanie wszystkie presety i zestawy, to na razie wiadomo, tutaj nie ma sweetaśnego UI-a takiego i innych rzeczy. Ale możesz zrobić dla zespołu presety np. przy mockowaniu, odpalaniu i innych takich rzeczach. Więc to jest taka wiesz, taka popierdółka, która w innych tego typu rodzajów nie widziałem do końca tych takich presetowych rzeczy.
Szymon Warda: Ja powiem tak, można dużo hejtu na MS wylewać, jednak takie credit where credit is due podejście to jest to, że faktycznie narzędzia dla developerów mają dobre. Tutaj faktycznie MS stoi dobrze, więc dobry ruch w dobrym kierunku. Dobra, to ja teraz inne. Link, długi link i będzie dużo bardzo skrótów. Ale jeżeli ktoś tego potrzebuje to jest strzał w dziesiątkę, bo jest świetne w ogóle. NSA, Amerykańska Agencja Bezpieczeństwa oczywiście, ta która zasłynęła oczywiście ze Snowdena, itd.
Łukasz Kałużny: I innych rzeczy.
Szymon Warda: I innych rzeczy, ale też kawał software’u tam się dzieje i tam się dzieje dużo. National Security Agency opublikowały dokument, 45-stronicowy dokument, odnośnie podejścia do opensource’u i wykorzystania rzeczy z opensource’u. I dokument jest świetny. Dobra, on skupia się na czterech obszarach, jeszcze bardziej układa proces wokół opensource’u w czterech obszarach - zarządzania opensourcem, to jest w ogóle pierwsza, tworzenie i zarządzanie wewnętrznymi repozytoriami. To jest ciekawe, ale to ma sens, jak się popatrzy na pozostałe rzeczy. Utrzymanie, wsparcie i zarządzanie sytuacjami krytycznymi, tworzenie z SBOM-u, czyli Software Bill of Materials i walidacja artefaktów. Dokument ma 45 stron, więc nie będziemy tutaj dokładnie przechodzi. Ale w ogóle nie wiem czy pamiętasz, jakieś pół roku temu mówiliśmy właśnie o tym inquisitive order.
Łukasz Kałużny: Właśnie tak, to jest wynik tej inicjatywy, że zaczęli to porządkować.
Szymon Warda: Szybko.
Łukasz Kałużny: Trzeba przyznać, że szybko.
Szymon Warda: Pół roku temu to śmignęło gdzieś tam w newsach.
Łukasz Kałużny: Na początku tego sezonu bodajże chyba nawet.
Szymon Warda: Tak, dokładnie, przewidzieliśmy, że coś się będzie działo. Dobra, teraz przejdźmy przez zarządzanie opensourcem. Co tam w ogóle, co radzą? Fajnie jest, bo ten dokument zbiera prawie wszystko, co się dzieje na rynku, w jedno miejsce. Wyznaczenie ról w organizacji do zarządzania, co mimo wszystko jest bardzo ważne, śledzenie aktualizacji, śledzenie licencji. Teraz jest też, proponują proces jak wybierać opensource? Przez badanie Software Composition Analysis, czyli sprawdzanie wersji, sprawdzenie bezpieczeństwa, licencji, rozwoju i wsparcia. Czyli generalnie po prostu czy ten kawałek jest w ogóle sensowny. Dalej, skanowanie w poszukiwaniu wirusów, fuzz testing, czyli wstrzykiwanie błędnych, ale potencjalnie niebezpiecznych inputów i patrzenie co się dzieje na dedykowanych środowiskach. Tworzą rekomendacje dla developerów, przy wyborze, idziemy, rozpoznanie licencji. Głównie opisują procesy w organizacji, co jest bardzo fajne, rozpoznanie licencji, historia podatności, co jest też dość ciekawym obszarem. Ocenianie wartości adopcji kontra wewnętrznego developmentu, co normalnie brzmiałoby jak: o Jezu, po co w ogóle takie rzeczy robić? Ale mamy Node’a i wszystkie mikro paczki generalnie, tak że to może nie być taki zły pomysł.
Łukasz Kałużny: Powiem Ci tak, jak pomyślę sobie o świecie Javowym czy .Netowym czy Golangowym, to brzmi spoko.
Szymon Warda: To naprawdę brzmi spoko.
Łukasz Kałużny: Raczej ja w kontekście np. backendu w ogóle się do tego nie przyczepię.
Szymon Warda: Ja widziałem dużo, sorry, ale głównozależności wersji alfa, które utrzymywały się przez długi, długi czas do jakichś małych pierdółek.
Łukasz Kałużny: Ale jak sobie popatrzysz na backendowe języki poza Nodem i Pythonem, to nie jest źle. W sensie nie jest źle całościowo, ale jak pomyślę teraz o tym jak wygląda… Zresztą u jednego klienta przecież się po dziś dzień wozimy z podatnościami Pythonowymi, bo mają takie, a nie inne podejście, a tak lecą zależności. Nie mówię już o Node’zie i frontendzie.
Szymon Warda: Tam będzie tego. Ale teraz wracamy do artykułu, bo tam dalej się dzieje jeszcze lepiej. Proponują wykorzystanie OpenSSF Scorecard, czyli do analizy komponentów. Co to robi? To generalnie fajne narzędzie, które patrzy na dojrzałość procesu wytwarzania pakietu powiedzmy sobie, czy te nasze zależności, czy tam software’u jakiegokolwiek i ma wewnętrzne heurystyki, które oceniają to, na co patrzą, tak z ciekawości. I to nie jest CI/CD. Wykorzystanie fuzzingu, czy jest używany na licencje? Ciekawe rzeczy, między innymi to jest też jaki jest rozstrzał zatrudnienia pracowników czyli kontrybutorów, bardziej może tego. Czyli pracują w jednej organizacji czy w wielu organizacjach? Cała lista, jest taki cały ładny checklist, który generalnie po prostu daje nam odpowiednie punkty. Mega sensowne. Idziemy dalej. Wykorzystanie Vulnerability Exploitability eXchange, czyli dokument generalnie, który nam robi bardzo ciekawą rzecz, ale przydatną. W ogóle to jest dokument sprzed dwóch lat, 2022. Mapowanie, który komponent jest potencjalnie podatny na którą podatność, czyli mapowanie zależności pakietów do komponentów. Czyli w tym momencie mamy jakąś podatność, nam wychodzi, to od razu dzięki temu wiemy, które obszary systemu potencjalnie są narażone. Super rzecz. Dalej, wykorzystanie BAS płatności, nie tylko wykorzystanie CVE, czyli Common Vulnerabilities and Exposures, NVD, National Vulnerability Database, ale też wykorzystanie OSV, Open Source Vulnerabilities, z przykładów, które dają, bo też dają przykłady, z których korzystać. Wykorzystanie od CISA KEV, czyli Known Exploited Vulnerabilities Catalog to jest w ogóle, CISA, to jest Cyber Security Infrastructure and Security Agency.
Łukasz Kałużny: Odpowiednik tak jak z NASK-u mamy tego carta narodowego, to jest odpowiednik tej instytucji.
Szymon Warda: Idąc dalej, to jeszcze polecanie EPSS, czyli Exploit Prediction Scoring System, czyli systemu generalnie właśnie z mapowania, generalnie jak coś nam wybuchnie, to jak bardzo nas to zaboli.
Łukasz Kałużny: Wiesz jaki mam z tym problem, z całością? To jest do systemów krytycznych.
Szymon Warda: W tej wersji, w której jest? Tak. Ale ja na to patrzę inaczej. Jeżeli ktoś buduje jakąś politykę bezpieczeństwa, to po prostu to jest wzięcie tego dokumentu i skopiowanie odpowiednich fragmentów całości.
Łukasz Kałużny: Nie, inaczej, tak jak patrzy się open source management, czyli w ogóle świadomość licencji czego mamy? Spoko, bardzo się zgadzam. Samodzielne np. tworzenie Scorecardów, mapowanie tego wszystkiego, w niektórych ekosystemach, Szymon, moim zdaniem to jest w ogóle na zasadzie nagle się okazuje, że potrzebujesz full time job, zespół, który będzie Ci analizował, albo kawałek firmy.
Szymon Warda: Wiesz co, wydaje mi się, że generalnie to w innym kierunku będzie szło. To jest to, jak mówiliśmy, jak omawialiśmy ten case, że będzie to szło w kilku kierunkach. Po pierwsze, automatyzacji zależności, coś, co powinniśmy już od dawna zrobić, czego nie robimy, to jest przerąbane.
Łukasz Kałużny: Tak, ja chciałem ci powiedzieć, jak na część z tych rzeczy popatrzysz zupełnie, to dobre serwery artefaktów. Weźmy np. JFrogowe Artifactory z Xrayem przykładowo, czy GitHub Security, Advanced Security i inne takie rzeczy. No to większość z tych rzeczy kończysz na dobrym Bill of Materials.
Szymon Warda: Na SBOM-ie tak, dla mnie wartość tego całego dokumentu. Procesy właśnie w kontekście dla developerów i pewne… Ponieważ tak, to jest narzucanie właśnie dla systemów krytycznych, czyli całej infrastruktury tak naprawdę, bo też. Jeżeli to będzie adoptowane, to wydaje mi się, że generalnie to będzie, tak samo jak projekty kosmiczne, powoli, powoli to będzie skapywało do zwykłych projektów i po prostu będą narzędzia, które się tym zajmują i automatyzują te wszystkie procesy. Bo robienie tego ręcznie przez dowolną korporację w tym momencie, która produkuje jakiś tam Enterpriseowy, nie ma żadnego sensu. Wartość jest taka generalnie, że byśmy mieli te Scorecardy, byśmy mieli wszystkie zautomatyzowane w projektach. Tak samo jak np. w GitHubie masz SBOM-a, możesz pewne rzeczy robić, masz wyciąganie licencji, to się już wydarzyło. Więc wydaje mi się, że to już przyszłość leży w tym, że będziemy mieli projekty, które będą już to miały gotowe po prostu.
Łukasz Kałużny: Raczej to będzie w toolingu. Nie, bo teraz mówienie: ja sobie widzę niebezpieczeństwo, jak słyszę słowo proces, uważam, że one powinny być. Tylko w firmach, kiedy nie masz narzędzi do tego, to ten proces staje się, to już jest tzw. mocno biurokratyczny.
Szymon Warda: Tak, pamiętaj, że generalnie, że żeby narzędzia powstały, to musi być jakiś proces, który można ustandaryzować i jest sens go automatyzować. I w tym momencie ewidentnie i jest ten element zapłonu, że ok. Zacznie być sens to robić, bo narzędzia, które robią skanowanie licencji, itd., one są absurdalnie drogie względem swojej złożoności. Mówimy o dziesiątkach tysięcy dolarów licencji.
Łukasz Kałużny: Chociaż z drugiej strony chyba JFrog tyle nie..
Szymon Warda: Wyciąganie zarządzania licencjami to są dalej drogie. JFrogowe też wychodzi drogo.
Łukasz Kałużny: JFrog, z tego co pamiętam, on kosztował, nie pamiętam z Xrayem, ale nie mówimy tutaj o tych… Mówimy pewnie o jakichś kawałkach 45-100 000 rocznie.
Szymon Warda: Zgadza się, tylko mówimy o software’u, który defacto wyciąga i sprawdza licencje tak naprawdę.Robi trochę więcej, nie tylko licencje, bo jest całym serwerem tak naprawdę. Mówię też o Xrayach i innych takich rzeczach, więc trzeba go całego wdrożyć, żeby skorzystać z tego co daje.
Szymon Warda: Zgadza się, ale sam nawet software licencyjny, który niewiele robi, one są drogie właśnie, bo są generowane raporty. Więc to w tym po prostu, jest na razie, realnie powstaje potrzeba. Zostało to ustandaryzowane, zebrane w jedno miejsce, więc tylko czekam, aż to wyrośnie prędzej czy później tak naprawdę, albo rozszerzą się możliwości istniejącego software’u. A że ten dokument jest rozdmuchany, do większości organizacji, oczywiście, że jest, to nie budujemy elektrowni atomowej w większości sytuacji. A jak ktoś buduje, to napiszcie.
Łukasz Kałużny: Tylko nie publicznie.
Szymon Warda: Dla mnie ciekawiej, bo większość… Znaczy większość firm. Firmy zaczynają już myśleć o tym, co zrobić z open sourcem, bo to już nie jest taka bonanza generalnie, że używamy open source’u i nikt się tym nie martwi, prawda? Ta sinusoida się odbiła de facto i zaczęła myśleć o tym, co z tym zrobić? Chociażby jak patrzenie na licencje, chociażby poprzednie podatności, patrzenie na to generalnie, ile ludzi utrzymuje to, patrzenie na to, jak to się rozwija, jak to było rozwiązane, itd. Zrobienie wokół tego procesu, żebyśmy nie wybierali znowu gównozależności, dla mnie ma sens i to jest clue, takie nam będzie przydatne. Na wszystkie pozostałe ja czekam na komercyjne rozwiązania, które będą to adresowały. Albo open source’owe, może ktoś wokół tego jakiś projekt zbuduje też, albo nie jeden pewnie. Tak że tyle.
Łukasz Kałużny: Dobra, to lecimy sobie dalej. Taka teraz ciekawostka, w jaki sposób obsługuje milion userów od strony utrzymywania stanu Discord? I całościowo, to jest tam bodajże z października zeszłego roku to opisali, teraz mi to wskoczyło, ciekawostka nazywa się, że wykorzystują Elixira.
Szymon Warda: Co pasuje idealnie, bo Elixir był pisany do centralek telefonicznych.
Łukasz Kałużny: Raczej Erlang, bo jest nad maszynę wirtualną Red Langa. Więc ciekawy artykuł pokazujący, opisujący cały proces jak dochodzą całości, w jaki sposób rozrzucają, ile utrzymują sobie PR proces. Jest pokazane w ogóle w jaki sposób to funkcjonuje. Więc fajnie sobie zobaczyć w jaki sposób taki high performance może działać. Jest to dość wysokopoziomowe wchodząc w jakieś niektóre problemy, które trafili. Więc to jest taka ciekawostka, żeby zobaczyć jak to w ogóle wygląda.
Szymon Warda: Ja myślę, że on jest całkiem niezły, nawet jeżeli nie piszemy w Erlangu/Elixirze, to jest architektonicznie fajnie.
Łukasz Kałużny: Tak, bo kodu samego jest tam 16 linijek na całość, więc nie ma tutaj sensu zaglądać. I moim ostatnim linkiem…
Szymon Warda: Fajne, fajne.
Łukasz Kałużny: Tak, jest to rzecz, która się przewija, czekam aż przebije się do końca. Jest AsyncAPI. Artykuł w dobry sposób pokazujący komponenty samego AsyncAPI, na szybko pokazujący przykłady. I dla niesłyszących o AsyncAPI. AsyncAPI jest sposobem dokumentacji API asynchronicznych, czyli messagingu. Jest odpowiedzią na to, co mamy Swaggera OpenAPI. I tam jest fajnie, bo jest kilka dobrych building blocków, które mówią. Czyli mamy aplikację. Co jest potem? Potem mamy Sendera, czyli kto wysyła, Receivera, czyli kto odbiera, Channel, czyli mechanizm komunikacji, protokół, jaka jest wiadomość i jakie są bidingi. Czyli pokazuje całą taką ścieżkę, którą mamy przy używaniu architektury event-driven.
Szymon Warda: Ja pamiętam, że to AsyncAPI, pierwsza propozycja, to było sprzed 4 lat, to się pojawiło wtedy?
Łukasz Kałużny: Tak.
Szymon Warda: Coś w tym stylu generalnie. Ale pokazuje ile czasu zajmuje, żeby faktyczne projekty się przyjęły.
Łukasz Kałużny: Teraz najważniejszą rzeczą, którą zobaczyłem, to jak wygląda Code First. I jeden z linków nie jest tak. Jeżeli popatrzymy sobie, to mamy tak, mamy .Neta, Noda, Pythona, Golanga, Javę w jakiś tych rzeczach, więc jest tego trochę. Jest gdzieś tam natywnie dla Nesta, dla Kotlina, dla Scali, więc powoli, powoli wszystko się pokrywa. I jeżeli teraz popatrzymy, wyciągnąłem sobie, niestety gdzieś tam w sercu jesteśmy .Netowcami, więc zobaczyłem jak wygląda Lipka. I okazuje się, że Lego utrzymuje Lipkę do AsyncAPI .Netowego, co załączyłem w linku. I to jest rzecz, która od strony dokumentacji, tak jak już restową nawet nieźle możemy zdokumentować, jeżeli chcemy, to jest taka kolejna rzecz, na którą patrzę, że następny klocek do układanki. Bo messaging, to mi przyznasz rację, jest wrzodem na tyłku, jeżeli chodzi w tym momencie o dokumentację, jak i o robienie distributed traceingu observability.
Szymon Warda: Z dokumentacją to jest absolutna padaka. Distributed traceing, już się pojawiły wtyczki do popularnych bibliotek, jeżeli chodzi o wysyłanie wiadomości. Ale dalej to są jakieś tam powiedzmy śladowe projekty.
Łukasz Kałużny: Tak, bo traceing, tak jak rozmawialiśmy, jak zrobić spany i inne zabawki, jak to pokazać, to nie w sensie messaging, jeszcze od strony observability nie jest unormowane.
Szymon Warda: I dalej jest dzikim zachodem, to się często kończy na tym, że trzeba to robić ręcznie, bo coś gdzieś czegoś nie wspiera.
Łukasz Kałużny: Tak i coś wymyślamy na nowo. Dobra, to co, kończymy. Na razie.
Szymon Warda: Na razie, hej.