Bartosz Gałek Na pewno byłem zaskoczony mnogością technologii, którą mamy. Mamy kilkaset zespołów, kilka tysięcy aplikacji, które budują Allegro i ciężko jest wiedzieć, kto gdzie używa czego. Każdy teraz produkt SAS-owy ma. Używa nas ten i ten, ale ja nie chcę być tym co mówi logo firmy, my używamy. Nie, ja chcę powiedzieć my mamy punkty w Radarze, które na przykład są dwa razy takie same, ale w różnych kontekstach, mają różny stan.

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 klasycznie gdzieś tu na dole albo na Patoarchitekci.io. I słuchajcie, przypominamy o szkoleniach: moja Architektura 101, które zaczyna się 25 listopada. Cztery poranne spotkania w ciągu dwóch tygodni i będziecie na tym szkoleniu mogli uporządkować wiedzę na temat tego, jak projektować systemy, jak podchodzić do architektury nie tylko z perspektywy kodu, tylko z tych wszystkich rzeczy, które kopią po tyłku, jeżeli można tak to nazwać w tej pracy.

Szymon Warda: Dobra, potem 8 grudnia, mianowicie moja Observability na systemie Grafana i oczywiście Prometheus dorzucony, bo tak się już właściwie niemalże to wlicza, przejście i jak się z tych narzędzi korzysta z założeniem, że już wiecie mniej więcej czym jest observability, więc skupimy się głównie mocno technicznie, mocno narzędziowo jak użyć.

Łukasz Kałużny: Dobra i 16 grudnia, tak przed świętami, na zakończenie roku, powrót Kubernetes The Hard Way, chyba po dwóch latach publicznego otwartego szkolenia. Czyli uczymy się jak działa Kubernetes stawiając go od zera, bez żadnej pomocy, zakopując się w configi i patrząc się, gdzie która funkcjonalność jest tak naprawdę ukryta, a nie tylko, że z niej korzystamy.

Szymon Warda: Jasne. O czym dzisiaj Łukaszu?

Łukasz Kałużny: Dobra, były komentarze na YouTubie, była też nasza ciekawość, what the fuck Allegro Tech Radar jest w środku? Czym ta jest inicjatywa? No i dzisiaj rozbierzemy to sobie na czynniki pierwsze, bo okazało się, że Allegro może się tym pochwalić.

Szymon Warda: Dokładnie, więc zapraszamy.

Łukasz Kałużny: Cześć Bartku, witamy Cię w Pato i dzisiaj porozmawiamy, tak jak zapowiedzieliśmy, o Allegro Tech Radarze. Jakbyś mógł się przywitać i powiedzieć czym tak naprawdę zajmujesz się w Allegro.

Bartosz Gałek Cześć wszystkim. Dzięki za zaproszenie chłopaki. Ja jestem Bartosz Gałek, pracuję w Allegro jako Principal Engineer w obszarze Developer Experience. I tak żeby to jakoś skrócić, to mogę powiedzieć, że na co dzień dbam o to, żeby developerom i developerkom dobrze się pracowało i sprawnie i wydajnie.

Łukasz Kałużny: Okej, to jest też nietypowe chyba u nas, że jest już ktoś, kto w kraju, że w firmach pojawiają się ludzie od developer experience, o tak. Więc to jest taka nietypowa rzecz.

Bartosz Gałek Cały dział mamy.

Łukasz Kałużny: Wow! Słuchaj, to zacznijmy sobie słuchaj od pierwszego pytania. W ogóle skąd u Was pojawił się ten pomysł na Radar? Czy to była jakaś oddolna inicjatywa? Czy Wy to właśnie chcieliście wprowadzić? Czy był jakiś problem, który chcieliście rozwiązać?

Bartosz Gałek Okej, to tak naprawdę pomysł Tech Radaru to się rodził w naszych głowach albo w rozmowach od dłuższego czasu i wynikał głównie z tego, że Allegro ma dość dużą skalę, jeżeli chodzi o software development. Pomyślcie o tym w ten sposób, mamy kilkaset zespołów, kilka tysięcy aplikacji, które budują Allegro i ciężko jest wiedzieć, kto, gdzie używa czego i jak tych rzeczy używa i jak można tą wiedzę propagować. Wyobraźcie sobie aplikację, która obsługuje mapę automatów paczkowych Allegro. No i tam trzeba rozwiązać problem, jakieś wiecie wyliczenia dystansu na mapie i tak dalej. No i ten zespół się wyspecjalizował w używaniu jakieś bazy, która obsługuje geolokalizację. No ale w tej firmie, tak dość dużej, w zupełnie innym dziale, w całkowicie innym departamencie, w innym mieście nawet pojawia się podobny problem i ciężko jest jakby wyłapać, że ktoś inny czegoś używa. Więc kończy się tak, że albo ktoś mówi na jakimś Slacku dużym, że halo, halo, czy ktoś używa takiego czegoś, bo my mamy taki problem albo przeszukuje code base, albo może wypytuje tu i tam. Więc to jest pewne wyzwanie, żeby wiedzieć, co technologicznie w firmie mamy. To była jedna z takich potrzeb. Drugą potrzebą jeszcze było podejmowanie decyzji. No bo my w firmie mamy kulturę post mortemów. Kiedy jest jakaś awaria i coś się działo, to my zawsze staramy się wyjaśnić dokładnie przyczynę i wyciągnąć z tego lekcję. Ale chcielibyśmy też wyciągać lekcje z innych decyzji technicznych. Jeżeli coś się wybrało i np. to się nie sprawdziło, to fajnie by było zostawić po tym jakiś ślad, kontekst: słuchajcie to i to się nie sprawdziło w Allegro, bo to i to. Więc to była też dla nas taka ważna rzecz. Krótko mówiąc, żeby nie powtarzać swoich własnych błędów w przyszłości. No już pomijam, że jest to super okazja do podzielenia się tym, co Allegro robi. To już żeście chłopaki zauważyli na poprzednim odcinku. No jest to pewien element employer brandingowy, ale bardziej nam chodziło o to, żebyśmy my przed sobą i przed firmą mogli mówić o tym, co my mamy i czego używamy, jakie decyzje podejmujemy. Więc to były takie wewnętrzne potrzeby.

Łukasz Kałużny: Pociągnę w takim razie jedną rzecz w tym miejscu, jakbyś powiedział właśnie, bo wewnętrznie już teraz rozumiem trochę, to jest uporządkowanie tak naprawdę tego, co macie, ale po co tak naprawdę zdecydowaliście się to upublicznić? Bo to jest… Wiem, że Zalando na przykład tak też swój Radar upubliczniło. A ja chciałem się zapytać, jaka u Was była wewnętrzna motywacja tego upublicznienia?

Bartosz Gałek Na pewno pewną częścią tej decyzji była moja obecność w tym projekcie, ponieważ ja jestem absolutnym fanem open source i powiedziałem, że jak już to robimy, to czemu to robić prywatnie i chować to wewnątrz firmy, skoro możemy to zrobić publicznie na GitHubie. Więc to była też część tej decyzji. Ale oczywiście ostatecznie jakby my stoimy przed takim wyzwaniem, że Allegro mimo wszystko nadal jest firmą technologiczną i może z zewnątrz wygląda jak po prostu marketplace i duży e-commerce, ale jednak dużo energii i pracy i pasji przede wszystkim wkładamy w tą technologię. I jak na przykład ktoś jest ciekawy co Allegro robi i wejdzie sobie w oferty pracy, to często tam są dość skrótowe informacje. Można powiedzieć, że używamy, nie wiem, Javy i wszyscy o tym wiedzą, albo że używamy, nie wiem, Mongo, to też wszyscy wiedzą kto tam czyta ogłoszenia. Ale nie każdy może wiedzieć, że oprócz tego mamy pięć innych baz danych, które budują Allegro albo pięć różnych systemów AI, które używamy. I wydaje nam się po prostu, że to jest ciekawe dla nowych kandydatów do pracy, dla osób, które myślą o Allegro albo po prostu są ciekawi jak zbudować własny, taki duży produkt. Więc tak naprawdę nie ma tam żadnej dużej strategii pod spodem. Po prostu chcemy się tym podzielić i każdy, kto jest zainteresowany ma prawo wejść i zobaczyć. No i to w zasadzie to. Jakby to jest nasz ten plan, jeżeli chodzi o publiczną.

Szymon Warda: Czyli mamy Radar, ale ja bym się trochę cofnął tak procesowo generalnie. Jak to wyglądało, ile Wam to zajęło, kto pracował, jak to nazbieraliście, jakie były te poziomy decyzji? Tak od początku do końca, jakbyś mógł opowiedzieć.

Bartosz Gałek Tak, to projekt się wydawał na początku może prostszy niż się okazało, ale to chyba w większości projekty IT tak działają. No więc mieliśmy tak jakby wiecie kilka aspektów, bo tak, możemy to nazwać Radar, ale tak naprawdę fundamentem dla mnie personalnie było to, że musimy wiedzieć najpierw co my mamy. Więc myśmy zaczęli ten projekt bodaj rok temu, może trochę dłużej i pierwszą rzeczą, jaką trzeba było zrobić, to zrobić inwentaryzację. Inwentaryzację kilku rzeczy, inwentaryzację bibliotek czy narzędzi, których używamy, co okazało się nie takie trudne, bo istnieje takie coś jak software Bill of Materials. I jak myśmy sobie to zbudowali, całą infrastrukturę do tego, to już było całkiem łatwo zobaczyć cały obraz. Trzeba było też wyciągnąć z ludzi dobre praktyki, wyciągnąć z naszych wewnętrznych forów historie, które były zrobione przez nasze zespoły. Trzeba było też się trochę zabawić w taką rolę arbitra i jako jakieś tam gremium Tech Radarowe powiedzieć: dobra, słuchajcie, tak nie może być, że mamy trzy takie same rzeczy w tej firmie i trzeba zdecydować się na jedną. I jeżeli, nie wiem, drogą wiecie, zwykłych rozmów i negocjacji nie wybierzemy, to my po prostu wybierzemy jedną i już. Jeżeli są podobne i wszystkim nie zależy, no to weźmy jedną, takie najmniejsze zło. Więc ten proces był rozciągnięty dość mocno i stąd widzicie na publicznej wersji Radar v1, ponieważ Radar v1 dla nas, w naszej głowie, to jest zrzut tego stanu, jaki mamy teraz obecnie. W sensie to jest takie, wiecie, wszystko, co jest obecnie używane as is, my nie dyskutujemy z niektórymi decyzjami, to po prostu jest, obserwujemy to na naszym Radarze i to się dzieje. Takim przykładem może być na przykład Groovy, który jest używany w Allegro nie wiem, od odkąd ja pamiętam, czyli powiedzmy, że od 2013 roku, jako język do pisania testów. I dzisiaj być może mamy lepsze alternatywy i mógłbym powiedzieć, że nie jestem przekonany, czy to jest dobra decyzja na dzisiaj, natomiast ten stan jest obecny. Nie mogę zmigrować całej firmy dlatego, że ja powiem, że mi się Groovy nie podoba. To jest moja opinia, ale jakby wiecie o co chodzi, trzeba też ważyć zamiary. Nie mogę całą firmę teraz zmusić, żeby przez pół roku najbliższe migrowali testy. Więc na razie stan as is. I my to sobie obserwujemy i badamy, i próbujemy rozmawiać z naszymi ownerami, czy tam właścicielami danych tematów, jaka jest przyszłość tego czegoś. Tak mniej więcej mogę to skrócić. Chyba, że jeszcze mam coś się zgłębić?

Szymon Warda: Bo powiedziałeś takie dwa tematy właśnie, że właśnie nie migrujecie, ale z drugiej strony właśnie odbyliście taką rozmowę, że jednak trzeba wybrać jedną technologię, która służy do jednej czynności. Czy faktycznie ten Radar wpływa u Was powiedzmy na dalsze prace, migracje i tak dalej? Czy te akcje już się ruszyły, czy są zaplanowane, czy jak to wygląda?

Bartosz Gałek Wiesz co, to jest kilka aspektów znowu. Każdy z tych problemów jest taki wielopoziomowy. Z jednej strony Radar jest mimo wszystko dość nową rzeczą w Allegro i my powoli dopiero musimy zmienić w ludziach podejście. Czyli na przykład to jest tak, jednocześnie chcemy zachować autonomię zespołów. Ja jestem dumny z tej części Allegro. Jeżeli zespół twierdzi, że potrzebuje, nie wiem, Postgresa, pgvector, to niech sobie kliknie i niech się na tym nauczy. Tech Radar wprowadził tylko jedną zmianę, jak Ty to przećwiczysz i coś z tego nauczysz, to musisz dać nam feedback. Musimy się umówić, że możesz wziąć dowolną technologię, bylebyś na koniec napisał albo napisała nam parę informacji, czy warto w to iść? Czy to się sprawdziło? W jakim kontekście tego używacie? Więc to jest jakby jedna rzecz, która się dopiero tworzy i nad tym pracujemy. A z drugiej strony, sama ta inwentaryzacja pozwala naszym pracownikom powiedzieć: ok, poczekaj, nie odkrywamy koła na nowo, to już gdzieś tam w firmie jest, to po co mam brać coś nowego? I jednocześnie, to jakby jest jeszcze trzecia rzecz, obserwowanie w miarę live tego, co się dzieje w kodzie, czyli zależności, które w firmie są używane, pozwala nam obserwować nowe trendy. Czyli jeżeli na przykład, teraz przejdę do świata frontendowego, jeżeli powstaje nowy super framework albo jakaś biblioteka, dajmy na to Zod, to jest taki framework do walidacji. Jeżeli na przykład Zod nabiera trakcji w internecie, powiedzmy, że ludzie obserwują różne źródła, widzą, że to ma wartość, cieszą się z tego, jakby korzystają z tych dobrodziejstw, to powinno być to odwzorowane w naszym Radarze, bo ten projekt też powinien nabierać trakcji u nas. I my wtedy możemy zareagować i powiedzieć, czy to jest dobrze, czy to źle. Na przykład zapytać tych ludzi, czy Wam się dobrze korzysta albo czy powinniśmy to wspierać jakoś, czy platforma techniczna na przykład powinna dawać, nie wiem, jakieś konfiguracje wbudowane, żebyś nie musiał wszystkiego od nowa robić. I tak samo w drugą stronę, jak coś spada, na przykład coś się obniża, nie wiem już, nie chcę powiedzieć, że jest niemodne, bo to akurat głupi powód, ale jeżeli coś jest wymieniane na coś innego, bo ma jakieś lepsze benefity, to my też chcemy o tym wiedzieć, żeby zakomunikować w firmie: widzimy, że coś spada i widzę, że zastępujecie to czymś innym. Może faktycznie warto to proponować, reklamować, że to jest ta droga.

Szymon Warda: To super ważne pytanie w takim razie. Jak zbieraliście informacje, właśnie ten feedback od pracowników?

Bartosz Gałek Generalnie w momencie, kiedy my sobie zrobiliśmy ten stan, wiecie, bo ja jestem takim boomersem trochę, wiecie, otworzyliśmy sobie spreadsheet, wpisaliśmy wszystkie rzeczy, które tam mamy, tam było paręset pozycji, posortowaliśmy je sobie w jakiś tam sposób. I w naszej ekipie paru principali w projekcie właśnie Tech Radaru podzieliliśmy się ładnie, każdy dostał kawałeczek i musiał znaleźć właściciela. Czyli musieliśmy ustalić, kto w ogóle może być tą twarzą tej technologii, techniki czy tam biblioteki. I dajmy na to, jeżeli na przykład weźmiemy na tapetę, znowu przejdę na chwilę do frontendu, powiedzmy, że weźmiemy sobie React albo Preact, w którym Allegro jest budowane, to my musimy znaleźć kogoś, kto będzie twarzą i powie: wszelkie pytania to do mnie. Więc myśmy robili taką krucjatę i czasami było łatwo, dość prosto znaleźć na przykład zespół, który jest odpowiedzialny za, powiedzmy, decyzje frontendowe. A czasami było trudno, bo ciężko ustalić, czy ktoś w firmie jest ciągle, kto stwierdził, że będziemy robić Gita, a nie, nie wiem, Mercuriala czy coś tam innego. Więc czasem było trudniej, czasem było łatwiej, ale myśmy normalnie, fizycznie chodzili po tych ludziach, rozmawiali z nimi i prosili każdego o kilka zdań wyjaśnienia, albo jakiś background, jakąś historię, co za tym stało. I myśmy to wszystko zrzucali do markdownów tworząc nasz wewnętrzny Radar, który niestety nie jest publiczny. I tam wpisywaliśmy bardzo internalowe, wewnętrzne rzeczy, czyli decyzje albo historie związane z produktami czy technikami.

Szymon Warda: Czyli macie feedback, macie te informacje generalnie, macie taki słowno-muzyczny opis. W takim razie gdzie i kto decydował odnośnie właśnie tych poziomów, czyli trial, adopt, assess i hold?

Bartosz Gałek Właściciel. Czyli jeżeli był na przykład, do tego Reacta znowu wrócę, był React i Angular w firmie, nadal jest, to znaleźliśmy właściciela jednej i drugiej technologii i na przykład się okazywało, że właściciele części angularowej mówili: tak, my chcemy z tego zejść na przykład, bo widzimy, że reszta firmy już jest tam, a my jesteśmy trochę tu, pracujemy nad tym, mamy na to plany, wszystko jest spoko. Więc automatycznie my byliśmy w stanie porozmawiać z nimi: dobra, czy to jest ten moment, żeby powiedzieć hold? Czy to jest ten moment, żeby na razie powiedzieć adopt, bo to mamy i jak ktoś przyjdzie, to mamy to, jesteś specem od tej technologii?

Szymon Warda: Okej, czyli hold, te wszystkie poziomy, to są decyzje nie na poziomie organizacji, tylko na poziomie zespołów, które utrzymują te technologie.

Bartosz Gałek Które są twarzą tych technologii, tak.

Szymon Warda: Jasne. Okej, dobra.

Łukasz Kałużny: Dobra. To słuchaj. A teraz idąc troszeczkę w inny temat. Co było najtrudniejsze, jak tworzyliście Tech Radar? Czy były jakieś kontrowersje? Może wyzwanie organizacyjne?

Bartosz Gałek Wiesz co, powiedziałbym, że czas, bo Tech Radar to nie jest projekt, który przyniesie miliony dolarów, ani nie jest to coś, co biznesowo ma jakieś ogromne uzasadnienie, ale wynika z naszej potrzeby. Wiecie, wszyscy jesteśmy inżynierami i jakby z naszej takiej wewnętrznej potrzeby rozmowy o technologii, naszej wewnętrznej potrzeby świadomości, że robimy dobre decyzje, przemyślane, że opieramy się na obecnych danych i trendach. Więc to było mocno, na początku było mocno oddolne. Więc na początku trudność to było się zorganizować, serio. W sensie dogadać się, kto to będzie robił, kto może poświęcić na to trochę więcej czasu, kto może, ja wiem, że to zabrzmi bardzo smutno, ale naprawdę z pasji zostać po południu trochę i na przykład jeszcze po pracy podyskutować poza innymi tematami na tych rzeczach. I to było chyba najtrudniejsze. Bo potem to już zadziałało, jak w każdej chyba dużej korporacji, że jak już ruszył temat z kopyta i ludzie o tym rozmawiali, w firmach zaczął się pojawiać ten temat, myśmy coś zaczęli komunikować do firmy, że wiecie, piszemy maile szeroko, że my już nad tym pracujemy, tu jest pierwsza lista, możecie zobaczyć, do wglądu, na razie nad tym pracujemy, to ustalamy, to wtedy ta atrakcja się pojawiła w firmie. I później już było gładko, bo już później wszyscy wiedzieli, że jak przychodzi ktoś od nas i mówi: słuchaj, potrzebuję właściciela, nie wiem, MongoDB, to ktoś mówił: dobra, i tak się spodziewałem, że przyjdziecie do mnie. Super, chodź, pogadamy. Więc już było o wiele łatwiej. Ja uważam, że największy problem był tylko i wyłącznie wystartowanie.

Łukasz Kałużny: Dobra, a co Was najbardziej oprócz czasu, o którym powiedziałeś, wykluczmy go w tym momencie, co Was najbardziej zaskoczyło, albo Ciebie co personalnie zaskoczyło?

Bartosz Gałek Mnie personalnie zaskoczyło to, na pewno byłem zaskoczony mnogością technologii, którą mamy, bo akurat przez moje 12 lat kariery w Allegro to widziałem różne obszary i pracowałem z różnymi ludźmi i byłem świadomy, że mamy na przykład różne języki programowania, bo wiedziałem, że tutaj coś piszą w tym, tam coś piszą w tamtym. Ale dopiero kiedy zrzuciliśmy się, okazuje, że jest jeszcze na przykład w tej firmie jeden obszar, o którym w ogóle nie miałem pojęcia, że istnieje i on korzysta na przykład z jakiegoś totalnie dla mnie nieznanego stacku technologicznego. Dla mnie to był taki personalny szok, chociaż mogłem się domyślać. To jest duża firma, więc jakby domyślam się, że jak wrzucisz dowolne hasło, to znajdę kogoś, kto to coś w firmie robił, to to był taki szok. Inny szok to był dla mnie na przykład takie rozwarstwienie wersji aplikacji. Czyli na przykład może się okazywać, że w naszej firmie używamy jakiegoś narzędzia, jakiejś biblioteki albo czegoś w 15 wersjach. I wiecie jak to jest, ogólnie to pewnie nikogo nie boli, nic się takiego nie stało, że ktoś ma starszą wersję tam czegoś, a inny zespół ma nowszą. Problem następuje w integracjach, kiedy się okazuje, że ktoś robi bibliotekę i musi zrobić 7 IF-ów, bo tam są różne wersje pod spodem na classpath’ie. Więc…

Łukasz Kałużny: To akurat mnie zdziwiło przy waszej kulturze, bo jednak słyszałem różne historie, że jednak dość mocno staracie się aktualizować, update’ować, nie być w tyle.

Bartosz Gałek A widzisz, bo teraz to co Łukasz mówisz, to jest jakby wszystkie efekty uboczne, które ja przypisuję trochę inicjatywie Tech Radar. Trochę, wiadomo, że nie 100%. Ale przez to, że wiemy co mamy i rozmawiamy o tym, to możemy sobie zacząć to na przykład, nie chcę powiedzieć, że wymuszać, ale starać się robić inicjatywy, żeby to…

Szymon Warda: Nakłaniać.

Bartosz Gałek Wyrównywać, nakładać, dziękuję, nakłaniać. Słuchajcie, bo chodzi o to, że kiedy już mamy Tech Radar i ja widzę, że jest problem rozwarstwienia na przykład naszych wewnętrznych jakichś bibliotek albo jakichś technik czy narzędzi, to ja mogę pójść do drugiej ekipy. Akurat w tej ekipie też jestem, więc tak śmiesznie mogę iść sam do siebie, ale mogę zmienić kontekst i pójść do naszej ekipy, która zajmuje się w obszarze Developer Experience, u nas się to nazywa health check’i, czyli takie trochę standardy, to są jakby takie sztywniejsze miary, o których mówisz. I na przykład mogę w ramach zespołu od health check’ów wypracować jakąś strategię na przykład unifikacji tej wersji i na przykład znaleźć te osoby, znaleźć te zespoły i powiedzieć im: słuchajcie, ja nie mówię, że dzisiaj, nie mówię, że jutro, ale za rok, za pół roku ja chcę, żeby tych wersji było nie 53, tylko najwyżej 10. To jest, powiedzmy, dla Was to jest tyle i tyle pracy i będziemy Was za to ganiać. Będziemy Was pytać, będziemy pomagać, przyjdziemy, zrobimy pull requesta albo się dogadamy, ale musimy to zrobić, bo my nie chcemy mieć takiego rozwarstwienia. Więc tą przydługą historią chciałem powiedzieć, że do Tech Radaru można dopasować, jak takie puzzle, inne kawałki organizacji. Właśnie na przykład wymuszanie standardów albo wypracowywanie standardów. Albo może trzeba dopasować kwestie licencyjne, że na przykład teraz, jak już mamy w Tech Radarze pewne rzeczy, to możemy pewną rzecz powiedzieć, że jest on hold ze względu na licencje. Pytaliście mnie w mailach, jak żeśmy się umawiali na spotkanie, odnośnie na przykład Dockera i Podmana. I jakby można powiedzieć naiwnie, że oczywiście chodzi o pieniądze, wiadomo, ale chodzi też o część licencyjną. Bo na przykład to, co się dzieje z Docker Desktopem i te licencje, które wprowadzają, albo te modele opłat, które wymyślają, dla nas są po prostu nie fair albo nie okej. To nie jest kwestia tego, że Allegro nie stać na kupienie sobie licencji na Docker Desktopa, tylko my nie chcemy w tym uczestniczy. I dla nas migracja na Podmana to nie jest duży problem, bo to jest kompatybilny software. Ale jest wspierający.

Szymon Warda: Czerpiecie wartość z Tech Radaru, pokazujecie, że to nie jest tylko po to, żeby się pochwalić, żeby był sobie dokument w jakimś repo i tyle. Ok, ale w takim razie skoro mamy wartość, to teraz jak będzie wyglądał dalszy cykl życia Radaru? Bo mówisz, są dwie rzeczy, Wasz wewnętrzny, może mieć inną kadencję i ten publiczny, który jest publikowany. Czy to dalej będziecie wypuszczać? Jakie dalsze kroki? Co się w ogóle działo? I też czego się nauczyliście po wypuszczeniu tego, co zmienicie?

Bartosz Gałek Tak, jasne, to jest zasadne pytanie oczywiście. Więc ponieważ to jest świeża sprawa, dopiero pracujemy nad takim cyklem życia wpisów i na razie jest tak, że mamy taką dokumentację wewnętrznego Radaru, że kiedy pojawia się coś nowego, na przykład jest coś do assess’u, to my tam się umawiamy, że mamy trzy miesiące i za ileś trzeba wrócić i stwierdzić, co było czy co nie było. Jak coś wpada na hold, to musi być plan wyjścia i data. To nie jest tak, że robimy on hold, tylko dobra, to jest on hold, do 2026 tego nie będzie i taki kontrakt sobie ustalamy. Natomiast my chcemy, o ile dobrze wszystko zrozumiałem w mojej drużynie, to my byśmy chcieli się spotykać cyklicznie, raz na jakiś czas i żeby to było bardziej na zasadzie takiego, wiecie, otwartego spotkania dla wszystkich. Każdy, kto ma aktualizację swoich punktów albo może jakąś nową propozycję, powinien przyjść i z nami pogadać, opowiedzieć, my tu pomożemy umieścić na Tech Radarze. Ale jednocześnie chcemy wykorzystać ten cykl spotkań, żeby też wydawać kolejne wersje publicznego Tech Radaru. I wynika to z tego, że my byśmy chcieli się podzielić wszystkim 100%, ale nie zawsze będzie to miało sens publicznie. Bo jak ja napiszę piękną historię o tym, że w Casandrze model danych był trochę dla nas złożony i potem mieliśmy problemy z tam stronami, to to jest super lekcja dla innych firm i my chcemy to opublikować. Ale nie zawsze tak jest, bo czasami jest kontekst allegrowy, gdzie np. decyzja sprzed 10 lat wpłynęła na to, że ta technologia nam się nie sprawdza i nie możemy jednoznacznie powiedzieć to jest be albo to jest do kitu, tylko my musimy jakoś to ubrać w kontekst, a to jest kolejna praca do zrobienia. Więc mi się marzy, tak zupełnie między nami, marzy mi się to, że kolejne wersje Tech Radaru publicznego przestaną być tylko punktami na mapie, że my używamy tego, nie używamy tamtego. Ja bym chciał, żeby za każdą kropką na publicznym Tech Radarze stała historia, którą Allegro opublikuje, takie mini, nazwijcie to jak chcecie, mini posty, miniblog posty, to jest historia, która stoi za tym punktem, to się nie sprawdziło u nas. U Ciebie się może sprawdzi świetnie, ale u nas się nie sprawdziło z tego i z tego powodu.

Łukasz Kałużny: Dobra, słuchaj, to wejdźmy teraz o to, co było też wśród słuchaczy i pewnie widziałeś, nawet jedno z pytań jest bezpośrednio z komentarzy z YouTube’a nawet wzięte albo część dywagowaliśmy. I przejdźmy może do tych decyzji, które były, które się pojawiły, o których możesz, będziesz mógł powiedzieć. Do languages mamy jedno takie bardzo konkretne pytanie: czy ten poliglotyzm Was nie boli w tym momencie?

Bartosz Gałek Słuchajcie, czasem boli, czasem nie boli. Zależy co i jak. Ja uważam, że nie boli mnie personalnie i mojego działu. Co więcej, można do tego podejść na dwa sposoby. Bo można narzekać na wiele języków, bo tak, trzeb ustandaryzować jakieś biblioteki, trzeba wydawać w wersji X czegoś-tam, trzeba wspierać milion technologii. Ale można na to popatrzeć w drugą stronę. Jako Allegro chcemy być niezależni i chcemy wspierać jakby tą autonomię zespołów i nasza platforma techniczna Allegro powinna być agnostyczna i nie przeszkadza mi kompletnie w jakim języku jest uruchamiane. I dam Wam przykład. Powiedzmy, że z 10 lat temu powstała nasza taka główna platforma techniczna oparta na Javie i mieliśmy tam, wiecie, nasz starter Spring Boot’owy, który wszystko robił. I on wprowadzał pewne defaulty i pewne założenia, które były ukrywane przed developerami, developerkami. Na przykład coś było Wiecie tam ustalone, że jest taka konfiguracja, która ma tam, nie wiem, nazwę aplikacji powiedzmy, a i ta nazwa aplikacji powiedzmy jest zwracana w jakimś tam endpoint, który opowiada, co to za aplikacja robi. Prosta rzecz. I ponieważ jeżeli byśmy mieli zunifikowany stack i byłaby to zawsze Java, to ja bym z tym nie miał problemu. Co najwyżej jak coś zmieniamy, to powiem wszystkim: musicie podbić wersję dependa, bo przyjedzie, zrobi wam pull request i spoko. Ale nie mamy jednego stacku, mamy różne stacki. I teraz ja nie chcę, żeby wszyscy implementowali taką wiecie python starter, java starter, coś-tam starter. Ja bym wolał, żeby to było tak jakby uniwersalne, żeby wszystkim działało. Więc pewnie kto się domyśla, to już pewnie wie, zamiast konfiguracji w bibliotece, która ma jakąś tam zapisaną rzecz, zamiast tego w Kubernetesie, na którym uruchamia się dowolna aplikacja, jest dostępna zmienna nvarmentowa, którą po prostu autor aplikacji może odczytać. I my tylko sprawdzamy, czy na tym endpoincie, który ma być, który jest kontraktem naszych usług, jest ta wartość. Jeżeli jest, to wszystko gra i mi nie przeszkadza, czy to będzie napisane w Golangu, czy to będzie w Pythonie. Każdy developer, developerka może bez problemu po tą wartość sięgnąć i ją po prostu wyświetlić. My staramy się tak robić, żeby ten progres był ok, żeby to było częścią firmy.

Szymon Warda: Teraz chyba największa sekcja właściwie Radaru, czyli database and infrastructure. Dużo tam tego jest. Macie i Cassandrę, i MySQL’a i Oracle, które jest na holdzie i co mnie wcale nie zdziwiło, jak zobaczyłem to, tylko szukałem gdzie jest Postgres, bo to w ogóle tutaj automatycznie. Czy to jest element właśnie kosztowy, ujednolicenia stosu? Z czego właśnie wynika, że z tak wielu baz wstrzymujecie się, migrujecie? Jednak zakładam się, że do tego uniwersalnego Postgresa to już swoją drogą była mowa.

Bartosz Gałek Tak, tak. Wiesz co, to znowu wynika z tego, że Allegro ma długą historię. I tak, z Casandrą byliśmy pożenieni od 2016 roku, o ile dobrze pamiętam, albo 2017 i nam się to nie sprawdziło i mam nadzieję, że podzielimy się kiedyś tą historią w pełni. Nam się to nie sprawdziło, więc dlatego Casandra jest na holdzie od paru lat u nas. Jeżeli chodzi na przykład o Oracle’a, to po prostu jest nam niepotrzebny. Jakby nie używamy i nie widzimy powodu, żeby nie wiem, trzeba było na niego przejść. Jeżeli chodzi o na przykład MySQL, to my chcemy wystandaryzować sobie właśnie bazy danych relacyjne, bo do tej pory wspieraliśmy różne, były MySQL i Postgres i parę jeszcze innych po drodze, ale chcielibyśmy, żeby wszyscy w miarę możliwości przeszli na jedno, co nam pomaga potem na przykład część baz zmigrować sobie do clouda na przykład, bo jest to standardowa baza.

Szymon Warda: Jasne, się zgadzam, że Postgres został wybrany jako ten, który sprawdził się najlepiej i faktycznie też swoją drogą hype wokół niego jest największy obecnie.

Bartosz Gałek To jest też dynamika wydawania wersji, wsparcie.

Łukasz Kałużny: Dobra, to słuchaj, następne pytanie, które mnie mocno interesuje, to jest co tam do diabła robi Istio? Ponieważ mieliście dużo prezentacji, jak zbudowaliście własnego service mesha na bazie Envoy’a i przerobiliście pewien open source do zarządzania control plane’m? Wiem, że też chyba mieliście Consula, jak dobrze pamiętam, do Service Discovery. I tak jak sam powiedziałeś zresztą sporo w platformie się chwaliliście tymi elementami wokół Service Discovery i Netflix style podejścia. Więc co tu robi Istio słuchaj?

Bartosz Gałek Jasne, to oczywiście nadal jesteśmy dumni z naszego service mesha, którego mamy opartego właśnie o Envoy’a czy Consul’a. Ostatecznie chcielibyśmy w takim większym rozrachunku ustandaryzować się do Istio, bo to jest standardowy service mesh w Kubernetesie, o ile mi wiadomo. Więc my byśmy chcieli przejść…

Łukasz Kałużny: Tak, wygrał.

Bartosz Gałek O, właśnie. I o ile widzę wartość w takim customowym rozwiązaniu, bo możemy tam różne rzeczy magiczne robić, tak wolałbym być ustandaryzowany w Istio, tak żeby na przykład mógł mieć klaster Kubernetesa chociażby w GCP-ie i żeby on działał tak samo. Więc krótko mówiąc, po prostu nadszedł czas, że standard dogonił nasze customizacje i możemy spokojnie na to przejść. Znaczy spokojnie, to może nie powiem, że spokojnie, ale staramy się na to przejść. Żeby to było jasne Łukasz, nie kasuje tego wszystkiego, o którym mówisz, te prezentacje, o których mówisz, one były na tamte lata odkrywcze i to był nasz sposób, żeby sobie poradzić z service mesh’em.

Łukasz Kałużny: Raczej nie, wiesz, ja sobie zdaję sprawę, bo bardziej to jest pytanie wiesz, znając waszą historię trochę i ilość włożonej pracy w zbudowanie tego, bo to był niemały projekt, stąd aż tak wiesz, oprócz Casandry to było drugie duże zaskoczenie, o tak.

Bartosz Gałek Tak i Casandra również była jednym dużym, jednym z największych polskich klastrów. Tak że to można powiedzieć, że prawdopodobnie Envoy jest największy klastry.

Łukasz Kałużny: Byliście w tym, jeżeli chodzi o Casandrę, to wiem, że byliście top 3, znając parę innych tych, dwóch pozostałych użytkowników. Byliście w top 3, bo potem to już można byłoby się kłócić o detale.

Bartosz Gałek Tak jest, tak jest.

Szymon Warda: Teraz (…), to jest bardziej moja działka, bo widzę tak, widzę Grafanę i widzę Kibanę, widzę Prometheus’za i widzę Victoria Metrics. Ten stos monitorujący widzę tak, jakbyście mieli takie 2 trochę rozdzielne obozy. Właśnie jak to wygląda w ogóle? I obydwa te obozy są jako adopt?

Bartosz Gałek Tak, bo to jest stan obecny, to mamy i dlatego jest adopt. Natomiast to byś musiał mi trochę wytłumaczyć, dlaczego to jest osobny stack. Bo pomyślmy o tym. Elasticsearch jest odwróconym indeksem, więc jakby pozwala nam dobrze wyszukiwać. To, że tam są logi dla Kibany, to jest jakby rzecz wtórna, bo Kibana to jest narzędzie do przeglądania logów. Grafana Tempo służy nam do trzymania trace’sów z Open Telemetry, na które wchodzimy. Prometheus jest tylko, znaczy tylko, nie że tylko, jest świetnym scraperem, a Victoria Metrics backendem. Więc tak naprawdę w Tech Radarze mogliśmy, tak ja mówisz, umieścić ELK Stack i powiedzieć: mamy to. Ale chcieliśmy jakby wydzielić, ponieważ ja czuję, że możemy wymieniać te klocki. Dzisiaj Grafana, może za jakiś czas coś innego, może wciągniemy to do naszej konsoli albo albo inaczej. Więc dla mnie to są klocki, które mają konkretny cel, dlatego są osobne.

Łukasz Kałużny: Z ciekawości jedna rzecz, bo tam padło na początku odcinka i to było miejsce, w którym się chciałem o to zapytać. Czy wykorzystujecie Elastica również aplikacyjnie u Was?

Bartosz Gałek Tak, zdecydowanie.

Łukasz Kałużny: Ok. Nie, bo rzeczy akurat nienawidzę po prostu osobiście Elastica do logów w wielu miejscach, gdzie dla mnie to, tak jak powiedziałeś, na przykład ten case geolokalizacji i przeszukiwania po lokalizacji, który przepięknie działa w Elasticu, stąd było w tym. A gdzieś po prostu nie widziałem SOLR-a ani Lucyny tutaj u Was na tych listach, co mnie też zaciekawiło w ogóle.

Bartosz Gałek Też mamy i pewnie się pojawi. Z jakiegoś powodu nie weszło w pierwszej turze.

Szymon Warda: Lucyna raczej z całą biblioteką można powiedzieć. Wyjaśnijmy może o co chodzi bardziej, bo właśnie macie (…) w Grafenowym, macie Tempo, macie Grafanę i tak dalej, to jest taki pierwszy punkt wejścia. I teraz się właśnie, zakładam, że mówimy w kontekście logów, bo to jest bardzo ważne właśnie. W takim razie załóżmy czemu na przykład nie Loki do logów? Właśnie dla mnie to jest taka ciekawa decyzja czemu to się nie pojawiło i czemu właśnie poszliście bardziej w Elastic’a? O to bardziej mi chodziło. A odnośnie Prometheus’za, jak już wyjaśniłeś, że on jest tylko do scrape’owania, a trzymać się Victoria, to co się już wyjaśniło. Ale na przykład mi się rodzi pytanie, załóżmy czemu akurat nie Open Telemetry Collector? I czemu właśnie scrape’ujecie a nie wysyłacie? Coraz więcej zaczyna się rodzić tego, jak to wygląda i skąd te decyzje się wzięły.

Bartosz Gałek Super. I właśnie dlatego, że zadajesz te pytania, jesteś ciekawy, ja to szanuję. I właśnie dlatego bym chciał, żeby w kolejnych częściach Tech Radarów przy punkcie Prometheus czy Victoria Metrics pojawiła się nasza historia z Diamondem czy tam Graphitem, to już można sobie wybrać, bo my kiedyś przez długi czas właśnie wypychaliśmy metryki. A przeszliśmy na scraping i migrację na Prometheus’za, zakończyliśmy wydaje mi się, że dwa lata temu. Więc to też jest…

Szymon Warda: Ciekawe, bo (…) być odwrotnie. To zaczyna być naprawdę ciekawie.

Bartosz Gałek Właśnie widzisz i właśnie o to chodzi. Właśnie Szymon o to chodzi, że to jest ten moment, kiedy my byśmy się chcieli podzielić doświadczeniem, a nie tylko hasłem: my używamy tego. Bo dobrze wiecie, ja mogę mieć super stronkę, tak jak wiecie, każdy teraz produkt SAS-owy ma: używa nas ten i ten. Ale ja nie chcę być tym, co mówi logo firmy: my używamy. Nie, ja chcę powiedzieć: używamy tego, bo… Albo przestaliśmy tego używać, bo nie wiem, przy naszej skali się nie sprawdza.

Łukasz Kałużny: Mieści się w kontekście.

Szymon Warda: Albo co więcej, używamy do… Powiedzenie w sensie do czego, jaki jest kontekst tego wykorzystania, nie tylko, że po prostu korzystamy. To jest też super ważne.

Bartosz Gałek Chciałem tylko odnieść się do tego kontekstu “do”. Bo słuchajcie, my mamy punkty w Radarze, które na przykład są dwa razy takie same, ale w różnych kontekstach mają różny stan. Przykładowo…

Łukasz Kałużny: O, to ciekawe.

Bartosz Gałek Właśnie, bo to jest super aspekt. Jeżeli na przykład mówimy sobie, że Allegro używa Javy i że my jesteśmy za tym, żeby, nie wiem, najnowsze JDK było normą. Tak na przykład w mobile była decyzja na przykład na Kotlina i Java. To jest wszystko przykład, ale ta sama rzecz, ten sam wpis z perspektywy mobile, czy developmentu aplikacji mobilnej może być on hold, a w przypadku backendowych aplikacji może być on tam assess czy tam wiecie, adopt. Więc to jest też bardzo fajna rzecz, żeby napisać kiedy używamy i gdzie.

Łukasz Kałużny: Okej, to Bartku, teraz takie jeszcze pytanie, które mnie zaskoczyło, bo myślałem, że Redis u was jest standardem jako cache.

Szymon Warda: Tak, a on jest w trialu.

Bartosz Gałek Tak, to prawda i szczerze Wam powiem, że ja nie znam szczegółów dokładnie tej historii. Natomiast wiem, że Reddit się pojawiał i znikał, pojawiał i znikał. I teraz dopiero jakby wracamy do tego, żeby Redis był naprawdę takim first class citizen’em w wielu miejscach. Natomiast, żeby było jasne, to nie jest tak, że Allegro sobie nie używał czegoś innego. My do cache używamy na co dzień couchbase’a i jesteśmy z niego zadowoleni. A więc też to nie jest tak, że wiecie, że nasi developerzy chodzili po biurze smutni i mówili: ojeju, nie mam Redisa, przecież ja chcę mieć ten Redis, tylko były inne rozwiązania wewnętrzne z naszymi abstrakcjami, utrzymywane przez zespoły od strony technicznej. Więc były jako manage services. Nic lepiej się nie da mieć, niż powiedzieć na Slacku, gdzie mogę wyklikać sobie nowy cache. A tutaj kliknij sobie. I klikali sobie ludzie i mieli. Więc z tym oczywiście nic nie wygra. Natomiast my chcemy, żeby Redis się pojawił, dlatego jest w trailu i zastanawiamy się, jak to zrobić dobrze, bo mamy do wyboru, czy to Manage Services w cloud, czy właśnie własnej infrastruktury. I też żeby nie było, ten Redis gdzieś tam jest. To nie jest tak, że go w ogóle nie ma, ale chcielibyśmy, żeby był takim, wiecie, potencjalną…

Łukasz Kałużny: Szerzej i platformowo.

Bartosz Gałek Tak jest i wspierany platformą. Dokładnie tak.

Szymon Warda: To odnośnie teraz historii. Pytanie w sumie chyba już ostatnie. Co przeważyło, że jest Copilot jako wyżej, a Cursor jest jednak, że odrzucacie, stwierdzacie, że go wygaszacie, na holdzie?

Bartosz Gałek Tak i zastanawiałem się nad tym, co Wam powiedzieć, jak to pytanie padło. Wydaje mi się, że największym takim aspektem był po prostu poziom integracji z ekosystemem Allegro. Bo jednak Cursor jest zewnętrzną firmą, z którą by trzeba było podpisać jakieś NDA, więc takie wyzwanie korporacyjne. My w firmie, jakby Allegro stoi, odkąd pamiętam, od 2013 roku stoi na JetBrainsie i na IntelliJ-u, więc też by była to zmiana pewna kulturowa, żeby nagle się przesiąść na Cursora. Ja wiem, że VSCO też jest ok, nie mam nic przeciwko i część u nas developerów też korzysta, ale to jest kolejna zmiana, rozumiecie. Centralne sterowanie licencjami w IntelliJ, licence serwery i tak dalej, to wszystko jest bardzo dobrze ogarnięte. I po prostu nie wiem, na przykład tak samo jak mamy nie Cursora, mamy Copilota, a nie na przykład Codexa i wynika to z tego samego, Allegro jest na GitHubie, automatycznie mamy kontrakty z Microsoftem, o wiele łatwiej było negocjować warunki, bo nie startujemy od tak, wiecie, firma z Polski.

Łukasz Kałużny: Bartek, czyli uczciwie to co powiedzieliśmy, co wynika też z Twoich dokładnie słów wtedy w odcinku, potrzeby korporacyjne wygrały w tym miejscu i łatwość dostarczenia tego do ludzi.

Bartosz Gałek Tak, ale też, żeby było jasne, ja na przykład nie widzę aż takiej strasznej różnicy. Ja jestem w ogóle fanboyem nowych technologii, więc oczywiście Cursora zainstalowałem w dniu, kiedy go ogłosili na Hacker Newsach i pobawiłem się tym. I dzisiaj większość IDEE dogoniło. Ja naprawdę, ja nie rozumiem na przykład hejtu… Znaczy rozumiem hejt, jak ludzie narzekają, że plugin Copilota w IntelliJ kiepsko działa. No tak, no też tak uważam. Ale na przykład już Junie, który jest od JetBrainsów, działa bardzo fajnie w IntelliJ i na przykład wydaje mi się, że to jest okej. Więc myślę, że te technologie i tak dogonią i ostatecznie się zunifikuje.

Łukasz Kałużny: Inaczej, ja teraz patrzę i tak skończymy znowu ze wszystkim w konsoli. Ja patrzę na Codex’a i tego Copilota, teraz, który wyszedł, agenta w postaci CLI-a. Słuchaj Bartku, to chyba będziemy kończyć, bo przemaglowaliśmy Cię. Bardzo fajne wsadzenie w kontekst. Wiesz co? I nie mogę się doczekać, bo pewnie jak być może zaprosimy Was na review jak wydacie wersję z osadzeniem w kontekstach, bo to jest taka rzecz, która nas interesuje, o tak. Bo wrzucenie tych naszych pytań potem w konteksty, które posadzicie, może być bardzo ciekawą rozmową. I trzymam kciuki, żeby udało się to opublikować.

Bartosz Gałek Nie, to możemy w ogóle tutaj przy słuchaczach wszystkich taki deal zawrzeć, że jak wyjdzie następna wersja i będziemy mogli porozmawiać o kontekstach, to możemy nawet, jak dla mnie to możemy i pół godziny pogadać o jednej historii na przykład, która będzie, bo mamy parę świetnych historii.

Szymon Warda: Ja bardzo chętnie, bo to będzie realne użycie na dość fajnej skali. Więc tak, trzymamy za słowo.

Bartosz Gałek Jesteśmy umówieni. Dobrze.

Łukasz Kałużny: To dzięki. Trzymajcie się.

Szymon Warda: Dzięki wszystkim. Hej.

Bartosz Gałek Dziękuję.