Ł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/68. Łukaszu, co masz?.

Łukasz Kałużny: Dobra, dzisiaj artykuł z InfoQ na temat prostego frameworka do decyzji architektonicznych i nazwa… Jak zawsze prosty… Jest trochę zła, bo pokazuje bardzo techniki, które potrafią być bardzo zaawansowane.

Szymon Warda: Ale też nie wiem, czy nazywałbym to frameworkiem de facto. Bo wszystko dzisiaj nazywamy frameworkiem. Guidelinesy…

Łukasz Kałużny: Tak, właśnie wytyczne, wytyczne będą dobrą rzeczą. No więc pierwszą rzeczą, którą jest OK, to jest w kontekście naszej firmy zbudowanie swojego własnego technology radara. Technologii, których używamy, chcemy używać albo których unikamy, jego utrzymywanie.

Szymon Warda: Nazwałeś to technology radarem, to się od razu kojarzy z całym przeglądem rynkowym itd.

Łukasz Kałużny: Tak, bo stąd się wzięła ta nazwa. Ale de facto to jest technology radar…

Szymon Warda: To są standardy po prostu.

Łukasz Kałużny: Tak, to są standardy, standardy, tylko że pokazane w rzekomo najprostszy sposób.

Szymon Warda: To jest tak, bo są standardy i roadmapa, które rzeczy sprawdzimy, które wygasimy.

Łukasz Kałużny: Tak dokładnie.

Szymon Warda: I które będziemy wdrażali. To jest po prostu roadmapa technologiczna, de facto.

Łukasz Kałużny: Tak, pokazana w formie radaru.

Szymon Warda: Tak, tak, tak. Kółeczka.

Łukasz Kałużny: Tak, chyba najsłynniejszym takim jest w ogóle do tego np. jeżeli ktoś chciałby sobie sprawdzić, to najsłynniejszy taki jest open source od tego od Zalando. Zalando swój techradar ma online-owo publikuje na przykład. I oni mają też podział, bo podział tego to jest w zależności od tego co potrzebujemy. I Zalando np. w swoim tech radarze posiada data story, data management, infrastructure i languages.

Szymon Warda: Bardzo dobry podział muszę powiedzieć, bo nie wiem czy w ramach organizacji firmy wchodziłbym w pozostałe załóżmy tak jak robi to ThoughtWorks.

Łukasz Kałużny: Tak dokładnie. Więc raczej sam tech radar jest bardzo fajnym pomysłem, tylko trzeba to zrobić, właśnie dostosować to do siebie. I też można potem co miesiąc w dość ciekawy sposób pokazać mapę graficzną tego jak to się zmienia, jakie mamy podejścia i w prosty sposób przekazać innym na czym pracujemy. Jeżeli standaryzujemy. I właśnie ta standaryzacja jest następną częścią tego frameworka. Czyli tutaj jest założenie, że Technology Radar łapie nam te techniki i adaptowanie tego. Ale druga rzecz to są standardy technologiczne. Czyli de facto jeżeli popatrzymy, wystandaryzowanie rzeczy, w jaki sposób budujemy w firmie, podchodzimy do tego. Takie najszybsze standardy to jest standard, jaką będą miały wiadomości albo jak będą wyglądały logi, czy w jakim stylu będziemy tworzyć nasze Restfule, GraphQLe czy inne rzeczy.

Szymon Warda: Nie wiem dlaczego Łukasz, chcesz powiedzieć, że nie jest tak, że każdy zespół tworzy osobny mikroserwis w innej technologii z innymi standardami. Tak, tak, tak nie robimy?

Łukasz Kałużny: No właśnie tak nie robimy.

Szymon Warda: Cholera! Ale nie. Tak już mówiąc bardzo poważnie, cieszy mnie, że w końcu do tego dojrzeliśmy. Że jednak to nie jest tak, że każdy osobno i jest potrzeba ustandaryzowania, bo koszt utrzymania, potem tego, koszt zbudowania to jest proste, to jest 20%. Koszt utrzymania, to z reguły 80% całego kosztu systemów. Więc to musi być ustandaryzowane po prostu.

Łukasz Kałużny: Tak. I dobrym przykładem… a raczej przykładem, może inaczej - rzeczą, w której można wyjść jak napisać sobie takie… Bo zawsze jest problem. Jak ja mam napisać te wytyczne? Standard. To jest rzecz bolesna. To jest proces bolesny. Oprócz ChataGPT, z którego się zaraz ponabijamy, którego można zastosować do takich rzeczy, jest sobie RFC 7990, czyli jest to de facto RFC Format framework. W jaki sposób pisać właśnie jako taki startowy przykład… Jak pisać standardy? Więc to jest rzecz warta zobaczenia. I ostatnią rzeczą, którą już mocno omawialiśmy mamy cały odcinek lata temu nagrane. Są to ADR, Architecture Decision Record. I tutaj sprawa jest prosta. Czyli jest bardzo fajnie napisane, żebyś zaadoptował praktykę, zaadoptował praktykę. I dla skrótu którego… Czym są ADRy? Są to… Zapisanie naszego logu decyzyjnego. Dlaczego podjęliśmy taką a nie inną decyzję architektoniczną w naszym projekcie, rozwiązaniu, założeniach, technologii - tam od strony implementacji polecane jest po prostu stosowanie pull requestów w Waszych repo, ewentualnie confluence’a i całość… Mówimy sobie, co, jaki problem mieliśmy do rozwiązania, co zmusiło nas do tego, że zaczęliśmy na coś się decydować, jakie mieliśmy opcje na stole, jakie były plusy i ich minusy, jakie konsekwencje, co będziemy musieli zrobić. De facto taki log decyzyjny, spisanie na papierze, czemu podjęliśmy taką, a nie inną decyzję.

Łukasz Kałużny: I na koniec dnia ona ma odpowiadać na pytanie, bo - przepraszam za to określenie - kto Wam tak to spierdolił, albo czemu to tak spierdoliliście. To ADR ma odpowiadać na to pytanie, że w tamtym momencie w czasie, na naszą wiedzę, na to, co się skonsultowaliśmy. Ten wybór był ok. I doszliśmy do tego, że on już nie działa i to jest ok, żeby go zmienić, ale on ma pokazać historycznie o co w tym chodzi.

Szymon Warda: Mi… Raczej ja bym dodał jeszcze jedną rzecz, super ważną w kontekście ADRu, w kontekście właśnie radarów itd. I standaryzacji, bo jest duże bardzo ryzyko, że to wszystko powstanie sobie w takiej Ivory Tower zupełnie osobnej wiedzy. A obecna rola architekta to często jest de facto zaangażowanie wszystkich ludzi - znaczy wszystkich ludzi, części ludzi w firmie, z reguły decyzyjnych team leaderów i pozostałych, innych architektów. I tak naprawdę kooperacja i ustalenie wspólnej wersji rzeczywistości tak naprawdę. Ponieważ sporo z tych rzeczy de facto powstaje w formie tekstowej. Dla mnie super ważne jest, żeby te rzeczy powstawały jako PRy, żeby była kolaboracja, żeby był cały proces, jak mamy przy PRach, bo niestety publikowanie takich rzeczy przez jedną osobę bez konsultacji, bez elementu, nazwijmy to, nazwijmy to tak po angielsku się nie uda, bo to będzie narzucanie. Wszystkie te rzeczy umożliwiają ładną dyskusję co jak gdzie wyjdzie, bo opublikowanie to jest opublikowanie gdzie chcemy być i jak to będzie wyglądało, a nie powiedzenie jak to jest po prostu.

Łukasz Kałużny: Tak, jak to jest. W ogóle wiesz, z całością jest to, co poruszyłeś, to jest właśnie wprowadzanie i to jest dziedzina całego governance’u de facto, czyli kiedy wychodzimy z poziomu architektury oprogramowania i zaczynamy się patrzeć na to spójnie jako architektura IT. I to jest problem de facto właśnie wtedy zaczyna się pojawiać problem, że dopiero dostrzegamy to, co powiedziałeś, potrzebę, że jednak to trzeba zakomunikować, dograć to, żeby wszyscy byli zgodni i potem monitorować wykorzystanie tego i odstępstwa.

Szymon Warda: Tak, dokładnie, fajnie powiedziałeś. Bo Governance daje nam możliwość takiego wymuszenia standardu, który ustaliliśmy de facto. Ale zanim zaczniemy wymuszać, musimy też przestawić ludziom, co będziemy wymuszać, zakładać w jakiejś perspektywie czasowej, to jest super ważne.

Łukasz Kałużny: Ja też ze swojego doświadczenia, które miałem np. w mBanku, czasami musisz po prostu… Te wymuszenia są potrzebne, ale musisz wykonać dość dużą edukację, czyli możesz zrobić coś samodzielnie. Jeżeli naprawdę jesteś w stanie wyedukować dlaczego ich w ten sposób nie skrzywdzisz.

Szymon Warda: Tak, wytłumaczenie decyzji powoduje dużo mniejszą frustrację i ludzie łatwiej zrozumieją, czemu ona była podjęta i będzie mniejszy opór wewnętrzny. Mówiąc prosto: załóżmy, jeżeli wygaszamy jakąkolwiek bibliotekę, takie rzeczy też można robić - albo wygaszamy etapy logowania, metryk, czegokolwiek tak globalnie. To jest dodatkowa praca zespołów wytwórczych, deweloperskich i przez to de facto rozwalamy im trochę roadmapę, więc też muszą wiedzieć czemu nagle takie zmiany muszą zrobić.

Łukasz Kałużny: Albo takie standaryzacje, takie przejścia i całość bym powiedział, że i te rzeczy są… Tak, to jest takie właśnie… Nie nazwałbym tego właśnie prostym frameworkiem decyzyjnym, tylko de facto podstawą… Startowym governance przy wytwarzaniu oprogramowania, ale w kontekście organizacji, a nie pojedynczego projektu. I z tą praktyką nie wiem, jak Ty… Praktyka ADRowa to jest rzecz, którą da się zacząć robić od strzała, robić potem technology radar jako taką następną rzeczą i standardy to jest taka rzecz jednak końcowa, bo jest ona najcięższa, żeby zrobić ją w dobry sposób, mamy prawdziwą standaryzację, wytyczne.

Szymon Warda: Tak, bo problem jest taki jak ja widzę. To jest to, że łatwo jest to zrobić raz, gorzej potem to utrzymać. Bardzo łatwą pokusą jest to, że ona zabije pewną innowacyjność albo że ludzie zobaczą OK, standard jest… Powstał jakiś czas temu i potem zaczną go olewać, bo coś nowego weszło a nikomu się nie chciało tego zaktualizować. Więc zacząć jest prosto, utrzymać jest dużo trudniej.

Łukasz Kałużny: Wiesz co? To jest troszeczkę jak z Open Close Principle w solidzie. To jest ta filozofia. Trochę otwarte, zamknięte, czyli zamknięte na modyfikacje, otwarte na rozszerzenie to jest takie… Dobrze wskazuje to.

Szymon Warda: Czyli co ja praktykuję, to jest to, że z reguły piszę dokument, który jest taką konstytucją bardzo, bardzo high levelowy. On mówi co, gdzie chcemy być, a potem są dokumenty, które precyzują de facto, które precyzują.

Łukasz Kałużny: Czyli zaczynamy od… Wychodzimy od wytycznych, które dopiero potem w życiu można - jak się sprawdzą, można zacząć przebudowywać na standardy.

Szymon Warda: Ja bym powiedział inaczej, od celów, co chcemy osiągnąć generalnie jako organizacja w formie procesów technologicznych, że chcemy mieć performance testy i potem dopiero z tym dokumentem precyzujemy, jak one mają wyglądać. Potem dalej precyzujemy w dół, od ogółu, do szczegółu.

Łukasz Kałużny: Dobra, to teraz co Ty wykopałeś, Szymonie? W tym tygodniu.

Szymon Warda: Ja wykopałem trzy rzeczy. Tak naprawdę jeden artykuł, który przyznaję, że zrobił na mnie spore wrażenie jest odnośnie testów A/B tak naprawdę. Czyli jeżeli mamy testy na produkcji, że mamy testy online’owe. Problem jest taki jak one powinny wyglądać, bo mamy strumień danych powiedzmy - danych, czyli wyników tych testów. I problem pozostaje taki kiedy test zatrzymać? I jak tunelować do tych użytkowników czy jak te wyniki zbierać i tak dalej. To wszystko się ładnie nazywa sequential testing i nie mam alternatywy… to jest chyba testowanie sekwencyjne na wersji polskiej nawet na Wikipedii nie istnieje. Generalnie do wersji polskiej. Spotify wrzucił właśnie artykuł opisujący wszystkie frameworki, tylko frameworki pod względem matematycznym i statystycznym. Jak podchodzić właśnie do testowania? A/B na produkcji live. Bardzo długi artykuł, niełatwy artykuł. Nie jest to artykuł bardzo developerski. Zdecydowanie jest dużo bardziej statystyczny. Wrzucam go, bo jeżeli ktoś będzie miał potrzebę testowania A/B, to nie widziałem innego wpisu, który byłby lepszy. Jest naprawdę, naprawdę dobry, ale pewnie z pomocą kolegi matematyka trzeba by do niego podejść.

Łukasz Kałużny: Tak, jeżeli ktoś nienawidzi statystyki, to…

Szymon Warda: Ale fajnie uporządkowuje, raczej jeżeli jest potrzeba testów A/B to nie jest taki prosty temat że a wrzucę sobie i będę patrzył na wyniki - to musi do tego być podejście jakieś takie sensowne, bo może okazać się, że testy A/B nagle nam obniżą inne parametry i mogą być też niewypałem. To też nie zawsze są wielkie sukcesy. Pamiętajmy o tym. Więc nie najlepiej. Drugi link z serii “Małe rzeczy, które cieszą”… Passwordless deployment do chmury od githuba, dokładnie github actions. Czyli…

Łukasz Kałużny: Wiesz co, to jest ten, de facto… Jak popatrzymy, to jest Workload Identity.

Szymon Warda: To nie jest nic absolutnie nowego, ale cieszy mnie to, że de facto to zarządzanie tym użytkownikiem, że… Bo to jest z “małych rzeczy, które cieszą”, czyli że nie mamy jakiejś tam użytkownika i hasła w githubie…

Łukasz Kałużny: Wróćmy do tego, co to jest? Czyli, że spinamy w naszym providerze cloudowym, czyli np. Azure ADF, AWS IAMie, czy w google’owym OpenID. Wskazujemy, że tokeny pochodzące z tego konkretnego repozytorium właśnie z workerów są zautoryzowane w naszej chmurze i przypinają się do jakiejś tożsamości.

Szymon Warda: Tak, dokładnie. I przez to każdy deployment na przykład może mieć inną… dostać inny token tak naprawdę, czyli ryzyko wycieków i ryzyko utrzymania. Bo nie oszukujmy się, ten agent… Ta tożsamość, która ma możliwość deploymentu, to ona z reguły może robić absolutnie wszystko w naszej chmurze, więc ryzyko wycieku tego hasła biednego jest absurdalnie wręcz wysokie, a przejście właśnie na to tożsamościowe bezhasłowe niejako usuwa nam jedną podatność ataku, a szczególnie, jeżeli mamy CI CD wpięty w chmurze, który z reguły mamy wpięty w chmurze - jakikolwiek wyciek tego providera powoduje, że potencjalnie jesteśmy złożeni. Mała rzecz, która cieszy, jeżeli ktokolwiek korzysta właśnie z github actionsów, wydaje mi się, że to jest do przejścia tu i teraz.

Łukasz Kałużny: A więc raczej ja z tego korzystam w niektórych projektach, bo w Azure w tym nazywa się to Federated Identity Credential, ale ja z tego korzystam już od przeszło roku i jest po prostu… Jeszcze parę np. Terraform muszę sprawdzić czy już wreszcie to wspiera, bo ostatnio…

Szymon Warda: Wspiera.

Łukasz Kałużny: Już wspiera? OK. Bo jak zaczynałem z tym to nie wspierał tego.

Szymon Warda: Już wspiera i działa.

Łukasz Kałużny: Więc to jest taka rzecz. Inne rzeczy wspierają i ten wzorzec jest po prostu genialny. Czyli platforma wystawia swój zaufany token, a dostaje w zamian za niego, wymienia się na token z innej platformy i ściąga z nas to właśnie te wszystkie zwalone secrety i certyfikaty.

Szymon Warda: Tak, mała rzecz, która cieszy po prostu. I ostatnia rzecz… Do ChatGPT pluginy. Miałem okazję widzieć plugin do Blendera, czyli do softu do 3D. Całe tworzenie scen na bazie tekstu de facto i to robił dobrze, to robi kolosalne wrażenie w tym momencie; Naprawdę jestem pod wrażeniem jak się szybko rozwija. No i pluginów jest naprawdę dużo. Ten ekosystem rośnie. Widać, że ewidentnie już wszyscy producenci chcą mieć możliwość integracji z ChatGPT.

Łukasz Kałużny: To będzie raczej tak. Tylko wiesz co? I teraz tak patrząc się… Oskar w swoim newsletterze fajnie podsumował, że zacząłem pracę z ChatGPT, do czego go wykorzystuję? I opisał taki fajny… Cytując… “Praca z ChatGPT przypominała mi peer programming ze zdolnym klepaczem, ale słabym programistą” i to świetnie podsumowuje rzeczy. Czyli ten model de facto w tych kontekstach - on świetnie się sprawdza do generowania takich krótkich rzeczy, których my de facto wiemy, co chcemy uzyskać.

Szymon Warda: Tak, ale tu znowu wracamy do tego, co mówiliśmy parę odcinków temu. Może nawet paredziesiąt de facto, że to będzie po prostu generowanie tych mniejszych… To będzie eliminacja junior deweloperów de facto. Ludzie, którzy klepią powtarzalny, mały kod albo po prostu od takiego powtarzalnego Boilerplate’u… Na rzecz właśnie automatyzacji. To po prostu nie ma sensu, bo zawsze co próbowaliśmy zrobić? W końcu się ChatowiGPT udało. Te wysokopoziomowe na razie jeszcze są… Pozostają w rękach ludzi, ale to będzie się rozszerzało cały czas.

Łukasz Kałużny: Czat… Patrząc ciągle na całość i na te pluginy, bo tam parę osób robiło już z tego asystenty… Sobie z ChataGPT, łącząc się przez API. Co jest genialne. Zaraz będzie można zbudować na bazie tego produkt lepszy niż Siri, nie będzie już taki sztuczny.

Szymon Warda: Zgadza się, Mnie jeszcze jedna rzecz odnośnie czata zaciekawiła bardzo mocno. Na reddicie napotkałem się na wpis gdzie ktoś dał czatowi klatkę z Simpsonów i zapytał się czemu ten żart jest śmieszny. I wytłumaczył. Bardzo dobrze wytłumaczył. Przerażająco dobrze wytłumaczył.

Łukasz Kałużny: To jest tak jak z tą captchą, ale to już zostawmy. To co, kończymy.

Szymon Warda: Trzymajcie się, na razie.

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