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

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka oczywiście Patoarchitekci.io lub gdzieś na dole w opisie, wygooglacie, wybingacie, ogarniacie, wierzymy w Was.

Łukasz Kałużny: Dobra.

Szymon Warda: To co Łukasz, ogłoszenie?

Łukasz Kałużny: Dwa ogłoszenia. Pierwsze, przypominamy o szkoleniach, a drugie ciekawsze, ponieważ do Protopii zatrudniamy, więc jeżeli ktoś z Was chciałby z nami pracować, to szukamy DevOps engineera, tudzież cloud engineera. Czyli osoba, która nas wesprze w różnych elementach naszej pracy, o której też możecie usłyszeć w Pato. I słuchajcie, szukamy osoby, która po pierwsze, dość dobrze zna Azura i to jedno z takich wymagań, z rzeczy, które najczęściej robimy. Czyli wie czym jest np. managed identity i jak działa private endpoint i tego typu elementy. Druga rzecz, rozumie podstawy Kubernetesa i Dockera, czyli rozróżnia czym jest Pod, czym jest kontener, jak działa serwis, jak działa Ingress. Nie musisz znać hard waya na pamięć, ale te wysokie podstawy, jak napisać dobry manifest, jak najbardziej, znać któreś z narzędzi do CI/CD, bo wychodzimy z założenia, że jak znasz jedno, to znasz większość i ewentualnie ponarzekasz. Do tego jakiś język skryptowy, żebyś umiał, umiała automatyzować. I co ważne i chyba najważniejsze samodzielne myślenie i kreatywność.

Szymon Warda: Tak, to zdecydowanie się przyda. Tak, zachęcamy ogólnie, nie jesteśmy tacy straszni, jakby się mogło wydawać. Tyle chyba właściwie no.

Łukasz Kałużny: Tak.

Szymon Warda: To co, lecimy?

Łukasz Kałużny: Tak.

Szymon Warda: Lecisz Łukasz pierwszy z wynikami.

Łukasz Kałużny: Dobra, pierwsze, post na LinkedInie, który mi się napatoczył. Jeden z dwóch, drugi niestety twórca skasował, więc go już nie będę dorzucał. Ale tutaj jest fajny, który jest prawdziwy, z którym też nie do końca się zgadzam. Ale to jest Junior versus Mid Developer, czyli gdzie leży różnica? I teraz dobrą rzecz, która mi się podoba i też, bo niektóre zakrawają trochę o seniora, w zależności jak tam popatrzymy sobie na nazwę, ale są fajne w pytaniach. Junior pyta: co mam zrobić, jak, kiedy, dlaczego, czy mogę iść do toalety? Mid zapyta, odpowie: zrobię feature X do piątku. Pytania będą jak coś wybuchnie. I to jest dobre podsumowanie w ogóle, takie wstępne. Kiedy junior przestaje być juniorem? Tak realnie.

Szymon Warda: Ja się zgodzę z tym, że to się kończy na samodzielności.

Łukasz Kałużny: Tak, bo świadomość kontekstu, potem jest tam rozwiązywanie problemów, zamieniłbym: kopiuję z ChatGPT. Ale Junior: kopiuje rozwiązanie ze Stack Overflow i modli się. Mid: rozumie rozwiązanie ze Stack Overflow i adaptuje je, ale też się modli. I to jest tak i to jest ok, ale świadomość kontekstu: mój kod działa na moim komputerze versus ten kod wpłynie na performance całego systemu. Uważajmy.

Szymon Warda: To tak już bardziej seniorem według mnie.

Łukasz Kałużny: Zajeżdża raczej mid versus senior w tym miejscu. I to jest fajne, że jak popatrzymy w tym wpisie, co jest ważne, właśnie skupia się na myśleniu i samodzielności, a nie jak fajnie podkreślił, że junior musi koniecznie gromadzić technologię jak Pokemony.

Szymon Warda: Tak, to fajnie widać jest na CV-kach juniorów, że nagle jeżeli widzieli na oczy jakiś framework, bibliotekę, to jest w: używałem. Widać, że wraz z wiekiem ta liczba “używałem” maleje tak powoli, powoli, człowiek stwierdza, że może niekoniecznie.

Łukasz Kałużny: Wiesz co, i z drugim postem, który jest już skasowany, była tam długa dyskusja pod nim ciekawa, ale polegała na tym, że można tam zastąpić człowieka z 15-letnią wiedzą o optymalizacji C++ gościem po studiach i bootcampie Rusta, tak można go było postawić. Ja się zastanawiam… Inaczej, dwie rzeczy, które tak popatrzę, co Ty robiłeś przez 15 lat, że można Cię zastąpić tak szybko? To jest taka Wiesz, to jest pierwsze pytanie. To znaczy, że masz prawdopodobnie 15 razy 5 albo 15 razy 2 doświadczenia. Wiadomo, że masz 15 razy rok doświadczenia, bo powtarzasz przy systemie tą samą robotę od 15 lat. Wiesz, to było…

Szymon Warda: To jest ciężkie w kontekście C i C++, bo to jednak są języki, które wymagają trochę wiedzy. Tam nie idą ludzie z przypadku. Chyba, że faktycznie czasami widuję właśnie takich ludzi 15 razy 1 piszących rzeczy pod urządzenia.

Łukasz Kałużny: Trafiłeś dobrze, bo tamten post akurat był, który jest skasowany, był też o tym. Ale jedna rzecz, która jest ciekawa, która dała mi do przemyślenia. Bo mówi się, że każdy, to jest ciekawe, że dobry senior będzie w stanie programować w każdym języku, w teorii, że szybko się w niego wgryzie. I teraz jedna rzecz, która w sumie nigdy na to… Inaczej, z tą frazą ogólnie się zgadzam, że jesteś w stanie poznać język w ciągu miesiąca, takie rzeczy. Ale będzie tak jak dowcip, w szczególności dowcip na temat ludzi, którzy wyszli z Javy, czyli programiści Java przestańcie pisać w GoJavą albo przestańcie pisać Javą w Scali.

Szymon Warda: To właśnie miało znaczyć, oni będą w każdym języku się poruszali, ale będą próbowali go nagiąć do tego, co już umieją. A trochę więcej czasu zajmuje, żeby zrozumieć, jakie są te główne paradygmaty, jak się poruszać w konkretnym języku. To zajmie dużo czasu.

Łukasz Kałużny: Całą filozofię, tak, i to zajmuje i tego nie zastąpisz. To jest…

Szymon Warda: To są dupogodziny.

Łukasz Kałużny: Dupogodziny. Jeżeli, inaczej, jeżeli wchodzisz w istniejący codebase, no to masz skąd zrobić copy paste i na czym się wzorować, to tak, ale to nie będzie 100% takiej seniorskiej samodzielności, nie będzie jeszcze tego flow.

Szymon Warda: Genialne, bo miałem podobne przemyślenie odnośnie linku, który ja znalazłem. Jest wpis Pagoda: A Web Development Starter Kit for Go Programmers. No nie, Pagoda. To nie framework a jednak framework starter kit webowy dla Go. I tam jest kilka takich pięknych zdań: but why not make Pagoda a Go framework? Because the Go community doesn’t seem interested in that, he said. No to teraz, czyli tłumacząc wprost na polski to, że społeczność Go nie jest zainteresowana, żeby robić framework webowy. Można powiedzieć, że w takim razie można stwierdzić, że IQ developerów Go jest wyższe niż developerów Rusta, chociażby oni mają framework webowy. Ale jednak jak się poczytałem i poszukałem to okazuje się, że jednak mają push upa i mają Go Buffalo, więc nie jest aż tak dobrze.

Łukasz Kałużny: Co to za framework jest właśnie, jak już przechodzimy tak płynnie do Twojego wpisu.

Szymon Warda: Tak, a potem dalej jest jeszcze jedno ciekawe zdanie: Most of us don’t want to have to switch languages, especially if you’re not using JavaScript in the backend. I to jest coś, co, znowu powiem, w moim pokoleniu, że tak powiem, bycie wielo, używanie wielu języków było naturalne i było czymś dobrym, czym się ludzie chwalili. A teraz ludzie podchodzą do tego, że nauczę się jednego języka i będę go używał wszędzie, gdzie tylko można. Z całym szacunkiem, każdy język ma swoje plusy i minusy i używanie go w różnych kontekstach, znowu Context is The King, będzie miało swoje benefity albo swoje minusy. Wpychanie Go do Weba nie ma sensu.

Łukasz Kałużny: Ale to samo możemy teraz powiedzieć o Hotwire… Bożesz, jak się nazywa ten frontend C Sharpowy, kurde, ten nowy? Jak się nazywa ten nowy frontend? Ale mam dziury… Blazor.

Szymon Warda: Blazor, tak.

Łukasz Kałużny: Tak, Blazor. To one wszystkie odpowiadają na to pytanie.

Szymon Warda: Tak, jak wcisnąć język tam, gdzie on nie powinien być. I pamiętam jak dużo było prelekcji o tym i nawet było dużo badań o tym, że znanie wielu języków poprawia jakość kodowania, poprawia sposób myślenia, otwiera nowe możliwości i tak dalej. I wydaje mi się, że to wszystko prowadzi do tego, o czym w ogóle mówimy często na szkoleniach i mówimy często w innych sytuacjach, że mamy coraz mniej developerów, a coraz więcej frame’owych operatorów. Ludzi, którzy znają jedną rzecz i znają ją świetnie i nie znają niczego innego.

Łukasz Kałużny: Wiesz co? I w tym poście, który właśnie omawialiśmy na początku, też jest wspomniane na tym właśnie Bla. Tylko z drugiej strony jest multum ogłoszeń, które promują framework developerów ze względu na to, że mamy Stack, lecimy nim i tyle.

Szymon Warda: Tak, bardzo dużo i też coraz więcej języków ma ten jeden prawidłowy framework.

Łukasz Kałużny: Tak, czyli mamy ten, znajdziemy zaraz Spring developerów, Nest developerów, zamiast Reacta to Nest developer.

Szymon Warda: Tak i takich developerów jak najbardziej możemy spokojnie w wielu sytuacjach zastąpić właśnie Chatem, jakimkolwiek tak naprawdę. Dobra, dajesz, co to tam wyszukałeś?

Łukasz Kałużny: Właśnie, ale jeszcze o tej Pagodzie jakbyś wspomniał, bo tak zaczęliśmy, miałeś linka. Czyli co? Ogólnie pomysł na Starter Kit do developerki?

Szymon Warda: Do developerki webowej tak naprawdę, który finalnie używa Ajaxa, CSS, HTMLX’a i tak dalej. I on umożliwia stworzenie strony i takie właśnie, żeby z Go kontrolować nie tyle to, co się dzieje na frontendzie, ale żeby ładnie to rozłożyć. Coś takie SP bym powiedział bardziej, no nie? Także no okej, ale po co?

Łukasz Kałużny: Czy przypomina to Django, czy mi się tak zdaje, jak tak patrzę? Bo HTMX…

Szymon Warda: Trochę tak. Tak trochę wygląda. No ale bardziej sama idea mnie przeraża.

Łukasz Kałużny: Dobra. Następna rzecz, Oskar, niestety znowu odcinek, chyba AI-a żadnego dzisiaj nie mamy, tak sądzę.

Szymon Warda: Ale ja mam Kubernetesy.

Łukasz Kałużny: Ale ja też mam Kubernetesy, dlatego Oskar 0, ten 1 na 2 spełnione, żeby short był właściwy i był zamknięty w naszej bajce. A mówię o Oskarze, bo jest jego wpis. Wspominaliśmy ostatnio o tej migracji do TypeScripta.

Szymon Warda: Kompilatora.

Łukasz Kałużny: Kompilatora. Oskar się ten odpalił jak zobaczył 10 razy więcej i zrobił mięsisty wpis tłumaczący o co w ogóle w tym chodzi i co, jak, dlaczego. I całość, która się sprowadza, bardzo dobrze pokazane, że operacje, które robi kompilator są tak zwanymi CPU bound, czyli są intensywne dla CPU, a nie wymagają wait’owania tak jak robi to zwykle Node i JavaScript dla pamięci.

Szymon Warda: Jako osoba, która pisała różne translatory i tak dalej, mogę powiedzieć to są operacje bardzo ograniczone przez CPU, tam trochę RAM-u przy okazji, bo tam buduje się różne drzewa do optymalizacji.

Łukasz Kałużny: Tak, więc tutaj w tym. W całości…

Szymon Warda: Wpis jest całkiem niezły, czytałem go, faktycznie całkiem niezły. Po prostu jest dobry.

Łukasz Kałużny: Jest dobry. Tak, zawsze zazdroszczę, że…

Szymon Warda: Fajnie pokazuje to, że bawienie się numerkami razy 10, razy 50, no spokojnie, i tak większość aplikacji jest ograniczane, przez co? Przez strzały do bazy danych. Taka prawda.

Łukasz Kałużny: Tak, więc podsumowanie dobrze tłumaczy co, jak, dlaczego, więc polecamy się tutaj zagłębić w to i zobaczyć. Ja nie wiem, czy z naszego podcastu, z odcinka wyniknęło, że faktycznie mówimy, że to kompilator, a nie jeszcze runtime, więc będzie to ciekawe. Dobra. Widzę, że masz Node’a następnego, więc idealnie trafiłeś.

Szymon Warda: W ogóle mamy jakieś takie przycięcia niezłe. To ja mam coś innego, mianowicie, że Node zaczyna wspierać TypeScript. Nawet może ktoś powiedzieć: no ale jak to? Jak to w ogóle? Przecież TypeScript był nadzbiorem do JavaScriptu. Tak, ale teraz natywnie. Ruch dość ciekawy, bo w tym momencie Node zaczyna nadganiać inne runtime’y jak Deno i Bun. Moje osobiste zdanie i tu może komuś się narażę, jest takie, że ja bardzo lubiłem takiego gołego JavaScripta, który był dużo bardziej funkcyjny, miał masę problemów, ale jakoś do TypeScriptu i takiego wciskania kodowania takiego typowo object oriented ja się jakoś nie przekonuję. Ale rynek całkowicie.

Łukasz Kałużny: Raczej tak, jest… Inaczej, na czystym Node’zie zrobisz teraz bardzo dużo. W sensie jest kompletny, jest kompletny, czy weźmiesz Express JS-a. No właśnie i to jest takie… Inaczej, ja do TypeScripta również się nie przekonałem w żaden sposób.

Szymon Warda: TypeScript jest świetny do dużych projektów. Jak potrzebujesz zrobić coś mniejszego, to dużo tego jest dookoła. JavaScript był taki, że potrzebowałeś zrobić jedną funkcję, używałeś jednej funkcji i koniec, starczało z reguły. No ale to może dlatego jesteśmy dinozaurami.

Łukasz Kałużny: Nie za dużo prostoty byś chciał, słuchaj? Za dużo, za dużo.

Szymon Warda: Tak.

Łukasz Kałużny: Dobra, to idziemy do Kubernetesa. A nie, jest kompletny, widzę, że masz GenAI-a, więc przepraszam. Dobra, a idziemy sobie teraz do ciekawego wpisu Mercado Libre. Platforma e-commerce’owa z Ameryki Łacińskiej, czyli Południowej. Pierwsza liczba użytkowników, zanim dojdziemy do tego, co Szymon sobie zaznaczył, to ponad 170 milionów aktywnych użytkowników, tam wizytorów. Więc jest co. I oni zbudowali sobie IDP. I tutaj dostajemy około 1,8 mikroserwisu na developera, czyli 30 tysięcy mikroserwisów, szesnaście tysięcy deweloperów. Pozaokrąglane, te liczby są zawsze fascynujące, o tak, od tej strony.

Szymon Warda: Znaczy fajnie widać po prostu, w którym okresie ten system zaczął powstawać. Była moda na mikroserwisy, to mają mikroserwisy.

Łukasz Kałużny: Tak. Przy czym ja patrząc się jak przeczytamy ten artykuł plus jeszcze drugi link o tym, oni pokazują tutaj swoją ewolucję swojego IDP, które się nazywa, zbudowali sobie sami IDP zanim to było modne, czyli to jest i nazywa się Fury. I z drugiej strony pokazali abstrakcje, które zrobili i cały przepływ, który przelatuje z ich historii bycia multicloud i w ogóle, pod tym względem wykorzystania cloud providera, zrobienia abstrakcji. I potem gdzie dojeżdżają do czegoś, co u siebie nazywają słuchaj serverless modules. Więc patrząc się na to, w jaki sposób jest to opisane i te liczby 30 tysięcy, to ja sobie tłumaczę tym, że prawdopodobnie po prostu jest to podejście bardzo pico serwisowe, pico, nano serwisowe, które jeżeli adaptowali w jakiś sposób na swojej platformie jakikolwiek wzorzec serverlessowy, no to ta liczba już Cię nie dziwi w żaden sposób.

Szymon Warda: Nie dziwi choć pali się dość dużo lampek w mojej głowie, to jest dużo serwisów, ustalmy. Narzut komunikacyjny będzie duży. Żeby nie było, takie ustawienia mają swój sens. One mają sens w wielkich, kolosalnych organizacjach typu Uber, który musiał szybko rosnąć. O tym też kiedyś mówiliśmy. Odcinek o mikroserwisach chyba dalej jest ciągle żywy, gdzie omawialiśmy. Pierwszy, drugi, trzeci?

Łukasz Kałużny: Patologie mikroserwisów.

Szymon Warda: Tak, jakoś tak, jeden z pierwszych odcinków. On jest dalej aktualny, może kiedyś nagramy ponowienie go i aktualizację. Pico, fajnie to brzmi na papierze, fajnie brzmiał na prezentacjach, finalnie trochę tego nie widzę. Zbyt dużo problemów to generuje.

Łukasz Kałużny: Więc można przejść, skrót tego jak zbudowali tą platformę, z czego się składa, więc polecam sobie zobaczyć jak można to zrobić i nie róbcie tego w domu.

Szymon Warda: Oj zdecydowanie nie. Dobra, a teraz idziemy, inne duże organizacje. Adidas. W ogóle jakoś tak przyuważyłem, że Adidas się od jakiegoś czasu, mniej więcej roku, pół roku zaczął bardzo mocno chwalić co tam w ogóle porabiają technicznie. Ewidentnie ktoś ma parcie na szkło, tudzież na papier, tudzież na cośkolwiek innego. To bardzo widać, co nie jest wcale takie złe. Z tego artykułu jest trochę, jest ciekawy. Parę rzeczy jest interesujących. Między innymi co mnie zaciekawiło najbardziej, to jest to, że mierzą downtime, czyli to ile aplikacja nie działa, przez Lost Revenue Per Second. I teraz i to jest naprawdę, w ich kontekście to jest bardzo sensowne, bo powiedzmy 5 minut w okresie wyprzedaży to nie to samo co 5 minut między pierwszą a drugą w nocy. Więc ten czas nie jest tak samo ważny, pomysł jest niezły. Ale wpis jest całkiem niezły odnośnie tego, jak budowali platformy jako produkty, o czym też wielokrotnie mówiliśmy, że to musi być, żeby się udało. Trochę liczb. W 2020 roku mieli 300 mikroserwisów. Użyli Wardley Mappingu i stworzyli katalog z tego dla biznesu i dla Ciebie z możliwymi reużywalnymi serwisami. I przy tej liczbie i ich skali, ich użyciu, bo oni tam mieli od groma integracji, to ma bardzo duży sens.

Łukasz Kałużny: Ty, zobacz jaka ten, 30, 300.

Szymon Warda: Tak.

Łukasz Kałużny: Przepraszam, 30 tysięcy, 300, żeby była skala.

Szymon Warda: No, ładne przejście. Tak, dalej. Fajne rzeczy też zrobili w kontekście wdrożenia Copilota, 2024 i tam parę statystyk. 79% używa Copilota do tworzenia nowego kodu. No okej, jakiś tam boilerplate. 62% używa do zmiany istniejącego kodu. Ok. Ale najbardziej interesuje mnie ostatnie, 61% uznaje go jako przydatny do dokumentowania kodu. I to jest 100% racji.

Łukasz Kałużny: Dziwię się, że tak mało.

Szymon Warda: Też mnie to zdziwiło, szczególnie, że 80% używa do tworzenia nowego kodu, więc naprawdę mnie to zdziwiło. Ale jedna rzecz mnie martwi, tutaj cytat z artykułu: However, as Adidas’s time on keyboard had shifted from 47% in 2018 to 65% of the time in 2024. I teraz o co chodzi? Adidas zaczął mierzyć, taką metrykę wprowadzili developerów, czas przy klawiaturze. I właśnie, tak, z jednej strony to jest fajnie, bo to jest fajna metryka, która może zmniejszać ilość dupnych spotkań, każde takie ma jakiś przeszkód i tak dalej. Ale to jest metryka, którą tak jest łatwo nagiąć i oszukać i może prowadzić do absurdalnych rzeczy typu nie róbmy spotkań, nie rozmawiajmy, albo miejmy to spotkanie zdalnie, mimo że będzie dużo wolniej trwało i tak dalej, zamiast po prostu pójść na kawę na chwilę, no nie? Tak że to jest bardzo, bardzo, bardzo martwiące.

Łukasz Kałużny: Czekaj, muszę jedną rzecz, teraz mnie aż zaintrygowałeś i doszukać w tym artykule jednej rzeczy konkretnej.

Szymon Warda: Ty szukaj, a ja powiem inny bardzo fajny cytat, tym razem: The closer you are to the IRP or the core processes of the company, the harder it gets. O co chodzi tam? Chodzi o to, że oni stwierdzili, że, i bardzo słusznie, stwierdzili to, że pewne rzeczy są bardziej skomplikowane. Szybko notując ten cytat, to jest taki kawałek, że: it’s complex because we decided it to be more complex. Chodzi o to, że nie można Dorą ani żadnymi innymi metrykami mierzyć bez kontekstu. Pewne rzeczy będą trudne. Integracja z prostymi systemami typu nawet TikTok i tak dalej, to będzie łatwe. Systemy księgowe, takie grube, sprzedażowe, one będą ciężkie, skomplikowane, bo te procesy są ciężkie i skomplikowane. Tak że fajnie zrobili to właśnie rozdzielenie, które procesy i jak na nie patrzą, no nie. Nie wszystko musi być tak bardzo zwinne i tak bardzo Agile’owe, tak bardzo mikroserwisowe i tak dalej. Bo mamy różne domeny. Różne domeny wymagają różnych rozwiązań po prostu. To jest akurat dobre.

Szymon Warda: Czy udało się znaleźć?

Łukasz Kałużny: Tak. Ja szukałem słowa McKinsey.

Szymon Warda: Oczywiście, że tam pewnie jest.

Łukasz Kałużny: Jest, ale próbują się od niego odciąć.

Szymon Warda: To tyle dobrego. Tak, zobaczyłem, bo był ten artykuł z…

Łukasz Kałużny: Tak, bo oni zobacz, że w tym wprowadza sobie czas w IDE i czas przy klawiaturze, że trochę to rozróżniają względem tego. Bo McKinsey skupiał się na tym sieć w IDE i nie wychodź z niego, a tu trochę to rozróżniają. Ale dobra.

Szymon Warda: To nie jest zła metryka. Bardzo łatwo jest ją nagiąć, że zacznie się optymalizować. To metryka, której nie potrzeba maksymalizować. [Niesłyszalne 00:21:22] w tym obszarze.

Łukasz Kałużny: Wiesz co, to jest bardziej statystyczna.

Szymon Warda: Tak.

Łukasz Kałużny: Bardziej trzeba byłoby patrzeć na dupogodziny… Inaczej, szukanie dupogodzin, cyklicznych spotkań i innych rzeczy. Problem jest ilość prawdopodobnie spotkań i złych wymagań, a nie dupogodziny przy klawiaturze.

Szymon Warda: Tudzież czekania, wysyłania maili i czekania na innych ludzi. Tak, to są kwestie procesowe. Dobra, co tam jeszcze innego masz?

Łukasz Kałużny: Dobra, to polecieliśmy. Teraz dowcip pod tytułem, jak ten, dasz mi w tym, tytuł jest ten: All my DevOps pipelines from GitLab commit to ArgoCD got beaten by FTP.

Szymon Warda: By FTP?

Łukasz Kałużny: Tak. No dobra.

Szymon Warda: Ja już to otwieram normalnie.

Łukasz Kałużny: Dobra. Historia polega na tym, to są żale gorzkie, gorzkie żale. I o co tutaj chodziło? Jest tam fuzja pracowników, powiedzmy firma A i B, w sumie dziewięciu pracowników. I jest tam opis tego, jak ktoś na siłę próbował wprowadzić nowoczesność w domu i zagrodzie, czyli PHP-owcom wrzucić Dockera, zrobić pełen pipeline CI/CD, gdzie oni od zawsze wrzucają PHP-a FTP-em. Każdy ma jakiegoś swojego lokalnego LAMP-a, czy jak to się tam zwie, czy inny Stack do odpalania tego PHP-a lokalnie, mają prawdopodobnie jakiś swój własny framework PHP-owy.

Szymon Warda: Na pewno.

Łukasz Kałużny: I klientom nie przeszkadza, że ktoś wchodzi i wrzuca patche w postaci plików. Jak przyzwyczaisz kogoś z tego na przejście na CI/CD z Argo, Kubernetesem innymi rzeczami.

Szymon Warda: Znaczy ja powiem tak. Nie no sorry, ale wjeżdżanie na koniu, tudzież na hulajnodze, właściwie bardziej tak to wygląda. Systemem, który normalnie sobie działał i nagle wjeżdżamy z Kubernetesem i innymi sprawami, jeszcze Argo, no nie tak się zaczyna. To jest ewolucja zawsze. Widziałem trochę systemów, często te obrazy Dockerowe to jest taki po prostu sam PHP i nic więcej, a i tak ma podmontowany wolumen, który pliki PHP-owe skanuje i używa. Powiem tak, trochę się nie dziwię, ktoś przestrzelił zdecydowanie. To trzeba jednak iść etapami. A kiedy się klient przekona? Jak mu coś wybuchnie w twarz i nie będzie mógł tego odzyskać.

Łukasz Kałużny: Inaczej, i tak wybuchało.

Szymon Warda: Oczywiście, będzie to będzie wybuchało.

Łukasz Kałużny: Klienci marudzili, ale płacili, więc po co? Inaczej, to jest Szymon, Ty przeżywasz podobną katorgę w jednym miejscu.

Szymon Warda: Tak, tak, tak, pozdrawiamy. Zdecydowanie tak.

Łukasz Kałużny: Więc akurat znane połączenie, ale jest dość fajnie podpisane tam pod koniec, że są decyzje, że nikt tego nie rusza i że po prostu zespół nie jest gotowy, nie chce, a management nie będzie walił, bo nie widzi z tego benefitu.

Szymon Warda: I tak powinno być. Jeżeli ktoś nie widzi zysku z tej inwestycji, no to po prostu nie róbmy tego. Nie ma co być dogmatyczny. Dobrze, to lecę z kolejnym artykułem: The Missing piece in platform Engineering: Recognizing Producers, czyli brakujący element w engineeringu platformowym, rozpoznanie producentów. O co tu chodzi? Całkiem, całkiem, całkiem, całkiem ok artykuł poza tym, że jest długi i jest przegadany. Ale tam jest takich parę fajnych opowiastek, więc jak ktoś lubi takie właśnie bardziej, bardziej opowiadanie zamiast pisanie konkretów, to dobrze. Jest tam parę fajnych punktów. To jest to, że faktycznie często budując platformę myślimy bardziej o konsumentach tej platformy, czyli myślimy bardziej o developerach, a często zapomina się o ludziach, którzy dostarczali wcześniej te rzeczy, typu właśnie DBA, SRE, bezpiecznicy i tak dalej. Czyli ludzie, którzy stali, żeby te elementy platformy dobrze działały. To jest faktycznie fajna uwaga. Jedna rzecz, którą chciałem podkreślić, mówiłem o tym już chyba kilka razy, ale mimo wszystko, tam to jest ładnie opisane. Nie do końca opisane jest ładnie jakie zyski z tego mieli. Ale posiadanie person w platform engineeringu czy określenie tego, dla kogo to tworzymy, to naprawdę dużo robi i jest bardzo fajne i korzystajcie. Jak potrzebujecie inspiracji, to ten artykuł faktycznie fajnie to opisuje jak to w ogóle wyglądało. Trochę nie za bardzo opisuje jakie mieli z tego benefity, ale opowieść jest całkiem ciekawa, więc jak ktoś chce poscrollować to, to to całkiem nieźle wygląda. I też są przykłady tych osób, więc całkiem nieźle. Zapamiętajcie - producenci i żeby mieć personę. Fajna sztuczka od [niesłyszalne 00:26:17].

Łukasz Kałużny: Inaczej, product management w platformie bez tego nie wypali, bez product managementu, platforma.

Szymon Warda: Bez person i bez, tak, bez [niesłyszalne 00:26:27].

Łukasz Kałużny: Bez takiego product ownershipu, że zarządzamy tym jak produktem. Wiesz co? Jedna rzecz, która mi się rzuciła, bo pewnie Kinga Gaździńska, o której rozmawialiśmy z Dorą, bo robią w Pracuj.pl, rozmawialiśmy o Dorze, jakieś tam w zeszłym roku. Ona teraz występowała na konferencji z prezentacją Before it was cool, six year of our Internal Developer Portal. I trochę, jeżeli do tej pory ktoś nie zbudował tego i nagle odkrywa, że powinniśmy mieć, to prawdopodobnie już tego nie potrzebuje.

Szymon Warda: Znaczy ja się nie zgodzę. Wdrożenie części rzeczy ma sens, tylko moduły do IaC-a chmurowego potrzebne są.

Łukasz Kałużny: Czy wiesz, czyli mówimy coś, czym możesz też nazwać standaryzację.

Szymon Warda: Tak, oczywiście. Platforma to jest po prostu zbudowanie w klocki standaryzacji. To absolutnie nie jest wdrożenie backstage. To nie o to chodzi Łukasz, tu się zgadzamy.

Łukasz Kałużny: I nie Kubernetesa.

Szymon Warda: Tak, nie Kubernetesa po prostu. Ale nie, ale są elementy typu właśnie modularyzacja, są elementy typu standaryzacja procesów CI/CD, takich rzeczy, w których naprawdę jest wartość. Pytanie, w którym momencie można to nazwać platformą? To jest rozmyte. Jak będziesz szczęśliwy z tego powodu, tyle właściwie, no nie? Dobrze. I ponownie backstage nie jest wymagany, naprawdę.

Łukasz Kałużny: Dobra, słuchaj, to lecimy. Kafka 4.0 się zbliża. I są dwie rzeczy, raczej jest tam dużo ciekawych rzeczy, jak tam popatrzymy. Ale słuchaj, są dwie istotne rzeczy, które mnie przy tym ten. Pierwsza, craft, czyli implementacja Rafta wbudowanego w Kafkę będzie domyślną zamiast ZooKeepera.

Szymon Warda: Bo była opcjonalna.

Łukasz Kałużny: Tak, więc ZooKeeper wylatuje dla utrzymywania quorum. To jest świetna informacja. Druga, queues for Kafka. Będzie, słuchaj, założenie jest takie, że, bo ja tego w ogóle przegapiłem to w tym, że takie coś w ogóle będzie, jest taki keep, wreszcie pojawiają się takie w tym coś podobnego do zwykłego Pub/Suba bez kombinacji.

Szymon Warda: Tak, w ogóle właśnie robią coś, porównują się do Amazon Simple Queue Services.

Łukasz Kałużny: Tak, że w sensie tak. Czyli tam zwykłe, ten, zwykły, zwykły… Raczej FIFO to nie będzie, bo… Inaczej, to nie jest FIFO, ale mimo, że tam gdzieś tak opisują. First In, First Out, ale zwykły, prosty, nie przypięty do ilości konsumerów kolejeczka.

Szymon Warda: Przydaje się, jak najbardziej. Dziwię się, że nie ma w ogłoszeniach natywnego wsparcia dla event sourcingu. No ale, trzeba trochę złośliwości.

Łukasz Kałużny: Dobra, koniec złośliwości. Ale tak, jak zobaczymy, że już nie będzie topicowa tylko będziesz miał kolejeczkę, kurde, może będę mniej narzekał… Inaczej, bo większość osób używa Kafki, a potrzebuje zwykłej kolejeczki, zwykłej, prostej kolejki z Rabbita np., takiej chamsko prostej.

Szymon Warda: To ja coś innego. Teraz wchodzimy trochę technicznie. Dwa artykuły, które mi wyskoczyły, Clickhouse i Uber. Obydwa odnośnie migracji do czego? Do ARM-a. Oczywiście on się tam chwali, bo artykuł by AWS, że tak powiem, 20% zysku wydajności, super, fajnie. Uber chwali się jak przypisali całą platformę do budowania obrazów dockerowych, bo oczywiście mieli własną platformę do budowy obrazów dockerowych. Z ciekawostek, mieli 400 tysięcy buildów dockerowych na tydzień. To jest dużo, ustalmy. Łącznie mieli 5 tysięcy procesów budowania kontenerów. To takie rzeczy się dzieją, jak się popłynie z mikroserwisami. Ale to jest najlepsza opcja. Gdzie się przemigrowali? Do GCP i do Oracle Cloud Infrastructure, co jest ok.

Łukasz Kałużny: Tanio? Inaczej, czy jest dobrze? Czy jest tanio i dobrze? Jest tanio.

Szymon Warda: Ale tak już myśląc właściwie to powiedzmy sobie, bo o ARM-ach mówi się już od dawna. To nie jest pierwszy, to 10 lat temu też się mówiło o ARM-ach. Ale tak naprawdę to obecnie wydaje mi się, że będzie coraz więcej projektów migracji do ARM-a. Mając Dockera to już nie jest większy problem tak naprawdę. Czy to nie będzie tak naprawdę za chwilę standard, czy nam nie będzie wisiało to [niesłyszalne 00:31:21]?

Łukasz Kałużny: To będzie się leciało. Ja jestem ciekaw, doczytałbym czy oni w tym ClickHousie odpalają bazę po prostu, czy jakąś część inną tego? Bo to jest ciekawe.

Szymon Warda: No właśnie tak nie do końca. Wydaje mi się, znaczy ja strzelam, że chodzi tutaj o części aplikacyjne. Bazy, to jest inna bajka. Gotowy system aplikacyjny, to trwa.

Łukasz Kałużny: Wiesz o co mi chodzi tutaj? Że to nie jest takie, aż potem sobie sprawdzę już offline. Czekaj, dobra, to tutaj nie będę teraz wchodził, nie chcę już teraz tak na szybko tego czytać, bo my nie oglądamy swoich linków przed nagraniem, żeby zobaczyć, ale jestem ciekaw czy tam faktycznie sprawdzają dokładnie bazę danych.

Szymon Warda: Strzelałbym tylko w serwisy aplikacyjne, bo to jest najłatwiej. Baza, tam jest zbyt dużo optymalizacji. To jeszcze zajmie duży moment czasu, aż to będzie migrowane. Ale te klastry Kubernetesowe, to się będzie działo i będzie się działo coraz łatwiej. To będzie taki projekt jak każdy inny. Dobra, ja mam jeszcze jedno ogłoszenie parafialne tak naprawdę. Masz coś?

Łukasz Kałużny: Nie, ja już nie, więc dawaj.

Szymon Warda: Znowu, mojego małego ogródka, który się czasami pojawia, kolejne wykorzystanie API Neo4j. Google Spanner odpala API Graphowe. Co jest, będzie się integrować z Langchainem i właśnie z Neo4j. Składnia jeszcze jest GraphQL-owa do odpytywania się. Po prostu…

Łukasz Kałużny: Co oznacza: będzie się integrował z Neo4j?

Szymon Warda: Będzie, nie, będzie wykorzystywał kwerendy Neo4j’owe, to jest.

Łukasz Kałużny: W ten sposób, ok.

Szymon Warda: Które są fajne. To jest najfajniejszy język, jeżeli chodzi o zapytania graphowe. Mnie cieszy to, że bazy graphowe stają się takim powoli czymś, co można używać, bo one są fenomenalne w bardzo wąskim zbiorze zastosowań, a były strasznym wrzodem na tyłku, żeby je postawić i hostować samemu. Tak że w ogóle odnośnie tego, to zapraszamy oczywiście do posłuchania odcinka, gdzie jeden z Polaków jest odpowiedzialny za optymalizację Neo4j’a, z Jarkiem Pałką. Tak, mieliśmy z nim wywiad, tak że zapraszamy, bardzo fajny wywiad. Jak ktoś potrzebuje, to jest kolejna możliwość ładnego serwisu chmurowego, który ma super API graphowe. Tyle.

Łukasz Kałużny: No dobra, to mamy w tym, mamy to wszystko zrobione. Więc co? Trzymajcie się i do zobaczenia. Hej!

Szymon Warda: Pa pa!