W dzisiejszym odcinku zanurzymy się głęboko w świat IT, rozpoczynając od kontrowersyjnego wpisu na LinkedInie, który zrobił spore zamieszanie wśród profesjonalistów z branży.
Rozprawimy się z mitami i rzeczywistością pracy w gigancie jak Amazon, przyglądając się zarówno złotym zasadom software engineering, jak i pułapkom, na które można natknąć się, podążając za big techowymi ideami.
Następnie, zmierzymy się z wiecznym dylematem: zacząć od najtrudniejszych zadań, czy może jednak eliminować ryzyka stopniowo? A co z CI/CD? Czy jest to naprawdę niezbędne od samego początku projektu, czy jednak jest miejsce na elastyczność?
Ale to jeszcze nie koniec naszej podróży. Przeniesiemy się do świata projektowania UI i back-endu, analizując, jak ważne jest, aby pamiętać o solidnym fundamencie danych przed wizualizacją. Dodatkowo, będziemy rozważać, czy rzeczywiście każde rozwiązanie jest dobre dla każdego problemu, czy też każdy wybór niesie za sobą konsekwencje w postaci trade-offów.
W końcówce, zrobimy zwrot nie tylko ku technologiom, ale także ku myśli organizacyjnej i zarządczej. Porozmawiamy o tym, jak ważne jest zrozumienie kontekstu, w którym działamy, i jak metodyki takie jak Agile mogą być interpretowane i stosowane w praktyce. Czy rzeczywiście chcemy waterfalla, czy może istnieje złoty środek, który pozwoli nam na skuteczną pracę w zmieniającym się świecie IT?
Z nami nigdy nie będziecie na bieżąco, bo zawsze będziemy krok do przodu!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka znajdźcie w opisie. Ogólnie sobie poradzici. Dobrze Łukaszu, co tam wyszukałeś?
Łukasz Kałużny: Jakieś 2 tygodnie temu wyskoczył mi taki wpis na LinkedInie. Koleś się nazywa Aleksander Zając. Jakieś tam przemyślenia w postaci 10 punktów po 3 latach pracy w Amazonie i chciałbym to teraz przejść, bo z dziewięcioma się nawet zgadzam. Jeżeli popatrzymy się na całość to już pewnie 10 widzisz, tudzież dziewiąty, bo numeruje od zera, więc na to można trochę inaczej popatrzeć. A powiedział czego się nauczył jako software inżynier, takie jego golden rules wyniesione. I pierwszą rzeczą, którą rzucił, to żeby zająć się złożonymi rzeczami już od razu na początku, czyli zacząć rozwiązywać rzeczy od najtrudniejszych. I sądzę, że to jest mocno big techowy aspekt.
Szymon Warda: A ja bym się z tym mocno nie zgodził w ogóle.
Łukasz Kałużny: Czy wiesz i teraz co jest trudną rzeczą? To jest też właśnie do zdefiniowania bardzo mocno, bo zobacz, że może to być problem technologiczny, który faktycznie trzeba wziąć na początku, albo problem biznesowy, który jest de facto zagmatwany gdzieś przez logikę, rozwiązywanie problemu biznesowego.
Szymon Warda: Dokładnie. I póki nie znamy domeny de facto, to rzucanie się na takie duże problemy jest złym pomysłem. Ja bym to określił inaczej, usuwanie ryzyk wcześniej, czyli adresowanie rzeczy, które mogą nam wybuchnąć i udowodnienie czy możemy czy nie możemy tego zrobić. Ale to nie jest rozwiązanie problemu. To jest tylko pokazanie, że tak, mamy pomysł jak go zaadresować.
Łukasz Kałużny: Tak i wiesz, dlatego mówię, że trochę big techowe, bo zobacz, że tam prędzej będziesz miał problem technologiczny do rozwiązania duży, niż nieznajomość domeny.
Szymon Warda: Może i tak i nie. To pamiętasz, tam też jest dużo softu wewnętrznego produkowanego, który jest tak samo nudny jak inne softy. Tam też jest soft do zgłaszania urlopów.
Łukasz Kałużny: Który jest brany już z rynku. Chyba.
Szymon Warda: Właśnie.
Łukasz Kałużny: Dobra, następny punkt, to żeby nie pomijać CI/CD od początku, że jest to Twój sprzymierzeniec.
Szymon Warda: To jest no brainer.
Łukasz Kałużny: Tak, ale jeżeli popatrzysz na komentarze startupowców i innych founderów, którzy się tam, przepraszam za to określenie, ale się zesrali, bo Agile’owo się tam zesrali, to sorry, bo większość tam przekombinowuje to. Ale proste CI/CD powinno być w sprincie tak zwanym zerowym zestawione.
Szymon Warda: Twierdzisz, że deployment z komputera lokalnego niezłym pomysłem? Tak, zgadzamy się co do tego, jak najbardziej.
Łukasz Kałużny: Tak, więc to jest dobre. Punkt 2, tudzież 3, w zależności od którego indeksu liczymy. Nie ma uniwersalnych rozwiązań, każde będzie miało jakieś trade offy.
Szymon Warda: Bardzo dobrze, kontekst is the king, jak najbardziej.
Łukasz Kałużny: Tak i to świetnie idzie. I kolejna rzecz i tutaj też było w komentarzach, było tam, gdzie to widziałem, wyshare’owane, do tego było dużo ciekawych rzeczy, żeby zająć się persist data first, then build the UI, don’t do top-down development. No właśnie i…
Szymon Warda: Bym się z tym nie zgodził. Żeby było jasne, ja wiem o co mu chodzi. Chodzi mu o to, żeby nie mapować UI-a na tabelę, tylko on chciałby mapować dane i potem przekazać to na UI-a. To nie jest też tak dokładnie.
Łukasz Kałużny: I wiesz i teraz zaczynamy się bawić w trend - czy ktoś dokonał w ogóle analizy i zaprojektował system?
Szymon Warda: Zacznijmy od tego, że modelowanie danych jako takie to nie jest coś, co robimy na samym starcie, bo gówno wiemy o domenie, o problemie, o przepływach, o tym jak dane są odczytywane. Ja bym właśnie powiedział, że bardziej popatrzmy na, zaprojektujmy UI-e, popatrzmy jak dane są wykorzystywane, jak są odczytywane, jak są zapisywane, gdzie je grupujemy logicznie i popatrzmy potem i to jest jako jeden z elementów wyjściowych do modelowania danych.
Łukasz Kałużny: Wiesz co? I fajnie wleciałeś w takie przemyślenie, które miałem jak to czytałem, faktycznie nie musisz budować UI-a jako inżynier na początku i to jest prawda, ale równolegle musisz nawalać design. Jeżeli chcesz budować najpierw back end i masz API i inne rzeczy ustalone, co tam będzie, to w tym momencie trzeba się mocno skupić na dobrym designie i UX-ie tego faktycznym.
Szymon Warda: Nie powiedziałbym UX-ie, bardziej dla mnie przepływie danych, przepływie działań użytkownika. To jest bardziej ten element, no nie?
Łukasz Kałużny: Z jednej strony to będzie modelowanie systemu, procesów, z drugiej strony UX experience, w zależności kto na to jak popatrzy, w którym miejscu w dzisiejszych czasach. Ale to dobrze powiedział, żeby nie robić don’t do top-down development, czyli to jest też antycrudowe, że tak powiem.
Szymon Warda: Z tym bym się jak najbardziej zgodził, tak.
Łukasz Kałużny: Następna rzecz, która jest, to minimalizacja złożoności. Napisałbym to raczej na nie wprowadzanie złożoności, bo minimalizować to można przy refaktoringu.
Szymon Warda: Tak, kolejny punkt się też bardzo ładnie łączy, bo jest trzymanie rzeczy połączonych blisko siebie. Czyli generalnie podstawowe zasady SOLID-a, jak najbardziej.
Łukasz Kałużny: Tak i to jest właśnie don’t break dependencies a cross-repos. I to jest w sumie dobrą rzeczą, bo nie mówimy tutaj w żaden sposób, że monorepo jest super, multirepo jest złe, tylko trzymaj swój serwis w jednym miejscu.
Szymon Warda: Tak, fenomenalnie jest kolejny punkt: requirements drive development, nail them down before coding. To jest statement, to jest określenie - chcemy waterfalla.
Łukasz Kałużny: I teraz zobacz, czy statement waterfalla, zastanawiałem się nad tym. Zauważ, że jeżeli nie robisz produktu B2C i drive’owanego zupełnie klientami zewnętrznymi… Bo zauważ, jeżeli nie jesteś w fazie takiej discovery produktu, który wypuszczasz jeszcze startupem, tylko robisz ten nudny soft u siebie wewnętrznie czy B2B, to… Inaczej, główne wymagania, pewnie nie wszystkie, ale główne wymagania jesteś w stanie zdobyć.
Szymon Warda: Ja się tak nabijam z tym waterfallem, bo to jest trochę określenie waterfalla, ale to bardziej nabijam się z tego powodu, że to stwierdzenie jest w kontrze do takiego głupiego Agile’a. Nie w kontekście, że Agile jest głupi, tylko w kontekście takiego Agile’a na zasadzie generalnie to niezła metoda i lecimy do przodu po prostu.
Łukasz Kałużny: Słuchaj, ja inaczej, nie zapomnę tych historyjek, które brałbym jeszcze zrywał, rozwalał ekrany, kasował te boardy pod tytułem użytkownik będzie mógł się zalogować do user account.. Zresztą sam uczestniczyłeś w takich projektach, gdzie taka głupota padała, kiedy to jest technicznie architektura i cała podstawa na czym mamy budować i nie powinno być to w ogóle poruszane tylko zrobione.
Szymon Warda: Rozumiem. Tak, to nie zawsze też jest w mocy developerów, to jest duża też rola team liderów i product ownerów w tym momencie.
Łukasz Kałużny: I scrum masterów.
Szymon Warda: Idź do kolejnego punktu. Tak.
Łukasz Kałużny: Dobra, następne jest take shortcuts only as deadline approach, clean them up after. I to jest bardzo realna rzecz, tylko wiemy, że się nie sprzątają potem.
Szymon Warda: Ale będą podejmowane jak najbardziej. Nie uciekniemy od tego. Nie ma srebrnych pocisków, żeby skupiać się na czytelności kodu.
Łukasz Kałużny: I wiesz co? I to mi trochę nie współgra z częścią, żeby zminimalizować complexity, złożoność.
Szymon Warda: Czytelność można interpretować dualnie. Albo nawalimy wzorców projektowych, czyli fabryka goni fabrykę goni fabrykę goni fabrykę i mamy więcej interfejsów niż klas.
Łukasz Kałużny: Właśnie o tym, wiesz i teraz wiesz, że niektórzy SOLID-em zaimplementowanym bez pomyślunku i rayem definiują czytelny kod.
Szymon Warda: Zgadza się, ale jesteśmy w stanie dowolny pomysł przekręcić i zmaksymalizować go, żeby po prostu implementować go na głupa po prostu, bo to tak trzeba nazwać. Nie myślimy, tylko po prostu lecimy interfejsami, fabrykami, itd. Żeby nie było, one mają swoje miejsce. Tylko np. ja raz tylko prowadziłem szkolenia z kodowania, zawsze było: po co ci ta klasa? Po co ci jest ten interfejs? I głupio powiedzieć: przepraszam, zawsze była, bo dalej przekazuje się interfejs. OK, ale po co ten interfejs? Interfejs ma jakiś cel, on jest abstrakcją nad coś. Jeżeli tego celu nie potrzebujesz to użyj klasy, będziesz miał łatwiej, lepiej. I to dla niektórych było takie odkrycie, że faktycznie. Ale większość ludzi wewnętrznie czuła taką opcję, że: powinienem zrobić inaczej, bo to jest brzydkie. To samo np. przy modelowaniu, za tym, żeby pewne rzeczy wypłaszczyć w tabelach. To jest takie: ale ja bym dał tutaj tabelę słownikową i będzie, sobie zrobię. Bo tak nam wbija się do głowy, że powinno tak być. Takie prawdy absolutne.
Łukasz Kałużny: Prawdą absolutną, że minimalizm jest najlepszą formą inżynierskiego outputu, prostota jest największą elegancją.
Szymon Warda: Kod, który będzie miał 5 plików jest czytelniejszy niż kod, który będzie miał 25 plików.
Łukasz Kałużny: Tak, za to nie lećmy golangowym sterownikiem do piwiku w Kubernetesie, kiedyś, w którym był komentarz na zasadzie: pozwól statkowi kosmicznemu lecieć dalej i 10 tysięcy w jednym pliku.
Szymon Warda: I ostatnie, używaj Javy. Java nie jest sexy. Jest dobra, szybka i się skaluje.
Łukasz Kałużny: Raczej czy wiesz, use Java, to jest trochę na zasadzie: kurd,e weź język, w którym masz kompetencje. Koniec i kropka.
Szymon Warda: Ja bym powiedział co innego. Weź język, który jest dojrzały, nie idź za trendami, czyli Java, C Sharpa, itd. Nie idź w najnowszą odmianę JS-a.
Łukasz Kałużny: Weźmiesz Pythona, Node’a, wszędzie. Tylko nie mów, że jak potrzebujesz wydajnego, bierzesz Rusta.
Szymon Warda: Trochę tak.
Łukasz Kałużny: Dobra, to by było na tyle z tego postu, ale jest ciekawy. Ciekawe klocki. Dobra, to od Ciebie?
Szymon Warda: W sumie to zainspirował trochę ten tok myślenia papier od Google’a i cała dyskusja odnośnie używalności kodu, który jest sexy, itd., itd. Papier Google oczywiście, który mówi o secure code. Cała dyskusja odnośnie języków i też tam dyskusja ze znajomymi, jaką miałem.
Łukasz Kałużny: Moment, żeby wprowadzić. Szymon mówi o White Paperze, który jest zalinkowany Secure by design at Google.
Szymon Warda: Tak, teraz idziemy takimi stwierdzeniami, zobaczymy czy się zgadzasz. Finalnie każdy projekt będzie miał swoje biblioteki wewnętrzne, będzie miał. Jakieś tam frameworki, coś będzie miał.
Łukasz Kałużny: Klasa i utility, zawsze gdzieś się pojawi, czy helpers.
Szymon Warda: Wszyscy ich nie znosimy. To jest pierwsze stwierdzenie, kto panu tak popsuł? To jest jak widzimy te wewnętrzne biblioteki najczęściej. Na to developerzy najwięcej narzekają. Tak z reguły jest. A już jak jest framework jakiś to już w ogóle jest masakra. Jak spojrzymy teraz na gigantów, Google, Facebook itd., tam nie ma kodowania, tam jest integracja, tam są biblioteki. Potrzebujesz zrobić X, korzystasz z biblioteki do X i koniec, nie masz wyboru, nie masz możliwości doprecyzowania czemu teraz. Bo ten sam problem, który jest załóżmy w Windowsie: każdy IF, który jest Windowsie, to jest po to, żeby jakiś program działał i żeby był zgodny. Dlatego właśnie możemy odpalić rzeczy na Windowsie 11, które generalnie chodziły na 9.5 z niewielkimi zmianami. Przemyślenie jest takie, że te wszystkie wewnętrzne biblioteki, itd., których tak nienawidzimy, a które zawsze budujemy, powstają po to, bo to jest sposób w jaki organizacja się uczy i zdobywa tą wiedzę, tą wiedzę przechowuje, umie obsługiwać kolejne sytuacje krytyczne. Te wszystkie IF-y po coś się tam znalazły, a złożoność po coś tam jest. To samo chodzi odnośnie języków, technologii i sposobów pisania. Zamordyzm standaryzacyjny wszyscy chcemy być jak w Google’u, czyli ten zamordyzm mieć niejako, ale w projektach wewnętrznych, jak robimy to, poza Googlem, to jest opcja generalnie: a użyjmy czego tylko możemy. Powiem tak brutalnie: to się zdecydujmy, kurczaki.
Łukasz Kałużny: Raczej zaczynasz, tak jak mówisz: chciałbym zrobić CV Driven Development, tylko łączę wzorce, które ze sobą są niekompatybilne.
Szymon Warda: Tak, sprawdzało się. Robimy wszyscy CV Driven Development, a potem się dziwimy, że nie mamy jak Google. Upraszczam bardzo mocno, ale uważam, że taka standaryzacja biblioteki wewnętrzne, ok, próg wejścia jest dużo większy, bez dwóch zdań. Natomiast jeżeli ogarną developerzy te biblioteki, te frameworki nawet, to w tym momencie zysk z tego potencjalnie może być bardzo, bardzo duży, bo problemy organizacyjne rozwiązaliśmy już w jednym miejscu i nie musimy po raz dziesiąty implementować ten sam problem i go rozważać, albo jak ten flow wygląda. Więc nie bójmy się starego softu, on po prostu działa. Skupmy się na realnych problemach po prostu.
Łukasz Kałużny: Wiesz co, zabawą trochę wewnętrzne biblioteki. Wiesz dobrze, że jeżeli wychodzą poza system, przestają być utrzymywalne.
Szymon Warda: Tak, to jest problem taki, że trzeba się pogodzić z tym, że to są wewnętrzne biblioteki nie w formie organizacji całej, że nie użyjemy jej do systemu A, do systemu B, do systemu C, czyli będąc załóżmy outsourcingiem nie będziemy budowali podstawy systemu na tych bibliotekach. Chociaż znam przypadki gdzie to się sprawdza mimo wszystko, ale w kontekście projektów to robienie tych wszystkich przepisywań na lewo i na prawo, żeby gonić.
Łukasz Kałużny: W większości, bo się moda zmieniła.
Szymon Warda: Tak, z całym szacunkiem, pewne rzeczy po prostu zostawmy w spokoju i niech to sobie tam działa, rozwijajmy, itd. Wiadomo, że to jest trudne, bo musimy mieć zespoły, które biblioteki utrzymują. To nie jest na zasadzie, że mamy bibliotekę np. klasy utils i tam każdy do niej pisze, bo to będzie pierdolnik za chwilę.
Łukasz Kałużny: Nie, pull request, review, czy faktycznie to powinno tam trafić.
Szymon Warda: Owner.
Łukasz Kałużny: Tak, tylko też mówisz, żeby złapać kontekst już nie mówimy o małych systemach.
Szymon Warda: Tak, to się opłaca przy większych systemach.
Łukasz Kałużny: Jak masz 50 developerów do jednego systemu, to już się okazuje, że takie hocki klocki trzeba przewidzieć i robić od początku.
Szymon Warda: Ja bym powiedział, że od 10 to zaczyna mieć sens, już będą pracowali dłuższy czas.
Łukasz Kałużny: Tak, tylko wiesz, patrzę nawet na Twoje doświadczenia tam jednego z tych większych projektów, to przy 50 zaczęło się to spłacać dobrze.
Szymon Warda: A to się spłacało błyskawicznie pod tym względem.
Łukasz Kałużny: Nie, zobacz, że w Twoim przypadku, tam tego ERP-a, zaczęło to się spłacać, w sensie taki super zysk było widać jak nawaliło tego i trzeba było wyskalować development.
Szymon Warda: Tak, dokładnie, bo to było ważne. Np. załóżmy, jak mam problem taki, jak ujednolicenie UI-a generalnie, ujednolicenie pewnych zachowań, wzorców technologicznych. To powinno być w bibliotekach, żeby ludzie nie kodowali tego, co po prostu nie zadziała. Więc nie bójmy się.
Łukasz Kałużny: Słuchajcie, ja bym zwrócił jedną rzecz, którą Szymon mówi - biblioteka, nie framework. Nie piszemy frameworka żadnego.
Szymon Warda: Framework jest super ryzykowny. W pewnych sytuacjach on ma sens. Dalej, on będzie miał sens w pewnych sytuacjach. Np. biblioteka przy mniejszej skali, załóżmy przy 10 osobach, biblioteka ma większy sens, przy 50 framework będzie już miał sens, bo pewne rzeczy trzeba wystandaryzować.
Łukasz Kałużny: Ja będę się skłaniał zdaniu, że jeżeli już tam robimy mikroserwisowo, czy cokolwiek, to biblioteki + boilerplate projektu z wykorzystaniem tych bibliotek, żeby było można zacząć kodować.
Szymon Warda: I tak i nie, powiedzmy sobie, zależy co systemy mają robić i zależy jak mają być skomplikowane i jak mamy skomplikowaną architekturę swoją drogą. I moje przemyślenie jest takie: nie bójmy się tego starego kodu i naprawdę nie każdy kod trzeba, jeżeli on działa to działa. Ale to, co jest na nas core’owe, po prostu starajmy się utrzymywać. Cała w DDD, to co jest dla nas corem, utrzymujemy żeby było dobre i to niech będzie reużywane, niech rozrośnie się na pozostałe rzeczy, a gdzieniegdzie po prostu dajmy ludziom się wyszaleć. I tak to powinno być projektowane, nie trzeba koniecznie marudzić, że: o Boże… Tyle mojego marudzenia. Co tam Łukaszu masz?
Łukasz Kałużny: Dobra, następny szybki wpis od DoorDasha, czyli następny powód dlaczego architektura komórek. Wspominaliśmy o tym kilka odcinków w kontekście chyba Slacka, Slack albo Discorda, mi się kojarzy.
Szymon Warda: Slack był, ale było też jeszcze w innych systemach, ale jak najbardziej.
Łukasz Kałużny: Tak, cell architecture. I dlaczego? Dwa powody, raczej pierwsze dwa, kurde, de facto jest jeden w tym DoorDashu, czyli żeby zmniejszyć koszty na transferze pomiędzy tymi availability zone’ami w AWS-ie, bo ruch sieciowy jest drogi i przy okazji też skrócić czasy odpowiedzi, przetwarzania. Czyli zabawa polega na tym, że najlepiej, żeby request nie opuszczał w żaden sposób zone’y, jak wpadnie, jeżeli wszystko działa poprawnie, bo to jest istotny element. I całość jest pokazane, w jaki sposób osiągnęli to na Kubernetesie, jak tutaj envoy ma się do całości tej zabawy. Nie pada tu słowo “istio”, co ciekawe.
Szymon Warda: Ale nie potrzeba. Przecież generalnie np. w Kubernetesie w zeszłym roku doszło właśnie wsparcie dla lepszego routowania multiregionowego.
Łukasz Kałużny: Wsparcia. Ale wiesz, jest teraz pytanie, nie wpadło tutaj w ogóle nic o istio, to jest właśnie jedna rzecz ciekawa. Druga rzecz, ale na temat właśnie topology spread constraints, o których mówisz, czyli rozrzucaniu pomiędzy zone’ami + innymi tego typu elementami. Wpadło, więc to jest ciekawe. Czyli można powiedzieć, że na envoyu zrobili swojego własnego service mesh, o tak.
Szymon Warda: Nie service meshem jeszcze generalnie.
Łukasz Kałużny: Tak, a drugą rzecz, którą wpisali, to właśnie topology aware routing jest tam wrzucony. I to się gdzieś teraz, w sumie jest już od dawna, bo od 1 23. W Kubernetesie 1.27 to zmienili nazwę na topology aware hints, czyli które pozwala nam samodzielnie wpisać hinty, jak ma coś być obsługiwane routowane.
Szymon Warda: To jest w ogóle fajny feature, fajnie to obsłużyli.
Łukasz Kałużny: Teraz zabawa. Jeżeli korzystasz, z tym mam zawsze problem, czy w ogóle to włączać czy nie… Może inaczej szkoda, że dostawcy tego nie robią by design, dostawcy klubowi tego nie włączają po prostu, żeby to się działo. To jest taki brak dla mnie w Kubernetesie. Druga sprawa, którą wiesz. Wiesz ile aplikacji potrafiło pójść na prodzie, na jednym POD-zie.
Szymon Warda: Node’zie.
Łukasz Kałużny: Nie, w sensie, że deployment ma jeden POD.
Szymon Warda: OK.
Łukasz Kałużny: Już nie mówię o tym, ale mamy na przykład każdy serwis w jednej kopii, to wiesz jak często się potrafi zdarzyć i że na testach jest testowane na jednej kopii, a na produkcji są trzy i zaczynają się zabawy.
Szymon Warda: To jest ciekawe. Tak w ogóle to myślę, że porzucimy wpisy, tak przy okazji tam nie ma co omawiać, wpisy odnośnie tego, jak wygląda utylizacja Kubernetesa, to też jest, ciekawie wygląda. Dobrze, to ja się dorzucę, kolejne rzeczy. Dwa artykuły właściwie, ale znowu jakiś taki przemyśleniowy odcinek dzisiaj. Oglądałem z młodą Marsjanina, w kontekście uczenia rozwiązywania problemów i 2 artykuły idealnie do tego pasują. Jeden, to jest artykuł bardzo dobry, bardzo dobrze napisany, od Allegro, odnośnie Kafki, odnośnie tego jak rozwiązali problemy z spikeó’w latencyjnych, wykorzystali eBPF-a, jakich narzędzi, jak to połączyła ładnie z Prometeuszaem. Bardzo fajny artykuł jak po kolei rozwiązywać i debugować kwestie problemów technicznych. I podkreślę jeszcze więcej, super napisane, bardzo ładnie, bardzo przejrzyste, przydatne, fajnie opisują proces.
Łukasz Kałużny: Raczej światowy poziom blogów inżynierskich big techu.
Szymon Warda: Nawet czasami lepiej niż niektóre blogi. Kolejne rzeczy. Mierzenie latencji na 99 percentylu, to jest nieźle, a gdzieniegdzie przesuwa się jeszcze, że 99,9 percentyl. To jest już absurdalna wartość. Faktycznie szacunek. Drugi blog, wpis na blogu, to metryki DORA w booking. I teraz DORA to są oczywiście te metryki, Google’owe de facto, czyli deployment frequency, lead time for changes, change failure rate i time to restore. Czyli jak często deploy’ujesz, jak szybko od deploymentu, jak często są błędy i jak szybko te błędy poprawiasz. I znowu jest super fajny, bo on po kolei pokazuje rozwiązywanie problemów organizacyjnych. I co jest fenomenalne, to jest taka mała pierdoła mimo wszystko, pokazują ile to zajmuje czasu. Skala tego artykułu jest mniej więcej od marca do października, więc pokazują fajnie, że wdrożenie metryk, jakie mieli problemy, jak je rozwiązali, czym je zastąpili, gdzie Dory nie mogli bezpośrednio użyć, gdzie im się to wysypało. I co więcej, rozwiązaniem całego problemu okazały się problemy miękkie, znaczy rozwiązania są miękkie, bo problemy były miękkie. Chciałem ich pochwalić, że rozwiązaniem nie były mikroserwisy, chociaż tam po drodze użyli mikro frontendów, które jednak okazało się, że działały gorzej, mimo że metryki pokazywały, że działają lepiej. Fajny artykuł, który naprawdę na sucho pokazuje i tak bardzo ostudzenie, że tak powiem, pokazuje jak wdrażać takie zmiany organizacyjne w organizacji i ile to zajmuje czasu, bo to jest cholernie długi proces.
Łukasz Kałużny: Tak, ale DORA tak. Zresztą dyskutowaliśmy, DORA nie służy, przypominając, bo tam są cztery ćwiartki, jak wypadasz i nie trzeba być w tej najwyższej, zupełnie.
Szymon Warda: Tak, mówisz o dojrzałości DevOpsowej.
Łukasz Kałużny: Tak, dokładnie. Ale to jest główna rzecz, czyli patrzysz na dojrzałość jako na całość, czyli nie musisz wypadać w ostatniej. Poza tym też to mocno rozdzieli jako elitę już taką ostatnią.
Szymon Warda: Dobrze. Co tam masz?
Łukasz Kałużny: To teraz taką luźną ciekawostkę po takich przemyśleniach, jako żart. Windows odpalony jako VM-ka w kontenerze dockerowym na Linuksie.
Szymon Warda: Właśnie widziałem tego linki i to wygląda ciekawie?
Łukasz Kałużny: Inaczej, to co jest zrobione, bo to jest teraz tak, jak zawsze podniecenie, bo ktoś coś zrobił. Ktoś zrobił coś, czyli wziął KVM-a, odpalił go i przekazał KVM-a jako device do kontenera, zrobił ładny skrypt, który pobiera sobie ISO i bootuje korzystając z możliwości jaką Windows daje, automatyzację, postawienie takiego Windowsa i dostanie się do niego przez VNC do konsoli. To w ramach ciekawostki jak się ludziom nudzi, co można zrobić ze sklejenia technologii, które są. o tak, ale działa. I co ciekawe, też jest tam kontener. To samo jakby ktoś chciał spróbować zrobić to na Macu, na nowych Macach ARM-owych, bo też jest wersja ARM-owa tego samego.
Szymon Warda: Dodam jeszcze, że nawet wspiera pass through dla dysków i pass through dla USB, więc szacun, naprawdę szacun.
Łukasz Kałużny: Wiesz co, ale to zobacz, to jest tylko, jak sobie popatrzymy, tam nie ma nic takiego specjalnie dziwnego, jak się popatrzy, bo to jest po prostu, jak popatrzymy sobie na to, ktoś miał po prostu fantazję. Jak to było kiedyś, była taka bardzo stara reklama: trzeba mieć fantazję, dziadku.
Szymon Warda: Czego to była reklama?
Łukasz Kałużny: Jakichś ubezpieczeń. I tutaj de facto chodzi o to, to tak jak odpalanie Windowsa na telefonie i innych rzeczach, jak robiono. Więc…
Szymon Warda: Duma generalnie. Przypomina mi się jak Husqvarna odpaliła chyba Duma na czymś tam generalnie, na kosiarce.
Łukasz Kałużny: Da się? Da się. Więc to w ramach ciekawostki.
Szymon Warda: To ja w ramach takich znowu tematów, Martin Fowler, więc wiadomo, że będzie poważnie.
Łukasz Kałużny: O Boże!
Szymon Warda: Wzorce na refactor systemów opartych na wiadomościach. Artykuł, mam bardzo mieszane uczucia co do niego i trochę jedne przemyślenia.
Łukasz Kałużny: Raczej ważne to jest ściana reklamowa, bo to nie jest jego wpis. To jest ważne też do powiedzenia sobie.
Szymon Warda: Tak, ale jest na jego blogu, więc podpisuje się pod tym. Jaki problem? Jak jest taki problem ze statement. Mamy system, który jest legacy, oczywiście nazywamy już legacy i chcemy teraz połączyć go z innymi systemami i ten system legacy wysyła wiadomości. No i teraz co możemy zrobić? Możemy dodać wysłanie wiadomości, labelek, jakieś tam pole na dane, które będziemy filtrowali, będziemy wysyłali…
Łukasz Kałużny: Czyli odkryto topiki.
Szymon Warda: Wiesz co, nie do końca, bo to jest bardziej taki, że masz wiadomości, dodajesz jakieś tam pole i teraz system stary, tam też dodajesz IF-a oczywiście i on te wiadomości ignoruje. A jak system nowy, generalnie też dajesz IF-a. Jak widzi, że to jest nowa wiadomość to ją pobiera. To jest jedna opcja. Kolejny pomysł jest taki, że to może zróbmy inaczej, może zróbmy taki myk, że jeden system, wprowadźmy system pośrodku, który będzie odbierał i będzie dalej routował ta do starego, do nowego, w zależności co tam trzeba zrobić. Problem dalej jest. Potrzebujemy jakichś odpowiedzi na to. W tym momencie ten system, taki reverse proxy, on tam routuje, czeka na odpowiedzi i te odpowiedzi dalej z tego systemu starego wysyła.
Łukasz Kałużny: Czekaj, czyżby ktoś opisał książkę Enterprise Integration Pattern w poście blogowym?
Szymon Warda: Tak, ale teraz idziemy dalej, bo generalnie to są jeszcze inne pomysły na zrobienie tego. Wiadomo, że jednym z pomysłów będzie oczywiście mój ulubieniec, czyli Change Data Capture, czyli CDC. Przecież musiało się pojawić. Żeby nie było, generalnie faktycznie jest taki jeden fragment tego wpisu, gdzie on pokazuje ładnie, że od CDC można zacząć i potem po kolei warstwami przechodzimy coraz wyżej, aż do warstwy biznesowej, że będziemy z warstwy biznesowej wysyłali te wiadomości, żeby było po bożemu, że tak powiem. Jaki ja mam problem z tym artykułem? To jest to, że a ile Łukasz znasz takich refraktorów, bo to jest duży refraktor taki, takie sytuacje, że te systemy pośrednie zostaną tam i one będą na zawsze elementem architektury.
Łukasz Kałużny: To zawsze tam będzie.
Szymon Warda: Zawsze będzie, więc teoria jest taka, że zróbmy to, żeby nie musieć ruszać systemu legacy. Ale moi drodzy, jakie mamy systemy legacy? Jest, znaczy się zrozumienie go, że Fowler nawet w tych swoich pomysłach dodaje tam elementy, gdzie trzeba ten legacy zmienić, więc my i tak musimy go ruszyć. To ruszmy go wertykalnie, podzielmy go wertykalnie, a nie wprowadzamy nowe obiekty, bo te obiekty tam zostaną, my ich nigdy stamtąd nie wyrzucimy, bo to jest cholernie ryzykowne i na to nie będziemy mieli też więcej czasu, itd. Dodając nowe elementy, które są tylko przełącznikami, tą logikę, co się gdzie dzieje, jeszcze bardziej rozpraszamy tak naprawdę. I teraz jest taki jeden genialny wpis, który teraz Łukaszowi właśnie wysyłam, żeby ten, bo nie chciałem…
Łukasz Kałużny: Jak zawsze ukryty.
Szymon Warda: Jest tak, seria, Łukasz widzi co Szymon mu pokazuje i on fajnie trochę pokazuje to, o co mi chodzi. Zobacz, przewiń do rysunku architektury. Wydaje mi się, że powinniśmy ten obrazek dać na zdjęcie do odcinka.
Łukasz Kałużny: I już patrzę. Gdzie mi go wkleiłeś?
Szymon Warda: Na Slacku masz.
Łukasz Kałużny: To słuchajcie, już lecę. Zostałem zaskoczony, wzięty z zaskoczenia przez Szymona.
Szymon Warda: Jak to się czasami zdarza.
Łukasz Kałużny: O Boże, to ten pierwszy rysunek, który się tam…
Szymon Warda: Tak, rysunek architektury.
Łukasz Kałużny: Nie wiesz co się dzieje, a to tylko prosty serwis.
Szymon Warda: Tak, że to jest tam akurat architektura do Guardiana, do ich serwisu, którym się chwalą. I ta architektura jest straszna. To jest kreska w kreskę, które się przecinają, każdy gada z większością. Jest tyle technologii, tyle serwisów, który każdy ma inną rolę tylko po to, żeby przykryć inny serwis i inną logikę i inny kawałek rzeczy. To nie ma większego sensu, co się tam w ogóle dzieje.
Łukasz Kałużny: Tutaj wiesz, tu jest akurat apka serverlessowa, więc jej wybaczmy w tym, co rzuciłeś.
Szymon Warda: Ale zobacz nawet na model danych, jak to wygląda, jak ona się komunikuje i do czego wykorzystany tam jest GraphQL, itd. Tego po prostu jest, tam każda apka czyta ze wszystkiego i komunikuje się przykrywając GraphQL-a tylko po to, żeby on namierzył co gdzie jest.
Łukasz Kałużny: Raczej tak, ktoś rozbił bardzo ładnie, czyli wszystko ze wszystkiego czyta. I to jest pytanie jak pisać serverless. Ale wracając do całości tego wpisu…
Szymon Warda: Fowlera.
Łukasz Kałużny: Fowler go tylko opublikował, więc tutaj jest…
Szymon Warda: Na jego blogu, więc na to samo wychodzi.
Łukasz Kałużny: Nie będę tutaj walczył. Wiesz co, całość, te przepisywania…
Szymon Warda: Te wzorce mają swoje zastosowanie, ale w bardzo wąskich przypadkach.
Łukasz Kałużny: Wiesz co? Inaczej, teraz to jest takie, to jest ten mit refaktoringu systemu, że zostawmy UI i zaczynajmy wyciągać warstwa po warstwie, że zrobimy teraz. Jak ja już to zobaczyłem Root Domain Services, takie określenie.
Szymon Warda: Nie wiem czy to jest od tego. Jest opcja, że nie ruszajmy legacy, bo nie. I tak musimy to legacy zrozumieć, bo uciekniemy od tego.
Łukasz Kałużny: Mam wrażenie, że to jest teraz tak dwojako. Mamy taki trend na rynku. Z jednej strony ciągle gdzieś tam się buduje opus magnum, ale gdzieś mówi się o tym, żeby ta aplikacja była wyspecjalizowana i nie łączyła zbyt wielu domen naraz. Są gdzieś tam takie przebłyski, żeby aplikacja służyła do jednego, a nie była kombajnem.
Szymon Warda: I to ma jakiś tam sens, jak najbardziej. Ale jak to by się aplikowało w tym momencie do tego legacy? Bo tu Cię trochę nie rozumiem.
Łukasz Kałużny: Czy wiesz co, mówię, że przy przepisywaniu, bo całość zobacz, że to jest powiedziane, że mamy system w ruchu i to jest taka kwintesencja Agile, czyli jak najszybciej, żeby coś na prodzie się pokazywało.
Szymon Warda: Tak, trochę tak, to jest trochę tak, bo żeby było szybko, w sensie zróbmy coś nowego i opcja, że to nowe będzie łatwiejsze. Nie będzie, bo przeniesiemy ten proces i on potem się skomplikuje za chwilę tak naprawdę. I bez zrozumienia tego, co było, nie zrobimy czegoś, co ma być dobrze i za rok wylądujemy w dokładnie tym samym punkcie, w którym byliśmy.
Łukasz Kałużny: Wiesz co to kiedyś musiałem przepraszać Gutka za władowanie go w jeden projekt. Parę lat dobrych temu. I tu zabawa właśnie polegała na tym, że można powiedzieć, że stwierdziliśmy, że pójdziemy sobie techniką, że wytniemy jeden komponent, który rzekomo był proxy i przepiszemy go na nowo. Nie brzmi skomplikowanie. Wejście do systemu, gdzie nie miało być logiki biznesowej. Co się okazuje? Sam klient nie wiedział ile ma tam logiki.
Szymon Warda: Bo klienci takich rzeczy z reguły nie wiedzą, bo to powoli rośnie, rośnie, rośnie tak naprawdę.
Łukasz Kałużny: Tak, to był taki zlepek. Jeszcze pamiętam, że oj, biedny Gutek musiał czytać Visual Basica .NET-owego.
Szymon Warda: Dobrze, lećmy do kolejnego. Masz coś jeszcze?
Łukasz Kałużny: Nie, ja już na dzisiaj koniec, bo długo nam wyszło.
Szymon Warda: Dobra, to w takim razie tyle. Trzymajcie się. Hej!
Łukasz Kałużny: Trzymajcie się, na razie. Hej!