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 na Patoarchitekci.io lub gdzieś tu na dole znajdziecie linka do tych linków, o których dzisiaj będziemy mówić.

Szymon Warda: I gdzieś na lewo, prawo, górze, dole, oczywiście linka do wyshare’owania, wysłania babci, cioci, szefowi, koledze z pracy, itd., itd., no bo pato to the moon. A co! Dobrze to Łukaszu lecimy, co tam wyszukałeś?

Łukasz Kałużny: Dobra, aktualnie zacznijmy sobie od szydery, bo nie ma jak to dobrze poszydzić z rana, kiedy nagrywamy. Omawialiśmy jakiś czas temu te newsy z .NET Confa i .NET Aspire, który zaczyna zakraczać kręgi absurdu, to co widzę na Twitterze jest wrzucane. Zastanawiałem się w jakiej kolejności powiedzieć, ale zacznijmy od pierwszego tweeta, czy tam X, jak to teraz już nie wiem nazywać. David Fowler wrzucił swój świetny pomysł, który dają, uwaga, odpalanie z runnera dotnetowego aplikacji node’owej.

Szymon Warda: Ale to jest niesamowite, że takie próby odpalania z jednej aplikacji, innej aplikacji to są regularne właściwie. I to nie dotyczy się tylko .NET-u. Ale pytanie podstawowe jest, po co właściwie?

Łukasz Kałużny: Że masz jeden framework, który w ten sam sposób odpala i jakby nie było Dockera.

Szymon Warda: Dla mnie to jest takie, że nie sprawdziło nam się trzymanie wielojęzykowych, wieloframeworkowych mikro serwisów. To jakby nagle nam się sprawdziło trzymanie wielojęzykowych aplikacji. Sorry, nie do końca to widzę. Zawsze można też odpalić po prostu z poziomu procesu generalnie.

Łukasz Kałużny: Obok, tak, właśnie. Próbują zrobić Docker Compose’a. Bo zobaczmy, jest teraz tak, dla mnie całość tego .NET Aspire, muszę znaleźć czas, żeby napisać dobrego tweeta szydzącego i przypominającego np. Scotta Hanselmana, który promował: bądź dobrym kolegą i nie pozwalaj na deploy z Visual Studio.

Szymon Warda: Łukasz, czekaj, czyli potrzebujesz przygotować i zaplanować napisanie tekstu 240 znaków?

Łukasz Kałużny: Teraz jest trochę więcej, ale odpowiednio szyderczego, żeby się przebił.

Szymon Warda: Dobrze, dobrze.

Łukasz Kałużny: Nie mam czasu, żeby… Właśnie to jest problem, że musi być to krótkie. Długi rzut tekstu to jest prostsza rzecz. Ale całość jest pokazana, wiesz, głupota tego, jak oni to robią, że nie patrzą w ogóle na realne potrzeby. Bo jest drugi tweet, który sobie tam leci z ekipy, która pisała tego Aspire: minęło już ponad 8 lat, kiedy pisałem prawdziwą aplikację, jestem szczęśliwy, że to tworzyłem. Pisał dashboard do tego Aspire. Takie moje przemyślenie tutaj po całości i będzie to cholernie niepopularna opinia dla niektórych, jeżeli chodzi o .NET-a, w .NET-cie brakuje podejścia, które mamy w Javie ze Spring Bootem np., że jest całe opinionated stuff przygotowany.

Szymon Warda: Teraz skontruję, ale w sumie taki Aspire jest taką próbą zopiniowanego stosu trochę.

Łukasz Kałużny: Zauważ tylko, że jest on od feature’ami, których nie ma w ogóle w Spring Boot’cie. Bo jeżeli teraz popatrzysz sobie kompleksowo na ekosystem .NET-a i tego co ma Microsoft od siebie ze stajni, zostawiając Microsoft + parę open source’owych bibliotek. Gdyby opakować te wszystkie poli, biblioteki do healthchecków, dorobić jeszcze tam parę innych bibliotek do konfiguracji, które masz w Microsoft Extension, wszystkie te rzeczy do feature flag. Masz tam przecież masę gotowych dobrych rzeczy, które zostaną opakowane wreszcie pod jedną wspólną nazwą, a nie rozproszone hen ho, dostaną jawną, ładną dokumentację pod jedną nazwą produktu. I tak jak masz w Spring Boot’cie, 3, 4 opinionated szablony, że wsadzasz tych juniorów javowych zobaczcie i oni mają od linijki, wiedzą jak to pisać.

Szymon Warda: Wiesz co, wydaje mi się, że problem w MS-ie jest inny. Problem w MS-ie jest taki, że de facto wiele narzędzi, nawet co wymieniłeś takich możliwości de facto, języka, runtime’u, itd., to jest jakaś tam integracja z Azure de facto. No i teraz problem jest taki, że nie wszyscy deploy’ują na Azure’a. .NET jest pewną formą jakiegoś tam marketingowego, żeby wcisnąć ludzi w ekosystem Microsoftowy, itd. Więc zbudowanie tego całego ekosystemu, to musiałby być biznesowo ekosystem zbudowany na Azure. A że to byłoby na Azure zbudowane, to w tym momencie to jest utrudnienie dla innych platform.

Łukasz Kałużny: Dobra i zobacz teraz taką jedną rzecz, jak o tym mówisz, bo tam ewidentnie strategia jest porozwalana, bo zobacz, że od Russinovicha ten projekt Radius, który też upadnie, bo upadnie, ale on zakłada multi Clouda, zakładał multi-clouda.

Szymon Warda: I dlatego padną właśnie.

Łukasz Kałużny: Tak. A tutaj w przypadku wiesz, jeżeli popatrzymy, dużo z tych bibliotek, które są, w ogóle nie zakładają Azure’a, więc raczej pozwalają zintegrować się z Azurem, ale równie dobrze wspierają on-prema. To jest taki mój punkt widzenia, że MS tym nakładem, którym próbował te badziewie pod tytułem Aspire wyprodukować, mógłby pod tym brandem zbudować, zebrać klocki i wynajmować biblioteki i zrobić pełnoprawnego Spring Boota w naprawdę szybkim czasie.

Szymon Warda: Pytanie jest takie, czy to im się opłaca finansowo i czy to by miało sens globalnie? Czy będą mieli odpowiednią ilość pieniędzy, żeby to rozhulać? Bo to muszą być pieniądze na developerów, itd., czas, żeby to działało poprawnie. Więc Aspire to jest taki..

Łukasz Kałużny: Side-project, który udało się przez sitko marketingu wstrzyknąć.

Szymon Warda: Możliwe. Dobra, to ja z czymś innym, trochę mniej aktualnym generalnie, ale to jest powrót do tego, co kiedyś omawialiśmy, framework dojrzałości organizacji. Kiedyś chyba polecieliśmy po łebkach, bo artykuł był trochę po łebkach, a znalazłem bardzo dobry artykuł. Jak go czytałem to dosłownie przegląd jak to wyglądało faktycznie i fajnie pokazuje poziomy dojrzałości organizacji ze względu na wydajność. Artykuł co prawda jest napisany jako wydajność frontendów tak naprawdę, ale jest na tyle generyczny, że jak się usunie to słowo frontend, to dalej to ma sens. I idziemy poziomami. Pierwszy, to jest bless, czyli generalnie problemu nie ma, brak świadomości i w ogóle wszystko jest super, tak naprawdę ignorujemy problem. Problem poziom drugi, to jest strażacy, czyli generalnie adresujemy problemy, jak one wystąpią, jest pełna panika i my nie mamy w ogóle żadnej kontroli nad tym, pali nam się pod tyłkiem, gasimy tylko punktowo. Brzmi znajomo, prawda?

Łukasz Kałużny: Dodam, to jest poziom rynkowy zazwyczaj.

Szymon Warda: Tak, ale w ogóle cały opis jest przefantastyczny, jak to wygląda. Poziom drugi, globalna baza i metryki. Czyli co robimy? Wprowadzamy globalne metryki, pierwsze adresowanie problemu. Spisujemy i propagujemy, jak sobie radzić z pewnymi problemami. Jest trochę lepiej de facto. Wprowadzamy narzędzia do monitorowania wydajności, ale zbieramy masę danych, po prostu zbieramy wszystko, co tylko można. Brzmi bardzo znajomo?

Łukasz Kałużny: Tak, wiesz co, tylko inaczej i większość rynku uważa, że jest to już dojrzały poziom.

Szymon Warda: Tak, ale teraz lecimy dalej, bo to jest taka piękna historia. Kolejny poziom, poziom trzeci, tzw. P75, czyli specyficzne metryki dla naszego przypadku. I tak, wprowadzamy własne metryki, które mają sens biznesowy. Strzał w piątkę. Dalej, świadomość, że średnia nie ma większego sensu. Tak, to po kolei pokazuje, jak to wygląda. Dalej, wprowadzamy precentyle w takim razie generalnie. Czyli już jest lepiej. Skupiamy się na przesuwaniu wydajności do konkretnych zakresów, czyli dzielimy sobie zakresy powiedzmy na te przedziały A B C D E i wprowadzamy cele. Dosłownie idealna historia, jak to mniej więcej wygląda. I teraz kolejny poziom, poziom czwarty, skupiamy się na kontrolowaniu i nagle zdajemy sobie sprawę, że de facto ten rozstrzał naszych wartości jest problemem tak naprawdę. Czyli skupiamy się na zmienności, wydajności tak naprawdę, czyli że ktoś ma, załóżmy, 50 milisekund, a czasami ma sekundę. Adresujemy to. Dalej, dodajemy bramki jakościowe do naszego procesu CI/CD, też brzmi znajomo. Badamy trend w czasie, czyli sprawdzamy. Interesuje nas nie tylko punktowe, tylko jak ta wydajność wyglądała, jak ona się rozwijała przez cały system de facto, przez nasz rozwój, itd. Koncentrujemy się nie na obecnej sytuacji, tylko na dłuższej perspektywie, jak to zrobić. Czyli mamy procesy…

Łukasz Kałużny: Strategic performance,to jest chyba określenie, to świetnie…

Szymon Warda: To jeszcze nie, strategic jest kolejnym de facto, bo na razie mamy jakiś tam trend i potem pojawia się zespół wydajnościowy. I teraz wchodzimy, poziom piąty, który nazywa się strategiczny, czyli to jest coś blisko. W tym momencie wydajność staje się elementem na poziomie już SI levelu. To coś, co istnieje jako problem, coś co istnieje, jako coś, do czego dążymy de facto. Mamy całą strategię jak sobie z tym radzić, itd., ogólnofirmową, dzielenie zespołem, propagujemy wiedzę. Czyli teraz to jest taki poziom organizacyjny. Czyli wprowadzamy, żeby wszyscy widzieli, żeby to był element, który po prostu istnieje. Czyli mamy strukturę do tego problemu. Dla mnie, jak czytałem ten artykuł, po prostu on jest długi dość tak naprawdę, świetne, świetne podejście do tego faktycznie jak to wygląda. I to jest takie, jak przejście tym takim frameworkiem do akceptowania śmierci czy innych rzeczy poważnych. To dosłownie punkt w punkt właściwie wchodzimy, jak to w organizacjach.

Łukasz Kałużny: Wiecie co? Ale ja z tego artykułu wyniosę coś innego. To jest artykuł dla szefa.

Szymon Warda: Tak, tak, to jest artykuł dla menedżerów, tak.

Łukasz Kałużny: Tak i to jest genialne. I słuchajcie, tam jest jeden paragraf, dwa paragrafy, które trzeba przeczytać, trzy paragrafy, dwa nagłówki. Jest The role of senior management, który to opisuje. I drugie, to jest dla osób, które gdzieś leadują technologią, to jest sposób postawienia pytań tym ludziom, są Question for senior managers.

Szymon Warda: Wiesz co, jeszcze jedna rzecz. W każdej z tych sekcji jeszcze jest fajny artykuł kiedy i czemu występuje regresja do poziomu wcześniejszego de facto. I to jest też bardzo fajna wartość. W sensie powiedzenie generalnie: my już jesteśmy na poziomie trzecim, to nie znaczy, że będziemy teraz awansowali tylko w górę, tylko może być taka sytuacja, że w tym momencie coś nawali i wrócimy np. do zerowego. Tak też może być. Naprawdę bardzo dobry artykuł. Długi, ale warty swojego czasu. To jest taki krótki wycinek tego, co tam jest, żeby Was zachęcić.

Łukasz Kałużny: Jest super i naprawdę, jeżeli widzicie u siebie problemy wydajnościowe i chcecie to posprzątać, to jest taki dobry sposób jak o tym rozmawiać i jak to zaplanować.

Szymon Warda: Nie tylko na menagerów, też od team leada, osoby, które chce wprowadzić zmianę.

Łukasz Kałużny: Tak, wprowadzić zmianę. Dlatego ja mówię, że to nie jest tylko dla menagera, ale dla każdej technicznej osoby, która ma jakiś wpływ, o tak, to jest istotny element. Dobra, następna ode mnie rzecz, to jest z Allegro.tech blogu, czyli lokalny tym razem: Beyond the code - an engineer’s battle against knowledge loss. I to jest tutaj, ładne jest odwołanie się kolejny raz do Conwaya i sposobu jak organizacja traci wiedzę.

Szymon Warda: A każda będzie traciła wiedzę.

Łukasz Kałużny: I tam są dwie rzeczy, takie dość fajnie metryki wskazane, które są, bo wiedza w organizacji jest plemienna.

Szymon Warda: Jak dokumentacji by nie było, to tyle, zawsze będzie jakaś tam plemienna część.

Łukasz Kałużny: Plemienna wiedza, tak. I tutaj są dwie rzeczy, które są, to jest time to problem resolution, wskazane jako taka metryka efektywności całych tych procesów. I druga, knowledge transfer rate, czyli ile czasu zajmie, żeby pracownik był po onboardingu, właśnie w ramach onboardingu, objęcia obowiązków, był samowystarczalny. I tutaj pada fajne bardzo stwierdzenie, to jest z jednej z książek, organizacja nie ma pamięci, które przepięknie to podsumowuje, jak popatrzymy. Bo te pamięci są punktowe.

Szymon Warda: Raczej organizacja ma pamięć, ale ta pamięć jednak się wygasza po prostu. To nie jest tak, że ona jest nabyta na zawsze tak naprawdę, według mnie przynajmniej. Nie, bo jak ktoś odejdzie, to ta wiedza jeszcze jakoś jest, ale potem po prostu ginie. Tak samo jak nasze umiejętności, z których nie korzystamy, to się niczym nie będzie różniło.

Łukasz Kałużny: Tak i tutaj jest… Opis, nie będę teraz referował już całości, bo też jest kawałek. On już nie jest aż tak długi, ale jest trochę mięsa. I jest tutaj popatrzenie też, że tych narzędzi będzie zawsze problem i alternatywy do długiej dokumentacji, co z tym zrobić.

Szymon Warda: Trzeba się pogodzić, że to nie jest tak, że ile byśmy dokumentacji nie napisali, to coś tam ucieknie. To w ogóle jest nierealne, żeby było inaczej.

Łukasz Kałużny: Tak, jedna rzecz tutaj, nie będę teraz już wchodził o dyskusję, tu jest też o event streamingu. Tak jak z Mariuszem rozmawialiśmy, to jest świetne narzędzie, odkrywcze, modelujące, ale nie jest to stała dokumentacja.

Szymon Warda: To jest też tak, że to jest narzędzie propagujące wiedzę i mieszające, i weryfikujące to, co się dzieje w organizacji. Super.

Łukasz Kałużny: Ale wpis jest, całość, jest dobry. Tutaj jest taka rzecz, która, jak ja teraz patrzę na różne rzeczy, jeżeli chodzi o modelowanie samych systemów, czy przypadkiem robienie UML-a, z powrotem używanie UML-ów, notacji BPMN-owych, tych wszystkich, nie jest dobrą rzeczą. Tylko robienie tego właściwie nie na poziomie kodu, nie na poziomie kodu, tylko tam, gdzie zostało to przeznaczone.

Szymon Warda: Dla mnie ona jest w zbyt sformalizowanej, przez co ludzie będą jej mniej chętnie albo błędnie używać. Więc tak…

Łukasz Kałużny: Ja wiem, że tak, tylko że ona, wiesz, oddaje… Inaczej, jeżeli modelujemy use case’y i inne rzeczy w tych Enterprise Architectach i innych takich rozwiązaniach, utrzymywanie tam, wersjonowanie, utrzymywanie tego, wiesz o tym, że to daje radę, jeżeli masz osoby, które umieją to utrzymywać.

Szymon Warda: Łukasz, po prostu chyba się starzejesz. Enterprise Architect zaczyna się podobać.

Łukasz Kałużny: Nie, mi się nigdy… Inaczej, jak masz osoby od tego… Jak masz. Ja sam tego nienawidzę, tych diagramów, nienawidzę dotykać Enterprise Architecta, ale mam szacunek dla osób, które potrafią tam zamodelować. Zresztą pracowaliśmy z dwoma kolegami, którzy potrafili pięknie to zrobić. Jak trzeba było wygenerować dokumentację to prawy klik, macie tu świeżą dokumentację z tego całą.

Szymon Warda: Tak, świeżą, może niekoniecznie aktualną. Dobrze. Wpis od Pragmatic Engineer, też długi, jak zwykle u niego i w miarę konkretny. Jest to porównanie jak AWS, Azure i GCP informują o awariach. I to jest porównanie jak oni, jako organizacja, się zachowują. Ale nie to chciałbym przekazać jako esencję tego artykułu, bo cały wpis to jest trochę streszczenie, można wyłapać kilka dobrych praktyk de facto i chciałbym się na nich skupić, jak to wygląda. Jedna rzecz, najważniejsza, przypomniał mi się jeden z moich szefów, co zawsze powtarzał, to jest to, że przypadku awarii i w ogóle wszystkiego, co aktualnie się dzieje, to jest bazowa mantra - komunikacja jest ważniejsza niż informacja. Czyli generalnie podstawa to jest po prostu informowanie, co się dzieje, nawet jeżeli nie ma nic nowego. Znaczy, że się coś dzieje, że problem jest niezapomniany generalnie. I teraz co lecimy? Dobrych praktyk. Publikowanie osi czasu, czyli co się wydarzyło, kiedy, konkretne daty, żeby to w miarę wyglądało i można było to umieścić w czasie. Szablon pytań do post-mortem, czyli określenia po awarii czemu wystąpiła. Pytania - co się wydarzyło? Co poszło nie tak, że się popsuło? Jak zareagowaliśmy? Co robimy, żeby takie zdarzenia albo były rzadsze, albo miały mniejszy wpływ? I pytanie ostatnie, to będzie triki, ale w sumie sensowne bardzo - co klienci mogą zrobić, żeby tego typu awarie miały mniejszy wpływ na nich?

Łukasz Kałużny: I wiesz co? I to jest bardzo ważne. To jest pytanie dla ludzi, którzy dostarczają platformę, jakiegoś clouda, usługę, a nie aplikację.

Szymon Warda: Tak, tak, tak to jest platforma. Ale ruszyć temat. To też się tyczy trochę platformy wewnętrznej, bo to też mogą być awarie…

Łukasz Kałużny: Dlatego użyłem słowa “platforma”, bo czy to jest IDP, czy platforma chmurowa, czy cokolwiek, jeżeli dostarczamy coś jako usługę do odpalania i budowy innych usług, to jest miejsce, żeby odpowiedzieć na to. Więc 99% społeczeństwa może te pytanie wyrzucić z takiej części.

Szymon Warda: Tak, ale jednak te platformy mają coraz większą adopcję, więc zobaczymy jak to będzie wyglądało. Ale idźmy dalej takimi dobrymi rzeczami. Q&A w formie video jako post-mortem. Po prostu czasami ludzie lubią to obejrzeć, więc to jest niezłe. Kolejna rzecz dobra wyszła, publikowanie wstępnego raportu i publikowanie pełnego raportu i już dużo, dużo później. Daje to możliwość, że mamy informację co się mniej więcej wydarzyło, co się nam wydaje, a dokładny, pełny raport jest dużo, dużo później. Czyli kupujemy sobie czas po prostu. Ale teraz jeszcze taki, powiedziałem, że niby nie będę porównywał organizacji, ale jednak parę ciekawostek wyszło. Najfajniejsze to jest, że GCP trzyma dwie zony w jednym regionie, z takich ciekawostek.

Łukasz Kałużny: Tak, albo nawet trzy. Raczej tak, w grupie Datacenter, że fizycznie, a w ability zone jest w jednym miejscu. Paryż tak zalało.

Szymon Warda: Azure ogarnął cały incydent. Faktycznie to ładnie im wyszło. GCP zapewniło najbardziej szczegółowy raport, ale zajęło mi to najdłużej. AWS nie opublikował żadnego raportu przez dwa miesiące. Dopiero jak ich practical engineer dopiero wypuścili na dzień kolejny. Czyli AWS, jak to AWS, uważa, że jest najmądrzejszy i może mieć wywalone na wszystkich.

Łukasz Kałużny: Wiesz co i tak z tymi kto jak publikuje. I teraz jest takie pytanie. Bo jak widzisz, post-mortem do setki małych outage’y na poziomie kawałka usługi w jednym regionie…

Szymon Warda: To nie ma aż takiego sensu.

Łukasz Kałużny: Właśnie, nie ma sensu, bo tam jest dobre porównanie, ilość incydentów opublikowanych post-mortem w 2023 - AWS ma jedno, Azure ma 15, Google Cloud ma 100. Patrząc na skalę, ci pierwsi fuck-upów, jakbyśmy przejrzeli Twittera, tam konta supportowe i inne rzeczy, gdzie są oznaczeni dostawcy cloudowi, to pewnie zliczylibyśmy, że wszyscy mają na tym samym poziomie.

Szymon Warda: Jest to bardzo możliwe, to są wszystko o dojrzałych organizacjach.

Łukasz Kałużny: Tak. Więc przy tej skali tam lecą, takich samych delikatnych incydentów dziennie lecą setki, które dotykają pojedynczych klientów. I pytanie - jak to się potem rozkłada? Dlatego ta liczba opublikowanych, trzeba się zastanowić, np. Google Cloud, dla mnie to jest w tym wypadku troszeczkę antyprzykład, bo robią tego za dużo.

Szymon Warda: Tak, to jest trochę sporo. Wydaje mi się, że to też trochę może wynikać z tego, że oni dalej próbują się przebić tak naprawdę. Oni dalej są w tym elemencie przebijania się przez tą chmurę. Dla mnie tak, porównywanie w tym momencie dostawców chmurowych po ilości raportów, czy jak reagują, nie ma większego sensu. Wartość tego artykułu to są te punkty właśnie, co można ewentualnie wziąć do siebie. Takie właśnie proste, które potencjalnie, jeżeli byśmy chcieli nawet jakiś super prosty post-mortem robić, to nawet te pytania, tego typu rzeczy dają nam pewną strukturę i mamy punkt startu do zrobienia tego samodzielnie. I to ma wartość tego artykułu. Reszta ok, nie musimy być aż tak Enterprise.

Łukasz Kałużny: Wiesz co, ja sobie tylko zaszydzę, bo pewnie w odcinku za tydzień już będzie przegląd nowości z re:Inventu AWS-owego. A wpadło mi teraz jedno do głowy czemu nie publikują tyle post-mortem? Bo ile to można pisać o istuest 1?

Szymon Warda: Robi się powtarzalne potem.

Łukasz Kałużny: Tak, być może to jest powód zupełnie czysto marketingowy.

Szymon Warda: Raczej AWS ma podejście takie konkretne do pewnych rzeczy. Dobrze, co tam jeszcze Łukaszu masz?

Łukasz Kałużny: Wiesz co, to u mnie ostatni link na dzisiaj, jest CNCF-owy white paper na temat platform. Czyli po co są platformy, dlaczego? Jest też wspomniana dojrzałość, to jest dobra rzecz, jest wspomniana też właśnie, że to jest potrzebna dojrzałość. I są elementy, albo raczej atrybuty platform opisane. Więc całość, jeżeli ktoś zastanawia się na temat czym jest platforma w ogóle, jak to wygląda. I dobrą rzeczą, co mi się spodobało, są możliwości platformy w postaci jednego rysunku i jest to świetnie pokazane, co powinna dostarczać platforma. I w ramach platformy interfejsów, pierwsze dwie rzeczy, które są pokazane tak głównie, to jest dokumentacja i template’y projektów.

Szymon Warda: Mi tu brakuje jednej rzeczy. Brakuje mi narzędzia CI/CD, bo ja będę się upierał przy tym, że narzędzie CI/CD jest interfejsem do platformy i chyba najczęściej wykorzystywanym.

Łukasz Kałużny: Raczej tak, to będzie, wiesz… Więc te interfejsy, tak, powinna być w interfejsie, bo masz automated build test and delivery i to jest funkcjonalność platformy, ale często będzie interfejsem.

Szymon Warda: Żeby doszczegółowić. Nie chodzi o to, że samo narzędzie CI/CD, ale workflow, który tam wystawiamy, akcje, które wystawiamy, template’y, które tam wystawiamy, to są wszystko sposoby na interakcję de facto z platformą.

Łukasz Kałużny: I teraz jest pytanie, bo tutaj masz web portals. Zobacz, że tu nie masz żadnego, że masz internal developer portal, czy coś tego, tylko masz web portals, API and CLIs.

Szymon Warda: Czyli co, stwierdzamy, że nie zaczynam od backstage’a, od dnia zero?

Łukasz Kałużny: Zobacz - web portals for observing and provisioning products and capabilities. Czyli nie musisz mieć backstage’a.

Szymon Warda: Ojejku, w końcu doszliśmy do tego.

Łukasz Kałużny: Raczej zobacz, że jest zdroworozsądkowo, nikt tu nie mówi: piękny self-service portal i inne takie elementy, tylko web portale, w liczbie mnogiej.

Szymon Warda: Tak, że w ogóle ta lista co jest, np. jaka będzie dokumentacja, jaka będzie automatyzacja - dobry wpis. Faktycznie ładnie jest to ułożone bardzo.

Łukasz Kałużny: Tak i tam potem jeszcze, jak zobaczymy, mamy Platform Engineering Maturity Model w ramach tego, wszystkie właśnie te aspekty. Mamy słownik, to jest bardzo fajne, jest zrobiony cały słownik pojęć, jest ich jeszcze mało. Jest pojęcie, to co zresztą teraz mówiliśmy, z możliwościami Platformy, czyli tutaj… Oczywiście nikt nie mógł zrobić, wpisać MVP, bo w team topology zostało wymyślone tajne z [niesłyszalne 00:22:05] Platform, żeby nie mówić MVP, TVP. Ale jest to samo, więc jest świetny. Dla mnie Jedną rzeczą, którą stąd wyciągnąłem, z tego wpisu patrząc się na całość, to jest Golden Paf w postaci template’ów i dokumentacji.

Szymon Warda: Teraz zwróciłem uwagę.

Łukasz Kałużny: Że to jest rzecz, którą w sumie mówimy o tym, ale jest bardzo ładnie nazwana.

Szymon Warda: A to ja jeszcze dorzucę całkiem fajne w kontekście tego, jakby ktoś chciał zobaczyć mniej więcej jak ten rynek wygląda. Mi się też podoba, że dołączyli tabelkę, w sensie umiejętność, co to robi i przykładowe projekty CNCF-u, które pokrywają tą umiejętność. Fajna opcja, bo zaoszczędza googlania, alternatyw i po prostu widzimy jak i co wziąć.

Łukasz Kałużny: Patrząc się, są też projekty nie CNCF-owe. Tak jak widzę masz tutaj Jenkinsa.

Szymon Warda: Ale też, tak, Jenkins jest, masz rację, zauważyłem. Tym lepiej tak naprawdę, że nie ograniczyli się tylko do CNCF-u. Także tak, fajna lista i dobry punkt startowy, żeby zrozumieć co i jak i z przełożeniem na realne produkty, nie tylko taki high level, który mówi o czymś co nie ma odniesienia na realne rzeczy.

Łukasz Kałużny: Dobra, co u Ciebie na koniec Szymonie?

Szymon Warda: Ja mam dwa wpisy. Ale takie pytanie, bo to jest coś, co ruszaliśmy jakiś czas temu i był fajny wpis, który trochę może zmienił moje zdanie, albo może uświadomił mi generalnie, że tak będzie. Pytanie takie, czy zdalne środowiska developerskie mają sens? Albo może inaczej, czy nas to czeka finalnie?

Łukasz Kałużny: Finalnie. Dobra, to moja odpowiedź jest bardzo prosta - to już tam, gdzie się miało przyjąć, to się przyjęło. Zobacz, że to jest bardzo ważna rzecz. Trochę firm zbudowało takie własne rzeczy na własne potrzeby. Czyli w Googlu, wewnątrz zbudowali. Tam nie masz kodu już lokalnie na swojej stacji ze względów bezpieczeństwa, wydajności całości. Ja np. przesiadłem się w całości np. ze swojego sprzętu jakiegokolwiek, nie mam lokalnie żadnych narzędzi developerskich, żadnych, tylko wszystko leci u mnie w GitHubie na codespaces.

Szymon Warda: Ale po prostu absolutnie nie jesteś developerem, więc to by się zgadzało. Cieszy mnie bardzo, że już nie developujesz, bo…

Łukasz Kałużny: Ty też już jesteś mało developerem, więc…

Szymon Warda: No tak. Ale właśnie ja bym się z tym nie zgodził, co Ty mówisz, bo wydaje mi się, że czeka nas to globalnie wszystkich. I teraz czemu? Tam były fajne, całkiem ciekawe punkty. Przede wszystkim wiele rep się nie sprawdza i wracamy do mono rep. Wydaje mi się, że to jest taki standard generalnie. Wracamy do zbierania tych wszystkich rep jednego worka de facto.

Łukasz Kałużny: I wchodzimy teraz, że większość developerów, przepraszam Was, jeżeli ktoś będzie czuł się oburzony, nie potrafi pracować w trunk based developmencie.

Szymon Warda: Potrafimy, nie potrafimy, ale generalnie posiadanie kodu w 30 repach do jednego systemu nie ma większego sensu. To już ustaliliśmy, że to jest zbyt dużo roboty. I teraz tak, wzrost wydajności maszyn, a szczególnie laptopów, bo już mało kto pracuje na desktopach, się wypłaszcza. Tam trochę Ryzen zamieszał, ale generalnie ten przyrost wydajnościowy już nie jest taki absurdalnie wręcz wielki. Kolejna, popularność chmury i jej dostępność, większa ilość datacenter i bliskość, czy też atencja idzie nam w dół, znacząco idzie w dół. Kolejna opcja to jest to, że to jest przerzucenie środowisk do zdalnych, przeniesienie np. do chmury, to jest super łatwy sposób na podniesienie wydajności de facto tych komputerów, bo to jest jeden klik i mamy. To jest dużo większa elastyczność. Kto może mieć jaką maszynę. Dużo większe tak naprawdę. Internet mamy już na tyle szybki, że to też jest rabialne de facto. A kolejne, ten atrybut jest fajny, czy my naprawdę wykorzystujmy te nasze maszyny tak ciągle, te 24h, 8, czy jakiekolwiek?

Łukasz Kałużny: Nie.

Szymon Warda: Więc właśnie, dochodzi nam tu opcja skalowania tego. Nie musisz kupować jakichś potworów de facto lokalnych, które i tak się czasami nudzą, bo siedzimy na spotkaniach i po prostu nic się nie dzieje. Argument kolejny, wycieki kodu, kontrolowanie tego i w ogóle cały governance jeżeli chodzi o dane bankowe, itd. Dużo firm dalej ma podejście takie, że lokalnie powinniśmy mieć administratora. Co jakiś tam sens ma, jest nierealne z racji na jakieś tam, jak wg jest developowane, jak ten development wygląda. Ale mimo wszystko wracamy do tego kontrolowania, pilnowania, nawet w zakresie big techu i nawet w zakresie mniejszych firm, że te dane po prostu wyciekają i co chwilę widzimy, że ktoś gdzieś wziął kod i nagle ruszył z własnym startupem, prawda? Lokalnie kontrolowanie jest tego ciężkie, rabialne, ale ciężkie. Zdalnie, super proste - po prostu nie skopiujesz. Takie rzeczy właśnie jak masz codespace’y, jak Visual Studio Code Server, itd., to po prostu się dzieje. I ostatni element. Pamiętasz? Chyba rok temu mniej więcej mieliśmy odcinek, w którym mówiliśmy o metrykach mierzenia wydajności developmentu, developerów, ale w kontekście tego jak pomóc deweloperom, w sensie jak zoptymalizować sprzęt, pobieranie kodu, metryki i na to zużywany jest czas pracy developera w kontekście buildu, pobierania paczek, itd. To jest super do optymalizacji właśnie przy zdalnych środowiskach.

Łukasz Kałużny: Tak. Ja bym dorzucił takie dwie rzeczy, które wiesz, jak teraz po całości sobie popatrzymy, bo niektórych skręca jak mówimy o VS Code jako IDE, to też trzeba pamiętać, że mamy do tego pełnego wizuala, czy mamy JetBrainsy, które np. z takim codespaces też się integrują, więc tutaj mamy cały przegląd narzędzi. To jest jedna rzecz. A dwa, drugie benefity. Jeden powiedziałeś o onboardingu i to jest przypadek GitHuba, który pokazuje, że wymusił… Development GitHuba odbywa się na GitHub CodeSpaces z tego względu, że tak jak dostajemy definicję w projekcie, wrzucamy sobie definicje, jak ma wyglądać nasze środowisko deweloperskie jeżeli chodzi o zainstalowany runtime, inne takie rzeczy. Czyli możemy w jednym dla wszystkich wziąć i te środowisko do developmentu zrobić dokładnie takie same. Wszyscy wiemy jak wyglądają instrukcje onboardingowe, jak odpalić development lokalnie naszego systemu. I jest to update’owane. Jeżeli dobrze pójdzie, osoba, która przychodzi, jest onboardowana, zdobywa wiedzę plemienną jak skonfigurować swoją stację, ponieważ to co jest już tam na Confluence jakimś jest nieaktualne.

Szymon Warda: Tak, dlatego właśnie wydaje mi się, że to nas czeka i że to nie jest aż taka zła sytuacja. Naprawdę to może być sensowne. Wracamy do tego, że będziemy proponowali w terminalach coś, co się działo w latach 60. de facto, więc pełna sinusoida.

Łukasz Kałużny: To taka sneak peek z rzeczy, które zauważyłem na re:Invencie. Tam wrzucę do tego linka. Pojawił się zdalny terminal do AWS Work Spaces, taka malutka ARM-owa kosteczka do podłączania do monitora. Czy gdyby wziąć Samsung ma DeX-y, ja na tym przez chwilę próbowałem sobie kiedyś coś tam, w pewnym momencie w jednej firmie dostałem, bo musiałem dostać telefon od nich też, pomińmy to, nie było sensu. Ale z ciekawości, miał firmowego VPN-a i miał RDP-a i przeglądarkę. Z ciekawości podłączyłem go sobie przez USB-C do monitora, który ma też stację dokującą. I słuchaj. Z telefonu de facto dało się wejść na stację, którą miałem i pracować z telefonu, jak zapomniałem ze sobą zabrać tego laptopa, tego klienta, więc…

Szymon Warda: Dlatego to nie jest aż taka tragedia de facto. Czekaj, to może być całkiem sensowne.

Łukasz Kałużny: Ja dodam jeden plus tutaj, taki bardzo duży, z mojej perspektywy. Jeżeli ktoś pracuje z wieloma projektami, to nie ma żadnego problemu. Właśnie dlatego ja powiedziałem, że nie mam u siebie żadnych narzędzi, bo czasami niezgodność wersji innych rzeczy, bibliotek, to jest po prostu… Inaczej, we wszystkim trzymanie już virtual environments na poziomie systemu operacyjnego, to zaczyna się robić wrzód na tyłku. Prościej byłoby po prostu odpalić sobie konfigurację takiego zdalnego desktopa.

Szymon Warda: Może to nie być aż taka zła przyszłość, jaką zakładałem, że może być. Dobra, kończymy, chyba tyle.

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

Szymon Warda: Trzymajcie się. Hej!