➡️ 04.06.2024 Architektura 101
Tym razem wywracamy do góry nogami tematy, które spędzają sen z powiek każdemu szanującemu się specjaliście IT. Zastanawiasz się, czy mikroserwisy to nadal złoty standard, czy już przestarzała moda? Dziś zagłębimy się w to, jak firmy rzeczywiście decydują o podziale aplikacji i jak to wpływa na ich zwinność i skalowalność.
Nie obędzie się bez porównań – rzucimy światło na różnice między narzędziami monitorującymi jak Grafana, Loki, i Tempo a nowoczesnymi podejściami takimi jak Pixie na eBPF. Które z nich rzeczywiście dają ci to, czego potrzebujesz do skutecznej obserwacji i zarządzania wydajnością? A na deser, jak observability wpasowuje się w KPI i cele twojego zespołu? Czy jesteś gotów do tego, by te narzędzia naprawdę pracowały na twój sukces?
Przygotuj się na ostry rzut okiem na to, co jest hot, a co już się przejadło w świecie IT. Startujemy!
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: Słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka na Patoarchitekci.io, które oczywiście w opisie, itd., itd., ogarniecie.
Łukasz Kałużny: Dobra, przed rozpoczęciem przypominamy o szkoleniach. Szymonie, Ty za cztery bodajże dni będziesz miał, 18 czerwca, Observability. I o czym szkolenie?
Szymon Warda: Tak, szkolenie, tak naprawdę kilka rzeczy, od tego czym się różnią tzw. auto instrumentation APM-y, czyli na przykładzie Application Insights. Dalej uważam za w sumie jednego z sensowniejszych APM-ów. W kontekście jak będziemy strategię układali do całego monitorowania. Potem powiemy sobie o obecnym stosie Opentelemetry, czyli tym co się najczęściej wykorzystuje - stos grafanowy: Tempo, Loki, Grafana, Prometeusz. Porównamy sobie to wszystko ładnie z Pixi, czyli takim znowu monitoringiem, observability na eBPF-ie. I powiemy sobie też odnośnie, trochę taka ciemna wiedza, czyli mianowicie jak ułożyć w ogóle strategię do monitorowania, do alertingu, do podejścia do wydajności, co dalej można z tym zrobić, jak to w ogóle budować w organizacji, tak żeby to nie była po prostu zabawka, która jest w organizacji, ale nikt jej nie używa, jak to często chyba widujemy w wielu, wielu systemach.
Łukasz Kałużny: I wszystko z perspektywy aplikacyjnej i architektury tego.
Szymon Warda: Tak, dokładnie. I też organizacyjnie, jak to wpiąć w KPI, w cele zespołowe, firmowe, itd.
Łukasz Kałużny: A następne szkolenia już od września, więc też zapraszamy na Patoarchitekci.io/szkolenia. Dobra, to co na dzisiaj Szymonie?
Szymon Warda: Dobra, dzisiaj kilka linków, bo takie trochę się ogórki bym powiedział zaczynają. Ale jest jeden fajny artykuł odnośnie spojrzenia, wydaje mi się, że już kiedyś o tym mówiliśmy, spojrzenia na mikroserwisy z punktu widzenia ekonomicznego, że to wynikało fajnie ze wzrostu po prostu organizacji i z tego, że jak organizacje się kurczą, to nie ma tej potrzeby, nie ma tego elementu motywującego, żeby faktycznie te mikroserwisy dalej tłuc, bo po prostu nie musimy tworzyć tych granic pomiędzy zespołami, po prostu możemy włożyć więcej ludzi do jednego repo, jednego systemu. Co więcej, teraz mamy też dużo więcej, powiedzmy bardziej doświadczonych developerów, itd. Ale nie dlatego ten artykuł wybrałem, mimo że naprawdę jest niezły tak naprawdę, to jest to, że przypomniała mi się rozmowa z jednym z naszych klientów odnośnie tego podziału na mikroserwisy. I tam oni się bardzo mocno upierali, żeby właśnie nie dzielić względem D tak naprawdę, bo to się sprawdza. A mnie to skłoniło do takiej myśli, która chyba jest dość ważna, że korzystamy z D do tworzenia podziałów. Tak, racja i to powinno być, to powinno istnieć. Ale to nie jest to, że jak mamy podział to musimy wydzielać. Bo wydzielamy serwisy bazując na niefunkcjonalnych wymaganiach, czyli np. skalowanie, wydajność, zespoły, itd. Czyli to nie jest to, że jak mamy podział, mamy bounded context, to już musi to być osobny serwis. Nie, to dalej może być w jednym serwisie, tylko mamy tą możliwość wydzielenia jakbyśmy potrzebowali się skalować, itd. I to wydaje mi się często jest takie łączone w jedną kupę. Łączymy czemu dzielimy z tym jak dzielimy. A tak wydaje mi się, że…
Łukasz Kałużny: Jak dzielimy, to jest dla mnie, to bounded context nie powinien opuszczać zespołu. To jest chyba dobre…
Szymon Warda: Tak, tu bym się…
Łukasz Kałużny: Ja patrzę domenowo, jak zaczynasz robić… Piękno mikroserwisu będziesz tracił jak zaczynasz robić domenę cross zespołowo. Czyli nagle okazuje się, że ta elastyczność, po której to skalowałeś, wprowadzasz kolejne nitki komunikacji i to takie grube.
Szymon Warda: Też mętlisz bardzo w tym momencie pewnie pojęcie domenowe, bo są inne zespoły, które się ze sobą nie komunikują, itd.
Łukasz Kałużny: Więc odpowiedzialność, rozliczalność też znika.
Szymon Warda: Tak i tu się jak najbardziej zgodzę generalnie. Ale dalej, co tu mówimy to to, że ten bounded context musi być w jednym serwisie, bo inaczej to w ogóle mamy totalną padakę. Ale co jest bardzo ważne, to jest to, że naprawdę często widuję taką opcję, że okay, jak to są różne bounded contexty, to muszą być osobne serwisy. No nie, nieszą być.
Łukasz Kałużny: Wiesz co, wróciłbym do sławetnego, to jeszcze wystąpi w przyszłych odcinkach, jak usłyszycie nagranie z Meetupu, ale do case’u serverlessowego AWS-a i Prime’a.
Szymon Warda: Tak.
Łukasz Kałużny: Że bounded contexty poszły w jeden deployment model.
Szymon Warda: Bo to po prostu ma sens, jak mamy dojrzały jakiś tam system generalnie, po prostu sobie żyje. Dobra, co tam u Ciebie Łukaszu?
Łukasz Kałużny: Ja bardziej newsowo, i lecimy. Ciekawa rzecz raport na DevOpsKube, raport zrobiony: State of Kubernetes Jobs Report. I tam jest ciekawa rzecz, która się pokazała, co jest najpopularniejsze. Mam nadzieję, że jeszcze nie widzisz tego linku. Jaki provider do Kubernetesów jest najpopularniejszy?
Szymon Warda: No nie widzę. Więc właśnie…
Łukasz Kałużny: Strzelaj.
Szymon Warda: Provider do Kubernetesa, w sensie provider… A!
Łukasz Kałużny: Cloudowy.
Szymon Warda: Cloudowy.
Łukasz Kałużny: Na podstawie ogłoszeń o pracę.
Szymon Warda: Ja bym pomyślał, że AWS. Jak na bazie ogłoszeń…
Łukasz Kałużny: Dobra, a ile tortu?
Szymon Warda: Ile AWS ma tortu? AWS ma sporawo, załóżmy, że 30, coś koło tego?
Łukasz Kałużny: 45 w ogłoszeniach o pracę, jeżeli chodzi o Kubernetesa.
Szymon Warda: To jest dużo, bo AWS ma tam 30-parę procent rynku, więc generalnie to jest dużo.
Łukasz Kałużny: Właśnie i teraz jest pytanie jak bardzo AWS, wiesz… To jest ciekawe zawsze spojrzenie na rynek, jak bardzo dany cloud w którym miejscu siedzi. GCP ma 18%, co jest takie bardzo urealnione.
Szymon Warda: Dobrym wynikiem.
Łukasz Kałużny: Tak, urealnione. I mam wrażenie, że Azure być może ma ciutkę więcej tego tortu, tego brakującego. Tylko firmy, które wykorzystają, trochę inaczej budują te kompetencje. I to są często importowane kompetencje, gdzie AWS jest takim bardziej inhouse’owym czasami jak patrzę rozwiązaniem.
Szymon Warda: Mam wrażenie, że mimo, że AWS się bardzo zmienił w ciągu ostatnich kilku lat, to dalej tam podejście jest takie, że jednak jest często traktowany jako provider VM-ek, ewentualnie provider usług, które trochę przykrywają VM-ki. Ewentualnie po prostu daj nam i lecimy tak naprawdę. Ale faktycznie, ciekawy wpis. Spodziewałem się dużo mniejszego…
Łukasz Kałużny: Dlatego to wziąłem, bo mnie trochę zaskoczyło, o tak. Gdyby tu było np. poniżej 40, to nawet bym na to nie rzucił tak okiem bardzo, ale to mnie tak rozwaliło, że więcej niż 45. What the… Ale za to jeszcze On-Premu - 8,4.
Szymon Warda: Co jest niemałą liczbą. Wiesz, Azure też tłucze sobie tym użyciem wszystkich pozostałych rzeczy tak naprawdę, całych office’ów, itd.
Łukasz Kałużny: Tak i ostatnią rzeczą, co jest ciekawe, On-Premises or Generic Multi Cloud. I Generic Multi Cloud jest wspomniany 3% tylko w tych ogłoszeniach, co jest już bardzo realnym.
Szymon Warda: I ile firm potrzebuje generycznego multi clouda? Naprawdę bardzo niewiele, trzeba to stwierdzić.
Łukasz Kałużny: To jest bardzo uczciwy, bardzo realny, uczciwy wynik. Dobra, co u Ciebie?
Szymon Warda: Bardzo fajny artykuł. Slack, który migruje swoje testy z Enzyme do React Testing. Jaki mieli problem? Problem taki, że Enzyme przestał być utrzymywany nie za bardzo w nowej wersji, jak to wszystko by działało. Mieli 2300 testów, stwierdzili, że użyjemy LLM-a. Pomysł jest w ogóle bardzo dobry tak naprawdę, jest świetny. LLM-y do tego są świetne, czy to jest przekodowanie z jednego silnika testowego na drugi silnik testowy, czy tak samo jak mamy tłumaczenia między językami, czyli przypadek do wykorzystania jak najbardziej bardzo dobry. Podejście też sensowne, więc zaczęli budować ten model. Fajnie artykuł pokazuje jak budowali cały chain, cały łańcuch, co tam się dzieje, jak budowali prompt, jakie mieli wyzwania, jakie mieli cele, jak to testowali. Bardzo fajny artykuł. Tym bardziej, że wydaje mi się, że ten przypadek jako taki, że będziemy korzystali z LLM-ów do migracji, tudzież upgrade’ów, itd., to jest bardzo dobry, powiedziałbym, że use case jest do wykorzystania. I to może nam fajnie zaadresować dług techniczny w wielu sytuacjach. Ale podali też liczby, wyniki, jak to stało się wydajne. I z 2300 testów, ile testów finalnie uznali, że przeszło na zielono, wszystko porządku? Strzelaj.
Łukasz Kałużny: Ja już zobaczyłem, więc…
Szymon Warda: 500, czyli…
Łukasz Kałużny: 20-22%. Tak.
Szymon Warda: Tak. I szczerze spodziewałem się dużo wyższej wartości, dużo wyższej, tak pod 70% lekką ręką spodziewałem się. Czy to dużo, czy to mało? W kontekście dupogodzin to jest absurdalnie wręcz dużo. To jest naprawdę zaoszczędzone, podejrzewam, że kilka tygodni developmentu. Ale w kontekście oczekiwań to bym powiedział, że jest bardzo mało.
Łukasz Kałużny: Brakuje mi czego użyli.
Szymon Warda: Tak, on nie jest taki super techniczny, ładnie opisują ten łańcuch, co się dzieje, jak do tego podeszli inżynieryjnie, jak do tego podeszli opsowo, to jest faktycznie, nie ma takich super szczegółów, tylko też jest krótki, nie oszukujmy się, nie jest jakieś takie super rozbudowane. Ale polecam.
Łukasz Kałużny: Kusi mnie, żeby zobaczyć benchmark, wiesz, jak ten model, ten model, ten model i w którym by wyszło. To byłoby ciekawe.
Szymon Warda: Mnie kusi co się będzie działo z takimi podejściami za jakiś czas i czy to będzie bardziej popularne? Wydaje mi się, że będzie.
Łukasz Kałużny: Dobra, słuchaj, następna rzecz, to dzisiaj kilka rzeczy LLM-owych. Klasycznie, o wtopach trzeba mówić. Teraz przepiękny Black Pattern od Adobe, który chce zmusić użytkowników do… Content, który jest trzymany na Creative Cloud, czyli z Photoshopów i innych, najbardziej popularna usługa, jeżeli chodzi o trzymanie tych assetów graficznych. Chcą zmusić użytkowników, że wyskoczył popup blokujący płacących użytkowników przed użyciem aplikacji, żeby zaakceptowali nowe termsy. A w nowych termsach wpisali pięknie, że Twoje prace mogą być wykorzystane do trenowania ich genAI-a.
Szymon Warda: Realnie, mają wielki zbiór danych, zapotrzebowanie rynkowe na to, żeby…
Łukasz Kałużny: Przechowują wielki zbiór danych klientów.
Szymon Warda: Wiem, żeby generować zdjęcia jest bardzo duże. Więc to jest taki ruch, powiedziałbym, że dość spodziewany i oczywisty. To, że Adobe nie ma konkurencji, bo nie ma konkurencji żadnej, absolutnie, to może zrobić sobie wszystko, co chce praktycznie, nie oszukujmy się. Pamiętajmy, że to jest też wykorzystane często do bardzo różnych zdjęć i ten zbiór danych, które mają, ok. Nie wiem, czy to nie będzie trochę garbage in, garbage out. Tam będzie też dużo dobrych rzeczy, ale też bardzo dużo słabych.
Łukasz Kałużny: Ale wiesz, to jest ciekawy kierunek. Czyli czekamy, kiedy firmy zaczną się chwalić: nie wykorzystujemy Twoich danych do trenowania modelu.
Szymon Warda: Raczej nie będą. Z takich rzeczy, to bardziej chyba oburzające w kontekście Adobe, też to było parę tygodni temu, jak mieli właśnie do Photoshopa i Light Rooma, czyli do edycji zdjęć, dali dodatek, w którym możesz zmieniać tło zdjęciowe bez potrzeby robienia ponownego zdjęcia. I było bardzo duże oburzenie w społeczności Adobe, że: no kurna trochę za chwilę pracy nie będziemy mieli.
Łukasz Kałużny: To ciekawy feature.
Szymon Warda: Przydatny bardzo. Ale tak to wygląda. Dobra, to ja teraz kolejny. Ciekawy artykuł porównujący jak działają wewnętrznie metryki Opentelemetry, szczególnie w zestawieniu z Prometeuszem. Dość długi artykuł, może nie jakoś piekielnie, ale mimo wszystko dłuższy niż średnia. Czemu przydatny i czemu fajny? Bo faktycznie opisuje internalsy tego, jak metryki są zbierane, jak wygląda agregacja. Coś, z czego sobie często ludzie nie zdają sprawy, to jest właśnie to, że te metryki są agregowane w pewien sposób w takich chunkach czasowych. Fajny, żeby zobaczyć jak to wewnętrznie działa, szczególnie do tego, że z reguły gdzie się patrzy na Prometeusza i ok, to jest to samo. No nie, to działa trochę inaczej. Przy okazji jeszcze dobre nazewnictwo, dobrze tłumaczy co, jak, gdzie i po co, jeżeli chodzi o metryki Opentelemetry. To powiedziawszy tak naprawdę jestem ciekawy jak szeroko się one przyjmą, czy faktycznie to będzie wyglądało tak, że będziemy korzystali z Opentelemetry i add Prometheus Exporter bo tak większość organizacji widzę, że robi po prostu, bo Prometeusz jest mimo wszystko standardem i Opentelemetry nie wygryzie go zbyt szybko, nie oszukujmy się.
Łukasz Kałużny: Tak, sam z siebie jest prosty.
Szymon Warda: Prometeusz?
Łukasz Kałużny: Do setupu, do setupu, takiego zrozumienia, już nie mówię o pisaniu metryk, ale samo zrozumienie Prometeusza jest proste.
Szymon Warda: Tak i jest też bardzo uniwersalne przez scraping endpointów, itd. Opentelemetry jest dużo bardziej ambitne, takie podejście, trochę bardziej jak miał Influx wysyłania, itd. Jest trudne i skomplikowane, to się z tym zgodzę, ale warto zrozumieć. Nie widziałem jeszcze tak dobrze napisanego artykułu, co, jak, gdzie to działa wewnętrznie, więc warto rzucić okiem.
Łukasz Kałużny: Dobra, nie pamiętam czy na odcinku z buildem wspominaliśmy o Recall?
Szymon Warda: Tak, było, było.
Łukasz Kałużny: Było, czyli snapshotowanie ekranu, zbieranie klawiatury, żeby cofać się w czasie, co my robiliśmy na tym Windowsie. Gównoburza z branży SEC-owej wypłynęła na to i jest bardzo szybko, czyli domyślnie będzie to wyłączone. To jest jedna rzecz. Następna rzecz, będzie just in time decription. I teraz tam jest ten Windows Hello, czyli to całe biometryczne odblokowywanie i inne tego typu elementy. I cały ten plik stanu i snapshoty będą szyfrowane za pomocą tego mechanizmu i tylko jak użytkownik jest zalogowany będzie to odszyfrowane w locie.
Szymon Warda: To powinno być tak zrobione od day 0, że tak powiem.
Łukasz Kałużny: No właśnie, ale widzisz, czasami trzeba coś pokazać marketingowo, żeby dostać feedback co trzeba zrobić.
Szymon Warda: W tym przypadku to bardziej powiedziałbym, że łomot niż feedback.
Łukasz Kałużny: Tak, jako użytkownik będziesz wiedział w którym momencie jest robiony snapshot. Te rzeczy, które idą sobie z Digital Rights, które przelatują sobie przez procka i inne rzeczy będą respektowane. In private browsing nie będzie snapshotowany, jak go wykonujesz, czyli już tam trochę inteligencji jest. I będzie łatwy sposób pauzowania, filtrowania, kasowania tych treści po prostu żeby cofnąć się, wykasować. Więc jak ktoś z tego będzie chciał korzystać, to…
Szymon Warda: Włączył byś to?
Łukasz Kałużny: Nie.
Szymon Warda: No właśnie.
Łukasz Kałużny: Chociaż powiem tak, czas,ami tak. Powiem Ci tak przy tym kontekście co bym sobie widział, jeden tylko feature, który bym chciał mieć, żeby mi to rozliczyło konteksty, kiedy muszę zrobić sobie timesheet dla klientów. Taki mój wewnętrzny.
Szymon Warda: Tak, taki dość wąski use case na to, żeby włączyć coś, co obecnie już brzmi lepiej. Ale nie mamy też pojęcia jak to się dokładnie rozwinie.
Łukasz Kałużny: Dobra i pora zamknąć to dowcipem, ten odcinek. To jest sobie firma researchowa Forrester, taki odpowiednik Gartnera. Wydają tam swoje również kwadraciki. I wydali kwadracik dla AI Foundation Models For Language. I Szymonie, uwaga, uwaga! Siedzisz?
Szymon Warda: Stoję bardziej, ale niech będzie.
Łukasz Kałużny: Niech będzie, to żebyś nie spadł. IBM został, podkreślam, AI Foundation Models For Language. OpenAI jest jako strong performer na równi z IBM-em.
Szymon Warda: Daj skalę generalnie, co jest jako najwyższy?
Łukasz Kałużny: Google, odstawiony gdzieś w ogóle do tego, potem Databrics i Nvidia i IBM z OpenAI-em są, a Microsoft jest daleko za nimi z AWS-em. Jako challengers jest MistralAI i następnej kategorii jest jako, to jest ostatnia kategoria, przedostatnia jest między innymi Anthropic.
Szymon Warda: Ja się śmieję, bo najlepszy jest komentarz na Twitterze odnośnie tego.
Łukasz Kałużny: Właśnie tak.
Szymon Warda: Forrester is not a serious company. No doskonale. Nie, raczej wydaje mi się, że w tym zestawieniu faktycznie absurd absurdem pogania. Ale to też pokazuje to, że do tych wszystkich zestawień trzeba mieć dość duży dystans tak naprawdę.
Łukasz Kałużny: Inaczej, IBM płacił prawie tak skutecznie jak Google, żeby ustawić, jakie są wymagania.
Szymon Warda: Ja nie chcę wnioskować co, czemu.
Łukasz Kałużny: Ja mam świetny twitt w tym co zalinkowałem: IBM jest liderem w wypłacaniu wynagrodzeń konsultantom zajmującym się sprzedażą pozycji na wykresach kwadratowych.
Szymon Warda: No tak, to zostawmy generalnie, w tym zestawieniu niech tak będzie i bez komentarza. Dobrze.
Łukasz Kałużny: I tą rozrywką na weekend życzymy miłego dnia i trzymajcie się.
Szymon Warda: Hej!