Szymon Warda: Cześć, Słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: …I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io tym razem /76 albo gdzieś w tym playerze, w którym słuchacie na dole w opisie. No dobra, Szymonie, to zacznijmy od tego tajemniczego, bo jestem ciekawy. Szymon mi schował jakiegoś linka i nie powiedział… To co dzisiaj będzie?

Szymon Warda: To ja Ci powiem taką sytuację. No nie? Idźmy. Problem, rozwiązanie. Chcemy taką sytuację mieć, żeby mieć jasny ownership. Kto zarządza jakimś konkretnym repo. Idziemy sobie w repo per powiedzmy serwis, rozdzielamy te repa, wiemy kto odpowiada. I w tym momencie mamy problem. Problem jaki jest? Jak wprowadzamy globalne zmiany. No nie? Ciężko, nagle musimy dziesiątki, setki, tysiące PRów robić w różnych repach, to koordynacja tego jest trudna. Jakie mamy rozwiązanie, możemy to zautomatyzować. Na przykład załóżmy - możemy sobie stworzyć obraz dockerowy, który korzystając z tooli linuksowych, z takich normalnych tooli do modyfikacji tekstu… Będzie nam automatycznie wprowadzał te zmiany. Dobra, temat jest - problem tej samej, takiej natury - jak namierzyć… Gdzie są jakieś zależności i jak na takiej dużej ilości repo wprowadzić te zmiany, no to mamy rozwiązanie. Możemy sobie użyć Java BOM - Bill of Materials generalnie, żeby określić które repo co wykorzystuje i może obsłużyć Kubernetesa i tam disclosure że poda tego obrazu dockerowego, który będzie te zmiany wprowadzał na tych setkach, tysiącach rep. I tworzył pull requesty, no nie? Ale nagle jest problem, bo nagle mamy setki tysiące pull requestów w różnych repach i nagle koordynacja tego jest trudna, czyli dużo roboty ludzkiej.

Szymon Warda: No dobra, takie mamy rozwiązanie. To są oczywiście autoPRy, że wystawiamy PRa, potem go automatycznie mergujemy, nie.

Łukasz Kałużny: Jeżeli są testy.

Szymon Warda: I całość brzmi mega skomplikowanie. Żeby nie było, że to jest w ogóle coś wymyślone przeze mnie, to jest to artykuł od Spotify’a.

Łukasz Kałużny: Znaczy wiesz co, z drugiej strony wiem jak to… Od tam… Ty też wiesz, od znajomych, jak to działa w Google’u i że takie mechanizmy tam działają zajebiście, ale w Monorepo.

Szymon Warda: Właśnie.

Łukasz Kałużny: Właśnie.

Szymon Warda: Właśnie tu chodzi o to, teraz żeby dać liczbę. Spotify w ten sposób w 2022 roku ogarnął 270 tysięcy pijarów, z czego 77 było automergem. I teraz moje pytanie, jest teraz takie, bo cały proces wygląda bardzo imponująco, ale modyfikowanie zależności korzystając z tooli linuksowych i w tym automatyzacja… Czy oni sobie nie stworzyli problemu sami z siebie? Bo wydaje mi się, że się wkopali w dołek, właśnie powiedziałeś… Monorepo by to rozwiązało bez większego problemu. A nagle mamy problem tej synchronizacji, mamy backstage’a, który koordynuje co się gdzie wywaliło. Jak działa i tak dalej… Absurdalny wręcz narzut pracy na problem, który można rozwiązać po prostu ludzko, łatwiej.

Łukasz Kałużny: Tak. Druga sprawa wiesz, to jest też… Czasami w zależności jak wyglądają i zbudowane zależności są paczki i inne rzeczy. Dużo ludzi często ma przy pewnych rzeczach wstręt do publikowania wewnętrznych paczek.

Szymon Warda: Nie wiem, czemu. To jest w ogóle podstawa.

Łukasz Kałużny: Ale w sensie bo kojarzysz, że jest bardzo często - sklonujmy repo i sobie zbudujmy tą binarkę, bibliotekę, whatever. Zaciągnijmy. A są mechanizmy czy to jak pójdziemy sobie na githuba, ten Dependabot czy inne, które na tej podstawie potrafią to zrobić automatem.

Szymon Warda: Tak. Tylko że Dependabot podbije w repo na… Bo to właśnie w konteście repo. A to chodzi o odbicie tego globalnie, wszędzie, żeby zależności były spójne.

Łukasz Kałużny: Czyli publikujesz nową wersję paczki i to Ci się rozprowadza po de facto organizacji.

Szymon Warda: Tak. Tylko najpierw musisz skoordynować we wszystkich repach, czy wszyscy podbili. To jest ten problem, no nie.

Łukasz Kałużny: No to słuchaj, wiesz, zawsze będą takie problemy.

Szymon Warda: Tak, ale zobacz, załóżmy, że normalnie na poziomie pojedynczego repo mamy do tego toola, które działają i działają od dziesiątek lat. A jak nagle rozbijemy to zbyt granularnie, bo z całym szacunkiem… Ale wydaje mi się, że w Spotify’u zbyt granularnie to zrobili, że mimo tak absurdalnej ilości rep, bo że potrzebują aż takiej automatyzacji - i spójrz na prepaid, 270 tysięcy pijarów to jest dużo. I ciekawi mnie ile z tych pijarów jest na poziomie generalnie, że musimy właśnie ten narzut na podbijanie w lewo i w prawo zależności. No nie. Więc ciekawy link. Artykuł długi, naprawdę bardzo, bardzo długi, warty do przeczytania i przemyślenia. Bym tak to powiedział.

Łukasz Kałużny: I zachęcę jeszcze do naszego starego 27ego odcinka, bo go teraz wykopałem pod tytułem Patologie Mikroserwisów - Repozytoria.

Szymon Warda: Tak, artykuł… On się czyta, on ma sens, ale jak się cofniemy chwilę do tyłu i powiemy czy to na pewno jest potrzebne? Nie, dla mnie, dla mnie zdecydowanie nie. I pozostałe artykuły właśnie z tej serii też całkiem są niezłe już, do przeczytania tak naprawdę.

Łukasz Kałużny: No, jestem właśnie ciekaw.

Szymon Warda: Dobrze, teraz coś Ty rzuć.

Łukasz Kałużny: Dobra, ja teraz rzucę, a zacznijmy, bo marudzimy na Kafkę. Ktoś nam kiedyś wspominał o Redpandzie.

Szymon Warda: Pamiętam, było.

Łukasz Kałużny: Dokładnie i ktoś tutaj stwierdził, że sprawdzi w takim razie… Wykresy, którymi się reklamują.

Szymon Warda: O, jak miło.

Łukasz Kałużny: Poszedł Open Messaging Benchmark w ruch. I co się okazało? Tutaj z takiego researchu jak sobie przejdziemy przez ten blog. Wpisy na tym blogu. To po pierwsze… Testy dla Redpandy nie znalazły się w repo Open Messaging Benchmark, tylko w forku. Taka ciekawostka. I druga sprawa, jakie są wnioski z tego? Jest tak, że można twierdzić, że w niektórych scenariuszach Redpanda jest szybsza. W niektórych Kafka na tym samym sprzęcie.

Szymon Warda: Czyli no wiadomo, optymalizujemy pod pewien use case, jeżeli coś optymalizujemy, to gdzieś będziemy gorsi. No, nie wyciągniemy szybkości, performance’u z kapelusza. No, to gdzieś będzie. Chyba, że napisałeś wszystko w Assemblerze, a w tym momencie koszt rozwoju tego będzie znowu poświęcony, no nie oszukujmy się.

Łukasz Kałużny: Nie no, ale tak, no nie oszukujmy się, że niekiedy jak popatrzymy jak w niektórych językach optymalizatoyr działają, to przecież…

Szymon Warda: Trzeba wybierać, które walki trzeba wygrywać. Nie ma sensu całego systemu pisać w assemblerze. Fragmenty mają sens, całość nie ma sensu, to się po prostu nie opłaca. Tego nigdy nie skończymy. Taka prawda.

Łukasz Kałużny: Tak, więc same… Rzucając, tutaj jest pokazane… Cały wpis. Redpanda nie jest tak piękna jak ją malują.

Szymon Warda: O dziwo marketing nie zawsze jest prawdziwy. Kto by pomyślał.

Łukasz Kałużny: Tak. I co ciekawe, Kafka, jest też dużo szczegółów, właśnie, jak że Kafka mogła np. dobić dyski do końca i wyczerpać, czyli obić ich limit. Redpanda nie potrafiła.

Szymon Warda: W ogóle patrząc dalej w ten wpis, bo faktycznie wcześniej go nie widziałem, to muszę powiedzieć jedno, dobry wpis nie tylko w kontekście Redpandy, ale w kontekście też testowania w ogóle systemów kolejkowych. Naprawdę, pod tym względem jest sensownie!

Łukasz Kałużny: Tak, jest. I w ogóle to jest takie podsumowanie, bo tego jest jeszcze 6 - takich wpisów. Czyli to, co widzisz, to jest summary, a jest tam po kolei 6 linków. Jak zejdziesz sobie na dół, które to w ogóle jeszcze rozkładają dalej.

Szymon Warda: No tak, właśnie tak scrolluję i tego jest dużo. Niezłe. Naprawdę niezłe. Dobrze. To teraz może ja czymś zarzucę. Trochę mówiliśmy jakiś czas temu o copilocie, ChatGPT itd. Staramy się wstrzymać, ale copilot też nas interesuje. Nie pamiętam czy na przykład wspomnieliśmy o tym w podcaście właśnie, że jak ważne stanie się za chwilę posiadanie modeli onpremowych tak naprawdę, które nie będą trenowane na danych, które nam wyciekły, bo jest szansa jak wkleimy ten kod, że on jednak w tym modelu zostaje, bo się uczy i potem się inne rzeczy dzieją. Więc fajny wpis z Practical Engineer… odnośnie porównania różnych modeli, ale teraz do copilota i tak przeglądając to trochę dokładniej to w ogóle… Przede wszystkim, od czego zaczniemy, na jakich wymiarach w ogóle porównuję i co ocenia w tabelce takiej ładnej spisanej, na czym był trenowany, na jakich danych, czy jest opcja self-hosted, bo nie wszystkie muszą mieć, czy można dostrajać do własnego kodu de facto. Tego, co mamy? Jaki jest poziom dojrzałości, czy jest opensource i jaki jest cennik? I od razu nadmienię - ta jego tabelka nie jest super dokładna.

Szymon Warda: Znalazłem przypadki, gdzie to się trochę rozjeżdżało, że jak projekt mówi, że jest w alfie a on daje, że jest production-ready. Więc tak właśnie różnie to bywa, prawda? Często widziałem Alfy odpalane jako produkcję i co wygląda fajnie? Faktycznie wygląda na to, że coraz więcej modeli jest, które można odpalać - one z reguły są płatne. Dwa modele, które wyglądają fajnie. Tabnine - bo jest opensource’owy. On właśnie jest pokazany jako production, ale na stronie repo i na githubie jest, że uwaga uwaga to jest alfa. Tabnine i Codium… Generalnie to te dwa ostatnie są już płatne, ale to dość ciekawie wygląda, szczególnie pod kątem potrzeby hostowania i używania tego kodu na onpremie, żeby te dane nie wyciekły, bo sorry, sporo było akcji właśnie, że coś wyciekło, bo ktoś wkleił kawałek kodu i potem się nagle gdzie indziej pojawia. Wydaje mi się, że zobaczymy takie modele częściej, chyba że dostawcy typu Microsoft i inni będą robili modele po prostu wydzielane. Po prostu jako self-hosted, to też jest jeden ze scenarisuzy.

Łukasz Kałużny: Tak, i patrząc się jeszcze dorzucę jedną taką ciekawostkę do tego, a mianowicie Starcodera, czyli jest to kawałek tutaj modelu, LLMa właśnie opensource’owego do generacji kodu.

Szymon Warda: Okej.

Łukasz Kałużny: I to też jest taka ciekawostka i posiada fine-tuning.

Szymon Warda: To jest ważne, bo właśnie te codebase’y będą się od siebie różniły. Czasem jak nie mamy tego codebase’u zbyt dobrego to może nie powinniśmy go finetunować, ale to tam bywa różnie. Ale wpis ogólnie warty chociażby do zapoznania się, jak szeroki to jest rynek, bo to nie są pojedyncze modele. Tego jest tam chyba około 12 - wymieniał z tych, które on znalazł. De facto. Więc krótki wpis, warto przynajmniej tą tabelkę zobaczyć.

Łukasz Kałużny: Dobra, to teraz druga rzecz. Zawsze patrzymy, że rekrutacje do Big Techu zawsze opierały się też o algorytmy i sprawdzanie - czy umiesz w algorytmy?

Szymon Warda: To sprawdza pewien sposób myślenia. Tak, dokładnie.

Łukasz Kałużny: I tutaj następny przykład to wpis na temat struktur danych. W jaki sposób booking.com może tak szybko wyszukiwać oferty po lokalizacji? Jest tutaj fajny opis całości - pokazujący, jak ten feature sobie działa i potem strukturę jaką nakładamy… Na mapie, czyli Quadtrees. W jaki sposób są budowane? To taki… Raczej obszerny, ale w miarę krótki, pokazujący samą logikę, nie kodowanie takiego czegoś. I to jest takie pokazanie, że są przypadki gdzie używasz takich algorytmów i innych zabawek. Jeżeli tworzysz czy Bloom Filters czy inne takie algorytmy, które trochę zmieniają Twoje myślenie na temat kodowania, rozwiązywania problemów.

Szymon Warda: Algorytmy subtelne warto znać. Ja mam zawsze z nimi taki problem, że czasami są wciskiwane do kodu.

Łukasz Kałużny: Na siłę.

Szymon Warda: Bo chce się je pokazać. Tak, to jest ryzyko a utrzymanie ich potem jest trudne. Tak prawdę powiedziawszy, jeżeli ktoś dobije już do słownika to z reguły to wystarcza. Ale zgadzam się z Tobą w pełni. Warto je znać, bo dla wąskich przypadków nagle będziemy mieli coś, co nam zadziała kilka, kilkadziesiąt, kilkaset razy lepiej niż cokolwiek innego, co musimy mieć z pudełka.

Łukasz Kałużny: Tak - I to nie jest znanie, że - kurde, potrafimy je wykodować z pamięci. Sorry, to podziwiam takich ludzi, którzy mają to wypalone w mózgu.

Szymon Warda: A ja nie podziwiam, bo to jest znowu kolejne ryzyko. Lepiej wziąć coś, co już kilka tysięcy ludzi przetestowało.

Łukasz Kałużny: Tak, wiesz, wypalone, ale chodzi o to, żeby wiedzieć, że są gdzieś takie a nie inne algorytmy i podejścia.

Szymon Warda: Tak, że pewna grupa problemów została już rozwiązana w pewien sposób i nie trzeba koła od nowa wymyślać. Dokładnie, zgadzam się, fajny w ogóle też wpis w kontekście nawet oprawy graficznej i wyjaśnienia - co, jak, gdzie wygląda. Nawet z samych rysunków można sobie przypomnieć, czym są właśnie Quadtrees.

Łukasz Kałużny: Dobra, co z Twojej strony jeszcze?

Szymon Warda: Z mojej strony jeszcze kilka rzeczy takich trochę short and sweet. Rzeczy, które mnie w sumie - mamy, jednak link, co mamy wspólny tak naprawdę. Ale z takich rzeczy short and sweet to są… CloudFlare wypuścił w swojej ofercie kolejki, zwykłe kolejki, na razie bez patcha i tak dalej. Na razie to jest wszystko w alfie, ale tak dla przypomnienia - CloudFlare ma usługę hostowania, ma bazę, ma bazę relacyjną, bazę obiektową.

Łukasz Kałużny: Obiektową.

Szymon Warda: Ma teraz kolejki, to staje się…

Łukasz Kałużny: To pełnoprawne on-the-edge, pełnoprawna platforma.

Szymon Warda: Tak, znaczy wydaje mi się, że dla… Ostatnio rozmawiałem z osobą, która ma po prostu swój własny serwis aplikacji generalnie.

Łukasz Kałużny: Mhm.

Szymon Warda: I tak realnie patrząc, to właśnie on wchodził w AWSa. On tego nie potrzebuje. On tego AWSa w ogóle nie potrzebuje, on spokojnie może wszystko oprzeć na CloudFlarze, całe swoje potrzeby, frontend i prosta baza danych.

Łukasz Kałużny: Znaczy wiesz co, jak robiłem stronę do streamingu konferencji Architektura i Kontenery to teraz uwierzytelnianie do materiałów i tam inne rzeczy jest oparte właśnie na CloudFlarze, bo było po prostu parę linijek, wysyłasz, zapominasz.

Szymon Warda: Tak - i to API w ogóle, które zrobili, jest naprawdę przyjemne. Jest super proste, jest totalnie bez żadnych wodotrysków, ale na zwykłe aplikacje wystarcza. Na Enterprise to w ogóle nie ta bajka, ale na takie wykorzystywanie codzienne w zupełności wystarcza.

Łukasz Kałużny: Na wszystkie side projecty i inne rzeczy świetnie się sprawdzi.

Szymon Warda: Tak, jestem ciekawy gdzie dalej się CloudFlare rozwinie, bo wydaje mi się, że rozwinie się taki właśnie co powiedziałeś. Taki cloud on the edge i to może bardzo szybko, fajnie działać.

Łukasz Kałużny: Tu fajne właśnie jest ten… Te ficzery Enterprisowe też mogą wbrew pozorom się bardzo szybko pojawić. Patrząc się na inne Offeringi ich.

Szymon Warda: Mają, mają dużo rzeczy w Enterprisowym kontekście networkingu w ogóle jako takiego.

Łukasz Kałużny: Tak, tylko że mówię, że w tym właśnie edge’owym Offeringu może się więcej pojawić.

Szymon Warda: Dobrze.

Łukasz Kałużny: I wspólny wpis… To zacznij, zacznij tą podśmiechujkę.

Szymon Warda: Znaczy nie wiem, czy to podśmiechujka. Znowu wpis od tego samego człowieka, od którego był wpis odnośnie copilota, mianowicie wpis nazywa się głośno… Mianowicie… Kto zapłacił 65 milionów dolarów za Datadoga? I wydaje mi się, że się zgodzimy z tym, że pierwszą cześć możemy spokojnie olać tak naprawdę, bo to jest ten cały… Dochodzenie, kto zapłacił.

Łukasz Kałużny: Tak. Powiedzmy, tak, kto to, przepraszam, bo to Coinbase…

Łukasz Kałużny: Coinbase.

Łukasz Kałużny: Coinbase. Za dużo trace’ował.

Szymon Warda: Tyle potrzebowali. Może. Nie mi oceniać czy za dużo, ale faktycznie. Ale druga część wpisu. Ja się… Zgadzamy się co do tego właśnie, że jest sensowna. Po pierwsze, bo na jaki stos się przenieśli? To jest jedna część, a druga… Jest ten magiczny algorytm. Kiedy warto pójść w vendora, a kiedy nie. Jeżeli koszty wewnętrznego utrzymania, ludzi itd. Są mniejsze niż vendor, to oczywiście bierzmy coś własnego, ale czasami my możemy płacić jak za zboże. Czasami vendor będzie miał sens po prostu, bo wewnętrznie byłoby drożej.

Łukasz Kałużny: Ale zazwyczaj - Im większa skala, tym vendor mniej się opłaca.

Szymon Warda: Ale na starcie ten vendor to właśnie zastrzyk wiedzy po prostu.

Łukasz Kałużny: Tak, dokładnie. Więc trzeba też to piękne pokazanie rozłożenia. Jedna rzecz, która dla mnie jest ciekawa z tego wpisu, bo tutaj jest też potem ucieczka na… Z powrotem do własnych rozwiązań. I tutaj, tak jak Grafana i Prometeusz w ogóle mnie nie zaskakują, o tak.

Szymon Warda: Też nie.

Łukasz Kałużny: Raczej jestem ciekaw, czy to jest Prometeusz, czy jakaś inna odmiana. Być może częściowo komercyjna i to jest ciekawe.

Szymon Warda: Ale pewnie zaskoczyły Cię logi.

Łukasz Kałużny: Tak, Ciebie też pewnie.

Szymon Warda: Też. Click House.

Łukasz Kałużny: Tak.

Szymon Warda: Bo… I biorąc pod uwagę, że wzięli Grafanę, która jest oczywistym wyborem. Swoją drogą nie ma tu rzeczy o tracingu, to mnie też zdziwiło, to ja akurat strzelałem, że to się pojawi tu Loki tak naprawdę.

Łukasz Kałużny: Wiesz co…

Szymon Warda: Albo Elastic.

Łukasz Kałużny: Właśnie Elastica albo Lokiego. Myślałem, że jak zacząłem Grafanę to pytaniem było - Elastic czy Loki, chociaż jakby był Elastic to pewnie byłyby w nim również metryki.

Szymon Warda: Bardzo możliwe, że tak. Tak, możliwe, że byłoby tak.

Łukasz Kałużny: Dobra, ale Clickhouse jako rozwiązanie jest genialne, jeżeli chodzi o wydajność, ale zaskoczyło mnie, że wpisuje się, bo nigdy od tej strony na to nie patrzyłem. Jako rozwiązanie do logów.

Szymon Warda: No właśnie przeglądam, to wygląda ciekawie. Faktycznie. Wpis jest warty - głównie ta końcówka. Faktycznie do przejrzenia sobie na spokojnie. Można powiedzieć, że od obrazków Grafany w dół to zaczyna być już wartościowy wpis. Jak dla mnie.

Łukasz Kałużny: Dobra. Ci, co nie wiedzą, Clickhousik ma rosyjską duszę, bo był na początku projektem Yandexa, ale został wyrzucony do open source’u.

Szymon Warda: I też Uber z niego korzysta. Tak swoją drogą.

Łukasz Kałużny: Tak. Dobra - i ode mnie ostatnia rzecz, którą miałem. Jest sobie prezentacja Avoid batch jobs, model the future. Jest ciekawa rzecz pokazana, żeby trochę zmienić myślenie, z takich czasami… z takich ficzerów korzystałem, o których jest tutaj mowa. Czyli żeby planować przyszłość, a nie batch joby. I autor prezentacji pokazuje dwa takie przypadki. Sposoby, jak można unikać. Pierwszy - pewnie Ci znany sposób na inteligentniejszych kolejkach, że możemy wysłać opóźnioną wiadomość.

Szymon Warda: Przydaje się czasami. Tak.

Łukasz Kałużny: Tak, że to jest jeden z ciekawych scenariuszy. Opóźnimy wiadomość. To jest pokazane, jako że zostańmy przy modelu całym eventowym asynchronicznym i nie miejmy crona tylko nadajmy wiadomość, która zostanie przetworzona za x czasu.

Szymon Warda: Tam wewnętrznie. Tam jest cron wewnętrznie, nie oszukujmy się.

Łukasz Kałużny: Tak, ale jest to… W sensie nie ma go w naszym systemie.

Szymon Warda: Dokładnie, to jest… Oddajemy odpowiedzialność do czegoś, co już wiemy, wykorzystujemy. Nie musimy czegoś nowego, nowego wprowadzać.

Łukasz Kałużny: Tak. Druga rzecz, która się tam pojawia, to tak naprawdę przy atrybutach naszych obiektów, innych rzeczy dawać po prostu i regułach biznesowych sprawdzać, czy one są spełniane czy nie, kiedy przychodzi faktyczne wykorzystanie, czyli jeżeli mamy coś, co jest określone jakoś time based, jeżeli wygaśnie jakiś czas, to żeby sobie to po prostu weryfikować, a nie tam cronem sprzątać. A z drugiej strony - jeżeli coś musi się zadziać akcją i być zaschedulowane, to jest to po prostu opóźniona wiadomość.

Szymon Warda: Tak, poleganie na czymś zewnętrznym jest fajne. Mi się przypomniało. Odnośnie opóźnienia, bo często opóźnienia załóżmy są generowane jako pessimistic concurrency. Taka mała rzecz, która się może komuś przydać. Mamy fajną obsługę pessimistic concurrency na blobach w Azurze. Swoją drogą. Tam i optimistic i pessimistic. I pessimistic jest robione tak, że nawet można by to wykorzystać jako mechanizm do pessimistic concurrency dla części aplikacyjnej. Małe, proste, może komuś się przydać.

Łukasz Kałużny: Dobra, wrócę do tego linka, bo jest to do tej ciekawostki. Dobra, to chyba wszystko.

Szymon Warda: Wszystko, kończymy. Trzymajcie się.

Łukasz Kałużny: To trzymaj się, na razie.