Ł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. Gdzieś na dole w opisie. Ogarniecie sprawę. Dobrze, chwalimy się Łukaszu, szkolenia.

Łukasz Kałużny: Tak, zaczynamy od szkoleń. Czyli macie cały katalog ich na stronie: Patoarchitekci.io/szkolenia. Najbliższe to za tydzień będzie Szymon prowadził, Modelowanie Danych.

Szymon Warda: Tak, trochę właśnie o rzeczach w bazach NoSQL-owych, ale głównie skupimy się na tym, jak odpowiednio zamodelować dane do przypadku użycia, a potem dopiero jak do tego dobrać odpowiednią bazę i gdzie one mają plusy, a gdzie mają minusy. Bo jak wiemy tych srebrnych pocisków nie ma i nie będzie.

Łukasz Kałużny: Więc SQL, patrząc na Twoje szkolenie, jeszcze nie zginął, znając jego zawartość.

Szymon Warda: SQL istnieje od 40+ lat, dalej będzie sobie istniał, bo jest dobrym językiem.

Łukasz Kałużny: Dobra, jak jesteśmy przy SQL-ach, to dobrze się złożyło, link z naszego Discorda. Tutaj Przemek M. wrzucił Postgresa, bo w sumie wyszedł nowy release Postgresa. Dzięki Przemku. Jak chcecie dołączyć do Discorda to link też znajdziecie w opisie. I teraz co, wyszedł Postgres 17. Z rzeczy performance’owych dwie rzeczy, które się pojawiły. Po pierwsze, mechanizm Vacuum, czyli sprzątanie plików etc., 20 razy mniej pamięci. Poprawili struktury pod spodem, co na tak dojrzały produkt jest kurde przeskokiem typu WOW.

Szymon Warda: Pytanie, jak to się odbije na ogólnej wydajności?

Łukasz Kałużny: Tak, tylko pamiętaj, że to jest proces czyszczenia, bo oni tą strukturę do czyszczenia poprawili i to jest jeden z takich.

Szymon Warda: Jednak finalnie użytkowników interesuje ogólna wydajność systemu, bo to jest forma mikro optymalizacji mimo wszystko.

Łukasz Kałużny: Tak, która jest przy dużych bazach kluczowa w przypadku Vacuuma, bo jednak sprzątanie w Postgresie jest newralgiczne, chyba bardziej nawet niż optymalizacje w SQL Serverze, które robisz na plikach.

Szymon Warda: Finalnie interesuje mnie performance całościowy, jakby to wyglądało.

Łukasz Kałużny: Druga rzecz, która się z performance’u pojawiła, to na indeksach B-Tree wprowadzono bulk scana i to jest właśnie też link od Przemka. Czyli że można hurtowo skanować indeksy i równolegle. I zaczyna to dobrze działać, słuchaj, w przypadku jak masz klauzulę na przykład IN.

Szymon Warda: Tak, czytałem artykuł, faktycznie niezły, że od razu do funkcji skanującej drzewo, która przegląda te wszystkie gałęzie drzewa i nie idzie pojedyncza wartość jak szła wcześniej, tylko idzie faktycznie cały zestaw identyfikatorów.

Łukasz Kałużny: Tak, więc jeżeli ktoś IN lub podobne klauzule wykorzystuje, to działa to świetnie. Z rzeczy, które tam popatrzymy, to jeszcze replikacja logiczna poszła do aktualizacji. W uproszczeniu, ułatwiono aktualizację, jeżeli robimy sobie klaster z replikacją logiczną. Czyli wszystkie tematy wysokiej dostępności są tutaj lepiej zaadresowane, to widać tą stabilizację w tym. Bo w Open Source’owych bazach ta wysoka dostępność zawsze była wrzodem na tyłku, to mało powiedziane, zawsze to było w jakiś sposób narzeźbione wokół różnym toolingiem, a tutaj zaczyna wyglądać to o wiele, o wiele lepiej. Co tam jeszcze? Z bezpieczeństwa, taka ciekawostka, ale wprowadzono Row Level Security na poziomie widoków.

Szymon Warda: To jest akurat ciekawe.

Łukasz Kałużny: Tak, jeżeli ktoś faktycznie przesuwa odpowiedzialność na bazę danych, to jest naprawdę ciekawy element. I druga strona, JSON Table, czyli zrób mi z JSON-a format tabelaryczny. Już się powoli przyzwyczajam, że z Postgresa da się zrobić wszystko.

Szymon Warda: Da się zrobić wszystko. Przypominam, kiedyś omawialiśmy jak z Postgresa zrobili Postgres As Code, czyli sterowanie infrastrukturą Azure’ową i AWS-ową w formie insertów postgresowych.

Łukasz Kałużny: Czy zbudowanie kolejki na mechanizmach notyfikacji.

Szymon Warda: Tak, takie rzeczy też da radę zrobić. Mnie cieszy bardzo rozwój Postgresa, bo faktycznie stał się realną alternatywą do tego, co się obecnie dzieje. Jakoś do MySQL-a się nie mogłem przekonać nigdy. I tam parę takich krytycznych zmian typu brak update’u, brak transakcyjności na updatecie schematu trochę jest upierdliwy, nazwijmy to delikatnie już poważnym brakiem. Postgres stabilny, ciągły, powolny wzrost i to staje się realnie alternatywą.

Łukasz Kałużny: Raczej taką zaczyna być definicją: masz problem z wyborem bazy? Użyj po prostu Postgresa i nie kombinuj.

Szymon Warda: Tak zaczyna się dziać. Dobrze. Teraz ja przejmuję, robię tzw. hijacking Twojego kącika AI-owego. Tak właśnie generalnie, ale trochę w innym ujęciu. O co chodzi? Wyszedł fajny papier, czy publikacja naukowa, bo trzeba to nazwać naukową publikacją już, odnośnie użycia Copilota i narzędzi wspomagających development w trzech dużych firmach w Microsoft Accenture i jednej anonimowej. I teraz nie wiemy, czy oni mogą, ale dane są całkiem ciekawe. Co w ogóle zostało odkryte, tudzież zbadane tak naprawdę? Ogólnie jest wzrost zakończonych pull requestów, commitów i buildów. Przy czym wzrost zakończonych pull requestów był najbardziej statystycznie ważny, pozostałe nie do końca miały ważność statystyczną. Czyli był, ale to mogło być w granicach błędu. Ale najciekawsze są połączenia, czyli było to badane na różnych grupach, na seniorach, juniorach i osobach nowych w organizacji. I to jest bardzo ciekawy element. To jest to, że główne wnioski: developerzy, którzy są młodzi w firmie, czyli mają krótki staż, szybciej adoptują Copilota, 9 5%. Juniorzy też, ale w mniejszym stopniu. 5,3. Co dalej? Osoby młodsze w firmie będą prawdopodobnie używali Copilota, bardziej po miesiącu, czyli niezdropują go w ciągu miesiąca. Co dalej jest? Badanie odnośnie uznawania podpowiedzi, które daje Copilot. Ci z długim stażem byli o 4,3% mniej skłonni do uznawania podpowiedzi. Seniorzy, to już było tylko 1,8%, skłonni do uznawania podpowiedzi. Finalnie wyszło, że mniej więcej 30-40% developerów używa Copilota. Co wyszło też generalnie? Że zakończenie tasków mniej więcej wzrosło o 26%. Liczba commitów, liczba, niekoniecznie ich jakość, 13,5% i 38,3% powiedzmy wyszło na increase in builds. Trochę ciężko jest rozszyfrować o co dokładnie chodzi. Ale z tego się wyłania dość jednoznaczny widok, moja interpretacja. Jakie taski będzie miał junior albo osoba młoda w organizacji? Proste. Te, które faktycznie Copilot ogarnie, bo to będą takie rzeczy na poznanie domeny. A seniorzy, którzy mają taski już takie konkretne, gdzie Copilot nie będzie działał tak świetnie, to będzie dużo mniejsza.

Łukasz Kałużny: Patrząc się, bardzo się zgadzam co do jakości podpowiedzi Copilota, to jest właśnie istotne. Bo to jest, trzeba powiedzieć, to wszystko leci mocno do przodu i inne modele niż Copilot, zauważ, kurde radzą sobie lepiej. Copilot ma tylko jedną dużą zaletę Szymon.

Szymon Warda: Dajesz.

Łukasz Kałużny: Compliance.

Szymon Warda: Dlatego będzie wykorzystywany w dużych firmach tak naprawdę. I to jest to. Ale to musimy mieć tak realnie. Wiesz co, ale wydaje mi się, że można ugenerycznić tak naprawdę szerzej właśnie, że ogólnie modele generyczne, nie wyuczone na zbiorze kodu, które ma organizacja, będą świetne w generycznych taskach. Czyli taskach, które dostają juniorzy i osoby młode w organizacji. Czyli masz task [niesłyszalne 00:08:36], sorry, ale tam już generyczność nie pomoże.

Łukasz Kałużny: Wiesz co, szybkość generowania kodu, jeżeli teraz pójdziemy sobie na przykład do Cursora, którego tam oglądam, czy podpięcia sobie Anthropica do Visual Studio Code, np. jest w tych zaawansowanych zadaniach o wiele lepsza, to teraz tak z mojego takiego testowania, jest o wiele lepsza niż czysty Copilot. Tylko to są już specyficznie wytrenowane modele i przygotowane pod to. GitHub jest mocno, Copilot jest mocno generyczny.

Szymon Warda: Jest tak, zgadza się. W Anthropicu możesz już dorzucić swój własny kontekst dużo łatwiej.

Łukasz Kałużny: Dużo łatwiej, tak, jest dużo łatwiej.

Szymon Warda: Dochodzi do tego, co właśnie mówiłem, że potrzebujesz napchać tam swojego kontekstu po prostu.

Łukasz Kałużny: Wiesz co, dla obrony Copilota, nie testowałem wersji Enterprise, kiedy możesz załadować swój codebase i jestem ciekaw takich wyników, kiedy masz też załadowany swój codebase, bo tego chyba w tym papierze brakuje, takiego odniesienia, czy on był ładowany czy nie.

Szymon Warda: Tak, faktycznie, nie ma doszczegółowienia tego, czy to jest Enterprisem czy zwykłym. Chociaż było to w Microsoft i Accenture, więc zakładałbym, że jednak może być.

Łukasz Kałużny: Ale widzisz, czy był załadowany codebase? Bo zobacz, że Microsoft nie ładuje codebase’u na GitHuba swojego.

Szymon Warda: Ciekawe. Tak. Dobra, lecimy dalej.

Łukasz Kałużny: Dobra. Kolejną rzeczą, jak jesteśmy, ja dzisiaj będę znowu przy bazach danych jeszcze przez chwilę. Service Now, czyli wielka platforma do ticketów, ktoś by się zaśmiał, ale też CMDB i innych funkcji do zarządzania IT w Scali, w szczególności jak nie jesteśmy SAS-em czy produktem. I co zrobili? Słuchajcie, to zeszli z MariDB na rzecz własnej wersji Postgresa.

Szymon Warda: A MariaDB to było, o ile pamiętam, fork MySQL-a zaczęty przez Facebooka, o ile pamiętam.

Łukasz Kałużny: Tak, dokładnie. I teraz patrząc się widziałem, miałem okazję robić analizę kiedyś Service Now w takim bardzo szalonym scenariuszu, z opcją wycofania się z Service Now do jego wersji on-premowej. Bo wyobraź sobie, specjalnie dla klientów Service Now ma takie dziwne wersje. Jakby ktoś kiedyś potrzebował analizy, w ogóle wyjścia z chmury i innych takich rzeczy też, zapraszamy do nas na konsultacje do Protopii. I w trakcie właśnie takich konsultacji musiałem poświęcić dwa albo trzy tygodnie na poznawanie Service Now .D tej strony jak to wycofać? I oni dawali właśnie swoją wersję, między innymi z MariąDB. Jak można sobie wyobrazić przenoszenie czegoś z SAS-a do lokalnej wersji, takiej hostowanej u siebie, wyglądało to poklejonie i pokracznie, o tak można to nazwać. Ale wracając do całości. Kiedyś, nie wiem jak w tym momencie wygląda architektura Service Now, ale ona była mocno single-tenantowa tego w jaki sposób to hostowali u siebie. I jestem ciekaw jak to wygląda. Czemu ten Postgres tak naprawdę się pojawił tutaj?

Szymon Warda: Kasa? Możliwości? A czy mnie zdziwiło to, że przeszli nie na czystego Postgresa, tylko na swojego Postgresa. Ambitnie, tudzież powiedziałbym też, że ryzykownie przy okazji.

Łukasz Kałużny: Właśnie, teraz przechodząc też są z tyłu zakupy pod spodem, które gdzieś tam się pojawiają. I kolejna rzecz, Knowledge Graph, który chcą wprowadzić.

Szymon Warda: Ja obstawiam, że to nie jest Postgres, taki homebrew, jak jest ładnie nazwany, też tani, customowy, tylko że mają bardziej, dodali po prostu całą serię pluginów pod siebie.

Łukasz Kałużny: Właśnie, to jest pytanie właśnie co… Ale nazwa jest niezła. Podoba mi się. RaptorDB.

Szymon Warda: Wiem, że Park Jurajski zrobił na Tobie duże wrażenie aż do dzisiaj.

Łukasz Kałużny: Słuchaj, to jest pierwszy film, który pamiętam tak realnie z kina, jako całą fabułę i inne rzeczy. Więc już jesteśmy dinozaurami, Szymon, trzeba się z tym pogodzić.

Szymon Warda: Dobrze, to przechodząc do kolejnego tematu, całkiem ciekawy artykuł od Ubera odnośnie ich migracji. I teraz co jest najciekawsze w tym artykule, to jest to, że Uber zaczął się migrować ze swoich mikroserwisów na pojedyncze, większe serwisy. Hurra! Pamiętajmy, że Uber miał, chyba chwalili się około 3,5 tys. serwisów łącznie. Taka dość potężna liczba.

Łukasz Kałużny: Nawet to omawialiśmy, czyli copy, paste i deploy’uj.

Szymon Warda: Tak, dokładnie tak to wyglądało. I przy pewnym wzroście organizacji to miało sens, żeby nie było, kontekst jest tu najważniejszy. Ale artykuł jest dość fajny odnośnie migracji systemu z jednego na drugiego, bo pokazuje bardzo fajnie kilka rzeczy. Migrowali system odnośnie, właściwie centralny system odnośnie właśnie ogarniania encji i kierowcy encji, osoby przejeżdżającej i encji samego przejazdu, samego tripu. I fajnie pokazywali strategię rolloutu. Nie jest to jakieś może super odkrywcze, ale urealnia jak to wygląda i że nie trzeba robić to takim big bangiem. Co się dzieje? Po pierwsze, generalnie shadow rollout. Czyli pierwsza rzecz to jest to, że odpalamy nowy system razem równolegle ze starym systemem i porównujemy requesty. Ten nowy nic nie robi. Kolejne to jest to, że jak ogarnęli wymianę danych między systemami? Zrobili faktycznie cash, który łączy te systemy, dzięki czemu, ponieważ to jest system persystentny, to miał pewien zestaw informacji. Robili też od razu przy okazji grupowanie błędów na kohorty czy na grupy podobne itd., itd., żeby tego nie analizować pojedynczo. I też analizowali sytuacje, gdzie te wyniki mogły być różne, bo faktycznie mogły być różne. Dla Scali, oni tam chwalą się, że akurat ten serwis to są setki różnych konsumentów tego API, co przy ich skali jest możliwe, raczej skali, ilości serwisów, bardziej o to mi chodzi. Ale co tutaj fajnie wyszło i co jest takie wartościowe i urealnia? To jest to, że cały rollout zajął im 4 miesiące. To jest długo. Przez ten czas głównie robili hardening nowego systemu i zainwestowali około 40% czasu w observability nowego systemu. 40% czasu developerki po to, żeby dodać generalnie system wspierający. To jest dużo.

Łukasz Kałużny: Ja teraz mam taką jedną rzecz, jak patrzę na Ubera. Ciekawe, czy dałoby się go technicznie wyczyścić jak Twittera?

Szymon Warda: Wydaje mi się, że to się u nich dzieje tak naprawdę.

Łukasz Kałużny: Że samo z siebie zaczyna przechodzić fazę: my tyle nie potrzebujemy serwisów i innych rzeczy.

Szymon Warda: Prosty myk, oni przeszli z takiej dzikiej opcji, że: a, wszystko róbmy szybko, jak najdalej i wprowadzają coraz więcej zamordyzmu. Ten zamordyzm jako pozytyw, czyli porządku.

Łukasz Kałużny: Żeby było już teraz taniej.

Szymon Warda: Tak, bo są już liderem na rynku, to się ustabilizowało.

Łukasz Kałużny: Nawet wykazali zyski.

Szymon Warda: Tak, kilka razy. A swoją drogą, jakbyście byli zainteresowani tematem observability, to oczywiście też zapraszamy na szkolenie, które też będzie. Jest chyba lista zapisowa, prawda?

Łukasz Kałużny: Tak, jeszcze terminu nie wybrałeś. Szymon walczy ze swoim kalendarzem.

Szymon Warda: Kiedyś przewalczę z tym. Ale artykuł, ogólnie rzecz biorąc jest kilka rzeczy nieodkrywczych, ale kilka rzeczy jest naprawdę fajnych, tak pokazujących jak to można zrobić ładnie i tak systematyzujący. Więc naprawdę warte przeczytania. Dobrze, Łukaszu, co u Ciebie?

Łukasz Kałużny: Azure Boost i OpenHCL.

Szymon Warda: Tym razem nie chodzi o Terraforma.

Łukasz Kałużny: Tak, nie chodzi zupełnie o Terraforma. Kilka ciekawych faktów. Po pierwsze, występuje tu Rust przy hypervisorze i wirtualizacji.

Szymon Warda: A to już chyba nikogo nie dziwi.

Łukasz Kałużny: Wiesz co, pierwszy na taką skalę. Bo zauważ, że teraz już mówimy takie publiczne mówienie, że władowujemy Rusta w hypervisor, który chodzi w Azure.

Szymon Warda: No okej.

Łukasz Kałużny: To jest taka pierwsza rzecz, którą… Raczej realność jest taka, że się po prostu to zaczyna dziać. Druga rzecz, która się pojawiła tutaj… Inaczej, teraz ten OpenHCL to jest nowa warstwa parawirtualizacji, żeby pominąć i przyspieszyć operacje IO, czyli dostępu do dysku, sieci, etc., tych wszystkich potrzebnych elementów, które są. I co jest tutaj ciekawego, to to, że zobaczmy, AWS miał swojego Gravitona, czyli dedykowaną całą platformę sprzętową i kod już lata. Nawet nie sprawdziłem przed tym, ale Graviton history, zobaczmy sobie kiedy… W 2018.

Szymon Warda: Ale nawet mam wrażenie, że my to kiedyś omawialiśmy, swoją drogą.

Łukasz Kałużny: Tak, tak, którąś generację… Inaczej, omawialiśmy którąś generację, że powstała i w ogóle wskazywaliśmy. To Microsoft teraz doszedł do ściany, w której zaczyna robić własnego SOC-a pod takie rzeczy, czyli tak naprawdę odpowiednik Gravitona.

Szymon Warda: Ale tam w ogóle, z tego co przeczytałem ten artykuł, to było właśnie, że też wspomagają się własnym hardware’em, co ciekawe, generalnie.

Łukasz Kałużny: Właśnie o tym mówię, że dlatego porównuję to, ten Azure Boost SOC to jest odpowiednik własnego, inaczej, to jest odpowiednik Gravitona, jeżeli popatrzymy sobie. Czyli że pod spodem zaczynamy coraz bardziej pewne rzeczy przerzucać na warstwę sprzętową przy takiej skali.

Szymon Warda: Bo procenty małe się składają przy tej skali.

Łukasz Kałużny: Tak, dokładnie. I to jest taka ciekawostka. Stąd mnie, jak popatrzysz, całość mnie zainteresowała. Jest jedno właśnie, że ten SOC pod spodem - System On a Chip - zaczyna już żyć mocniej. Druga rzecz, to ten Rust i że zaraz Hyper-V, które jest pod spodem, ten cały hypervisor, który jest, przestanie być tym codebasem, który jest wypychany do klientów do on-prema, że te ścieżki się ze sobą mocno rozdzielą.

Szymon Warda: Pytanie czy MS będzie wypychał swój hardware do klientów? A może pytanie jest inne, za ile kasy będzie wypychał swój hardware do klienta?

Łukasz Kałużny: Wiesz co, nie. Pamiętaj, że ma od tego Della, HP i innych. Zauważ, że ten hardware… Były jakieś offeringi dla chętnych do edge computingu, ale to nigdy jakoś… Inaczej, offeringi vendorów cloudowych do tego, co możesz wstawić sobie do on-prema, na koniec dnia się nie opłacają.

Szymon Warda: Na tym nie będzie dużo kasy.

Łukasz Kałużny: Bezpośrednio od nich.

Szymon Warda: Wiesz, to jest kwestia taka generalnie, że jak przyjdzie bardzo duży klient i bardzo dużo zapłaci, to może coś tam zrobią. Pytanie czy to będzie bardzo publiczne i ile tam będzie informacji o tym, bo nie każdego…

Łukasz Kałużny: Z mojej wiedzy na temat tego jak sobie działają te Anthosy od Google’a, AWS już nawet nie pamiętam jak się nazywał, Microsoft miał wpadkę o nazwie Azure Stack, teraz Azure Stack Hub, z którym gdzieś tam miałem do czynienia. I to wszystko, jest gorzej [niesłyszalne 00:20:03] niż te Service Now, o którym wspomniałem. Tam już jest tylko duct tape i trytytki, tudzież opaski zaciskowe, jak kto woli.

Szymon Warda: Dobrze, to co tam jeszcze masz? Bo ja już się z moich linków wypstrykałem.

Łukasz Kałużny: No i trzeci jest przyjemny. Są różne software’y. W PHP-ie takim wiodącym softwarem i przykładem jak nie pisać jest WordPress, jak to niektórzy się śmieją.

Szymon Warda: Łukasza kącik, co się dzieje w oprogramowaniu.

Łukasz Kałużny: Tak. Dramy, dramy. I dramy poleciały. Założyciel WordPressa wkurzył się na to, jak jest używany jego Open Source. Jest sobie firma WP Engine, która świadczy usługę hostowania WordPressa w wydajny sposób. I są jednym z głównych dostawców, największym chyba dostawcą takiej usługi. I tutaj poszło, jak popatrzymy, o użycie marki WordPress i wyłączenie historii postów. Tak, o to się zaczęło. I potem Mullenweg nazwał w swoim poście, wrzucił posta, że WP Engine jest rakiem WordPressa. Już w ten sposób, bo tam ofiarują do tego. Poszło oczywiście o zaangażowanie, bo ofiarują jakiś tam 1 FTI, czy coś takiego do Open Source’owego projektu, ładują z niego kasę, czyli że mało kontrybuują do Open Source’owej wersji.

Szymon Warda: Czyli jak nie wiadomo o co chodzi, to chodzi o kasę.

Łukasz Kałużny: Dokładnie, o to poleciało. Oczywiście poleciały pozwy i inne rzeczy. Gdzieś poleciał też ban, żeby nie dało się pobierać z WordPressa, żeby użytkownicy z tego WP Engine nie mogli pobierać z WordPress.org pluginów i innych rzeczy. Czyli full scale drama, jakie znamy z Open Source’u.

Szymon Warda: Ależ oczywiście, że WordPress Foundation zgłosiło prawa do nazw Manage WordPress i Host [niesłyszalne 00:22:12] WordPress, więc generalnie oczywiście zbiera się na to, że będą chcieli mieć swój offering odnośnie samego samego WordPressa.

Łukasz Kałużny: WordPress jest ten WordPress.com, Automatic czy jak oni się… Już nie znam, nie kojarzę tej nazwy. Wiesz co, mogli po prostu zmienić licencję, jak każda szanująca się firma.

Szymon Warda: Ale jakaś tam drama, a pewnie WP Engine zrobiłby z tego forka, itd., to by się jakoś tam ciągnęło.

Łukasz Kałużny: Ale mogli zrobić jak Mongo.

Szymon Warda: Można by. Dobrze. Masz coś jeszcze?

Łukasz Kałużny: Nie, kończymy na dziś.

Szymon Warda: To trzymajcie się, hej.

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