Ł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 na Patoarchitekci.io lub gdzieś na dole w opisie. Wierzymy, że ogarniecie to.

Łukasz Kałużny: No dobra, to co? Na początek kącik reklamowy, czyli zapraszamy na szkolenia. Szymon będzie prowadził ostatnie w tym roku Observability.

Szymon Warda: Dokładnie tak, będzie co nieco właśnie o Observability. Pobawimy się Loki. Pobawimy się Grafaną, pobawimy się Prometheusem, znaczy mówię pobawimy się generalnie, będzie to bardzo mocno deep dive w Loki i Prometheusa, bo właściwie w trakcie jednego szkolenia zobaczymy, co tam właściwie siedzi, troche o architekturze. Popatrzymy, co tam się w Pixi dzieje w ogóle, czyli jak tam eBPF-y zarządzają i pobawimy się też tym, jak w ogóle złożyć Application Insights. Bo czemu Application Insights? Bo jest po prostu fajny i wydajny cenowo. Jest po prostu super łatwy do użycia.

Łukasz Kałużny: Jako przykład APM-ów. Ja, Architektura 101, czyli wprowadzenie do świata architektury i uporządkowania wiedzy jak projektować systemy. Ale nie jest to perspektywa DDD, tylko jak patrzeć na architekturę i o rzeczach, o których przy samej software architecture nie myślimy. Czyli patrząc jak wygląda bezpieczeństwo, charakterystyki, architektura trochę sieciowa czy budować, czy kupować, czy może open source. Więc różne takie decyzje, które trzeba zrozumieć, które są nie tylko w samym software, czyli jak poukładamy nasze klasy czy jaki mikroserwis zrobimy.

Szymon Warda: No dobra, to co, lecimy w takim razie z odcinkiem.

Łukasz Kałużny: Dobra. To co? Czemu Copilot robi z nas gorszych programistów? I tak na początku myślałem, że będzie to marudzenie.

Szymon Warda: No bo tak brzmiałoby, zapowiedzi, powiedzmy sobie.

Łukasz Kałużny: Tak, ale jeżeli popatrzymy, to faktycznie ten skill pisania kodu. Jeżeli pójdziemy i zobaczymy jak działa teraz sobie Copilot, Cursor czy inne pluginy, które możemy doładować, że tym tabem piszemy komentarz i lecimy tabem bez zastanowienia, to one faktycznie, te ostrzenie piły i tą pamięć mięśniową i sposób myślenia będzie nas z niego okrajał. Nie będziemy tego pielęgnować.

Szymon Warda: Okej, ale to samo robił ReSharper czy inne toole, które wspomagały programowanie, że robiłeś taba i Ci się sam robił.

Łukasz Kałużny: Czy wiesz co, tak i to jest gdzieś to. Więc wiesz, to jest teraz powiedzenie sobie: wiesz co, może dużo… Inaczej, bo też będę powtarzał, to są super narzędzia. Ale z drugiej strony pewna rzecz, jeżeli ktoś jest fulltime’owym devem, to częściowo… Inaczej, to jest teraz taki trochę rozdział, gdzie z jednej strony będzie marudzenie, że ten kod jest super, bo jest tylko pisany przez człowieka, co wiemy, że rzeczywistość nie jest taka. A z drugiej strony ten automatyczny kod jest też trenowany na tym kodzie pisanym przez człowieka i będzie. Ale jest jedna rzecz, która jest dobra taka podsumowując, raczej dwie. W niektórych miejscach będzie zabierał zdobywanie głębszej wiedzy. Jeżeli coś jest Twoim fulltime’owym zrozumieniem jak to działa i będzie trochę zabierał te kreatywne myślenie.

Szymon Warda: Wiesz co, ja bym się z tym nie zgodził tak naprawdę, bo mam wrażenie, że blokowanie tego jak co działa, to nie jest kwestia narzędzia, to jest kwestia ludzi. Znamy dużo programistów i chyba z wieloma pracowaliśmy. Są ludzie, którzy będą po prostu zawsze dopytywali się dlaczego i próbowali zrozumieć czemu. I są ludzie, którzy będą przyjmowali: ok, muszę użyć tego API. Tyle potrzebuję i nic więcej nie chcę wiedzieć.

Łukasz Kałużny: Wiesz co, miałem takiego kolegę Jacka. Jacek mówi: ja nie wiem, co ten kod robi. Ja tylko implementowałem specyfikację.

Szymon Warda: No właśnie. Więc to jest kwestia bardziej osoby. A przyznaję się, faktycznie, pisanie kodu Basic Sharpera albo takiego w czystym Notatniku jest upierdliwe, tudzież [niesłyszalne 00:04:20], to jest takie coś: jak to wyglądało? Ale wydaje mi się, że ta pamięć mięśniowa, o której mówimy w sensie, że sami szybko wyklepiemy fora i tak dalej, czy to jest potrzebne? Nie jest potrzebne.

Łukasz Kałużny: Wiesz co, ja bardziej mówię, że w pewnym momencie nie będziemy wiedzieli, w szczególności na niższych etapach, które teraz na przykład wchodzą, są juniorami, dopiero regularami. To troszeczkę może być z tym problem, że oni nie będą w ogóle kumali co generują.

Szymon Warda: Ale w ogóle problem juniorów i problem tego, że uczymy się jak się uczymy i że i zarówno COVID i teraz jeszcze całe AI wymiótł właściwie w ogóle pozycję juniora i to, że nie mamy obecnie w ogóle żadnego pomysłu, jak uczyć juniorów i jak kształcić kolejne pokolenia, to się zgodzę. W ogóle bez dwóch zdań. Tylko wydaje mi się, że to nie tylko AI jest tym winnym, że tak powiem, tak naprawdę, ale to jak sprzedawaliśmy ludzi.

Łukasz Kałużny: Druga sprawa, rozdrobnienie technologiczne jest teraz już klątwą każdego. I drugi wątek, który jest, który stamtąd wynika, to jest że niektórzy staną się zbyt zależni od tych automatów. I z drugiej strony będą mieli zbyt duże poczucie eksperckości aka zajebistości w tym, co robią.

Szymon Warda: Nie przeklinamy, słuchają tego dzieci.

Szymon Warda: Wiesz co, bym się z tym zgodził. Tak, jest ta cała klątwa generalnie, że czym mniej wiemy, tym bardziej nam się wydaje, że jesteśmy większym ekspertem. Dla mnie raczej, ja widzę inne zagrożenie w tym wszystkim, ale też zagrożenie, które wynika z tego, jak widzę i jakie mamy rozmowy, właśnie to jest to, że dążymy do pisania pięknego kodu, który często nie działa tak naprawdę. I wszędzie będziemy stosowali super, mega fajne wzorce i kod, który powiedzmy mieścił się w 10 liniach nagle będzie rozrzucony na 20 klas, 8 interfejsów. I tak to będzie wyglądało. Bo czemu? Bo tak wzorce wyglądają. I żeby nie było, to ma sens, ale nie każda funkcja musi być za interfejsem, itd. To pojęcie co jest prywatne, co jest wewnętrzne, co warto, co zamienimy, a czego nie warto zamieniać, bo tego nigdy nie wymienimy i nie ma co robić na zasadzie, że bo się kiedyś przyda, albo bo może kiedyś wymienimy. Bazy danych nigdy nie wymienimy, nie oszukujmy się. Ja się bardziej tego boję, że tego kodu boilerplate’owego będzie tak dużo, że poruszanie się w tym code base’ie będzie po prostu coraz, coraz większe i trudniejsze. Bo znalezienie czegoś, co robi coś wartościowego albo sensownego będzie coraz trudniejsze.

Łukasz Kałużny: No dobra, co u Ciebie teraz?

Szymon Warda: A to ja pokontynuuję Twój wątek. Kontynuuję wątek, bo znowu link odnośnie tego Copilot productivity gains at big companies. I o co chodzi? Jest badanie, które mówi, że osoby, które mają Copilota, generują o 24% więcej PR-ów. Ustalmy, 24% to jest dużo, to jest bardzo, bardzo dużo. Była poprawka, bo oczywiście ktoś może za chwilę powiedzieć, że: okej, ale te PR-y mogą być mniejsze. Była poprawka i ci ludzie z reguły generują nawet większe PR-y niż ludzie bez Copilota. Więc oczywiście znaczy, że jest super, Copilot działa. To mi ta cała argumentacja, bo właściwie link bardziej daje do dyskusji, bo mi ta cała argumentacja przypomina bardziej sytuację, jak na moich studiach, że właśnie była dyskusja o tym, jak mierzyć wydajność programisty, że właśnie mierzmy go przez ilość linii, które wyprodukuje.

Łukasz Kałużny: Klasyczny LOC, klasyczny LOC.

Szymon Warda: Tak, to śmierdzi dokładnie tym samym tak naprawdę. I też właśnie moja obawa tego, że okej, Copilot będzie generował, ludzie z Copilotem będą generowali po prostu bardziej rozbudowany kod, tak to nazwijmy, żeby nie dawać jakichś tutaj określeń negatywnych czy pozytywnych tak naprawdę. Ale ogólnie problem jest taki, wydaje mi się, ze wszystkimi właśnie obecnymi narzędziami i w ogóle wcześniejszymi narzędziami do wydajności, że nie mamy jak mierzyć wydajności developerów, developerów jak developerów, narzędzi wspierania developmentu. Nie ma, a mierzenie to przez ilość generowanego kodu jest po prostu z definicji błędne.

Łukasz Kałużny: Nie powinno się wydarzać.

Szymon Warda: Tak, ale jest jakimś tam powiedzmy punktem sprzedażowym wielu ludzi.

Łukasz Kałużny: Ale słuchaj, to będzie tak jak klasyczne mierzenie wydajności w Agile’u poprzez ile człowiek dowozi punkcików w sprincie.

Szymon Warda: Tak, a jeszcze najlepiej porównywanie tych punkcików między zespołami, gdzie każdy ma inną bajkę. No bo tak to często wygląda, nie oszukujmy się. Dobrze, lecisz dalej. Nie ma co kontynuować tego tematu.

Łukasz Kałużny: Dobra, teraz rzecz, co jest ciekawe, tutaj terytorium, które stoi, Chagos Islands, które stoją za domeną .io, bo to jest najważniejsze, to ten teren, suwerenność będzie przekazana Mauritiusowi.

Szymon Warda: Idzie pod wodę?

Łukasz Kałużny: Ja nie wiem czy to idzie pod wodę, akurat tak się nie zagłębiałem. Dla chętnych sprawdźcie i skomentujcie czy Szymon ma rację czy nie. Ale słuchajcie, całość jest taka, że czy domena .io zniknie czy nie? Bo domena .io, na której my też hostujemy podcast, podpada właśnie na te. I historycznie były już akcje, że Jugosławia, ZSRR znikały z tych rejestrów końcówki.

Szymon Warda: Tak, idą pod wodę.

Łukasz Kałużny: To idą pod wodę? Sprawdziłeś?

Szymon Warda: Tak, jest zagrożenie.

Łukasz Kałużny: Więc teraz jest takie ciekawe pytanie, co też w tym wpisie zobaczycie, co będzie z końcówką .io, ponieważ dużo techu na tym stoi, oj dużo.

Szymon Warda: Dużo techu, był okres, że posiadanie domeny .io było takim badge of honor, że trzeba było to mieć.

Łukasz Kałużny: W końcu nawet zapowiadając, sprawdźcie na Patoarchitekci.io.

Szymon Warda: Nie od parady też pokazuje, kiedy to było tworzone.

Łukasz Kałużny: Tak.

Szymon Warda: Ciekawe, bo faktycznie własność domen tych narodowych należy właśnie w ramach faktycznego tego kraju generalnie, więc to jest ok.

Łukasz Kałużny: To bardzo ciekawy problem, który monitoruje, bo jest mi wrzodem na tyłku, w szczególności jeszcze, że prywatnie również mój mail kończy się na .io.

Szymon Warda: Jeden z wielu Twoich maili, powiedzmy sobie.

Łukasz Kałużny: Tak, ale tego, którego najczęściej używam i na którym mi zależy. Więc zobaczymy jak to będzie wyglądało.

Szymon Warda: Dobra, to ja trochę tak schodząc na ziemię, dobry, fajny artykuł. Kojarzysz Deezera? Taki serwis kiedyś sobie istniał, dalej sobie istnieje.

Łukasz Kałużny: Do muzyki, streaming muzy.

Szymon Warda: Dokładnie, dokładnie, dokładnie tak. Napisali bardzo ciekawy artykuł, w którym opowiadają dokładnie jak wykorzystali customowe metryki aplikacji do skalowania horyzontalnego podów. Całkiem fajny artykuł, dobrze napisany, z przykładami, z faktycznymi komendami, YAML-ami, itd., jakby ktoś chciał. Ale o co w ogóle chodzi? Chodzi o to, że tak naprawdę horizontal autoscaler kubernetesowy domyślny, on się skaluje na bazie tych podstawowych metryk, CPU, pamięć, itd., generalnie. Czyli powiedzmy sobie to są metryki, które jak już jest za późno, to…

Łukasz Kałużny: Działają, ale domyślnie nie skalują się na przykład na ilość sesji HTTP.

Szymon Warda: Tak.

Łukasz Kałużny: I requestów.

Szymon Warda: I co oni zrobili? Bo zrobili coś mega fajnego i to się może przydać niejednej osobie, która nas słucha. Po pierwsze, zaczęli produkować poprawne metryki w aplikacji Prometheusowe, bo Prometheus już jest standardem, więc wystawili jako Prometheusowe, użyli Prometheus Adaptera, którym zastąpili Metrics Server i dzięki temu mogli skonfigurować Horizontal Autoscaler, żeby odpytywał się o konkretne metryki i skalować się na metryki aplikacyjne. I to im daje bardzo fajne wyniki, bo mogą skalować się na bazie metryk, które mają jakieś sensowne znaczenie tak naprawdę. Między innymi właśnie to, o czym mówisz?

Łukasz Kałużny: Tak. Ja bym powiedział, że to jest mokry sen Kubernetesa, ogólnie mokry sen cloudu i autoskalowania, że weźmy ważne metryki aplikacyjne, wykorzystajmy wreszcie do skalowania albo ilość eventów na kolejce.

Szymon Warda: Znaczy powiem tak, no tak, na takie rzeczy chociażby w funkcjach Azure’owych chodziło o wielkość serwisu, żeby skalować się zanim coś się zacznie już przytykać tak naprawdę. Ale wydaje mi się, że ten kierunek, bo to nie jest pierwszy artykuł, który się spotkałem, ale on był faktycznie napisany na tyle dobrze, że się nim podzieliliśmy, to jest to właśnie, że przejście na metryki customowe, żeby ten horizontal autoscaler jednak nie był taki naiwny, nie oszukujmy się, zacofany.

Łukasz Kałużny: Wiecie co, to ja jedna polecajka od razu i przypominajka, czyli keda.sh, Kubernetes Event Driven Autoscaler. Bo dużo rzeczy, jak nie chcecie robić już tych metryk w tym, to bardziej inteligentne metryki można zrobić KEDA-om na Kubernetesie. To też jest ważne.

Szymon Warda: Ja dodam, że to nie jest koniecznie autoscaler, tylko to jest cały zbiór autoscalerów.

Łukasz Kałużny: Tak, więc macie bardzo dużo źródeł, da się zrobić ciutkę inteligentniejsze i chyba z takich rzeczy, to już nie patrzcie na CPU ram, bo one zazwyczaj są za późno wyznacznikiem. Dobrze jest zobaczyć na przykład ilość requestów na Ingressie czy ilość itemów na kolejce, bo to się świetnie sprawdza.

Szymon Warda: Tak, bo łącznie ma skalowanie też na wszystkie rzeczy, które hostujecie w Kubernetesie, czyli wszystkie Kafki, Rabbity i inne rzeczy. Więc można sobie fajnie ogarnąć całe operations jeżeli chodzi o takie rzeczy, które są w klastrze. No ale dobrze, lecisz Łukaszu dalej. Już pochwaliliśmy się i powiedzieliśmy co jest dobrego.

Łukasz Kałużny: I w ogóle tak pomagamy z takimi autoskalowaniami, jeżeli macie ochotę w Protopi. Dobra. I teraz coś, czego żałuję, że pokazałem to Szymonowi przed odcinkiem, bo spadł z krzesła.

Szymon Warda: Potwierdzam, to było dobre.

Łukasz Kałużny: To jest starość sprzed sześciu lat, ale ostatnio mi znowu trafił i stwierdziłem, że go przypomnę, bo chyba nigdy nie był w Pato: Volkswagen.

Szymon Warda: Pojawia się, co to jest? To jest biblioteka, która sprawdza czy testy są uruchomione na serwerze zdalnym. Jeżeli tak, to wychodzą.

Łukasz Kałużny: Czyli jeżeli coś jest odpalane, macie node’a i odpalacie buildy, testy na SI to zawsze przechodzą na zielono.

Szymon Warda: Tak. Osoby, które nie kojarzą czemu nazywa się akurat Volkswagen to oczywiście zachęcamy do przejrzenia informacji o Volkswagen i Diesel, powinno dość szybko znaleźć.

Łukasz Kałużny: Diesel Gate. Czyli jak Volkswagen był w stacji diagnostycznej, żeby przejść badania spalin, to przełączał się na tryb, żeby zawsze przejść.

Szymon Warda: Tam się okazał akurat moduł Boscha.

Łukasz Kałużny: Ale ten kod był tylko w Volkswagenie dziwnym trafem.

Szymon Warda: Zgadza się, jak najbardziej. Dobra, to ja trochę pociągnę, jakoś dzisiaj widzę ja mam taki kątek Kubernetesowy i jednocześnie AI-owy, zobacz łączę dwa obszary.

Łukasz Kałużny: Zabrałeś mi je.

Szymon Warda: Tak. Jest całkiem ciekawy wpis. Wpis jest o tym jak jedna firma użyła AI-ja faktycznie do monitorowania diagnostyki i troubleshootingu w ogóle node’ów Kubernetesowych. Ale co tam jest? Oczywiście brzmi to bardzo magicznie, ale co tam jest wartościowe tak naprawdę? Po pierwsze to jest to, że wybrali złote sygnały, złote metryki, które aplikacje monitorują. Potem dorzucili k8sGPT do tego, żeby móc robić diagnostykę. Do tego dorzucili swój własny serwis do embedingów, dorzucili własne ragi, dorzucili własne modele hostowane na on-premie, żeby też rozumiały kontekst z ich runbookami, itd. I mają dość ciekawy efekt, bo czym więcej o tym myślę, to wydaje mi się to mega sensowne właśnie, po to, żeby zbudować coś, co będzie umiało niejako wspierać tą linię wsparcia powiedzmy drugą albo trzecią tak naprawdę w kontekście diagnostyki, co się na tych klastrach dzieje. I to brzmi jak naprawdę dobry pomysł bym powiedział.

Łukasz Kałużny: Wiesz co, zobacz, teraz już podlinkuję narzędzia, jeżeli sobie przypomnę nazwę, ale ogólnie były już kubectl spięte z OpenAI do debugu, bo wiem, że nawet miałem okazję to pokazywać na prezentacjach ponad rok temu takie pierwsze wersje i one gdzieś pierwszą taką sensowność do troubleshootingu miały.

Szymon Warda: Tak, ale teraz właśnie ten k8sGPT, on obecnie jest jednym z najmocniej rozwijanych w ogóle projektów CNCF-ie i to naprawdę zyskało tak konkretnie wiatr w żagle.

Łukasz Kałużny: No tak, te pluginy, są ciekawą rzeczą, żeby sobie, tak, bo właśnie on też, to właśnie dobrze, że o nim powiedziałeś, bo on przecież zjoinował się do GitHub Foundation… Nie do GitHub, bożesz, do Cloud Native Computing Foundation.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Zrobił joina.

Szymon Warda: Rozwija się.

Łukasz Kałużny: Więc te narzędzia, tak, w ogóle ta diagnostyka. Tylko z drugiej strony niby to wygląda, mam też trochę do czynienia czasami, z dowcipu sprawdzam sobie Azure Copilota. No przemilczmy może o tak, bo jeszcze mi MVP zabiorą. Dobra, to ostatni wpis na dzisiaj od Cloudflare. Cloudflare zabawił się w gnębienie trolla patentowego, czyli Sable. I co było? Wygrał proces. Sable musi zapłacić tam trochę ponad 200 tys. dolarów i uwaga, uwaga oddać wszystkie swoje patenty do domeny publicznej.

Szymon Warda: To jest nieźle, bo trochę nadam kontekst prawa, jeśli chodzi o sądowe. W Stanach jest tak, że jeżeli… W Polsce jest tak, żeby kontekstu podać, kontekst między Europą w ogóle generalnie a Stanami, to jest tak, że jeżeli kogoś pozwiesz i przegrasz, to oddajesz kasę. W Stanach tak nie ma. W Stanach jest tak, że jeżeli pozwiesz, przegrasz to generalnie nic po prostu, nie musisz pieniędzy oddawać, przez co właśnie to zachęca trolli patentowych, że oni po prostu kasowo Cię zajadą po to właśnie żebyś nie miał kasy na obronę. Także to naprawdę, w kontekście prawodawstwa w Stanach to jest bardzo konkretna wygrana.

Łukasz Kałużny: Tak. No i teraz jest sobie taki Project Jengo, który ma właśnie chronić przed, jak sobie zobaczycie, chronić przed takimi rzeczami. Więc to się tam dzieje i to jest super sprawa, patrząc się na takie coś. W szczególności, że to dzieje się w Stanach. Trollerstwo patentowe dzieje się w Stanach i w Kanadzie. I to jest dobra rzecz, bo w Europie tak tego nie opatentujesz, takich rzeczy jak tam są.

Szymon Warda: Zgadza się. I też te koszty procesowe są dużo większe, więc to po prostu się nie opłaca. Nie ma sensu ryzykować jak wiesz, że przegrasz. W Stanach, jak wiesz, że przegrasz, a masz więcej pieniędzy to i tak możesz wygrać. Więc to jest taka dość potężna broń. Dobrze. A to jeszcze poreklamujemy, bo są linki, które się nie mieszczą się z reguły do odcinka bo z tego kontekstu, że albo to nie jest format, o którym warto mówić. Ale jest jeden bardzo fajny link, który omawia to, jak Netflix zajmuje się buforowaniem, cache’owaniem i propagacją wszystkich cache’ów. Bardzo długi artykuł, bardzo techniczny i trochę nie na omówienie do podcastu. Tak że zachęcamy oczywiście do naszego newslettera, będzie.

Łukasz Kałużny: I druga rzecz, na Discordzie pojawił się kanał od kuchni. Teraz możecie zobaczyć moje żale na Prompt Engineering i modele oraz jak Pato automatyzuje się w backendzie.

Szymon Warda: Tak, tak że jakby były jakieś halucynacje, to wiecie czemu. To nie dlatego, że popiliśmy, tylko dlatego, że to halucynaowało.

Łukasz Kałużny: Albo nie było czasu poprawić w czwartek wieczorem przed publikacją odcinka któregoś opisu.

Szymon Warda: Tak, możliwe. Dobrze, tyle chyba.

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