Transkrypcja
Nowy odcinek i Event Streaming
Cześć Wojtek.
Cześć Michał.
Witaj w odcinku, co do którego numeru eksperci nie są jeszcze zgodni. Czy to będzie odcinek 5, czy 4-coś-tam. Ale to myślę, że wyliczymy jeszcze w trakcie.
To będzie Eventual consistency.
Tak. To jakimś algorytmem to wyznaczymy i na pewno zawartość gdzieś tam dotrze. W każdym razie mieliśmy się dzisiaj skupić na części bardziej takiej chyba praktycznej. Ale zanim dobrniemy do tego, co tam nam wynika z case studies, z tych przypadków, w których mieliśmy okazję uczestniczyć, to jeszcze mamy jeden taki temat gruby. Z tych, powiedzmy, teoretycznych, których nie zdążyliśmy przeorać ostatnim razem. I to jest Event Streaming.
Czym jest Event Streaming?
No i. No i proszę, co to jest właściwie?
Tak, tak, zakończyliśmy cliffhangerem: Event Streaming w następnym odcinku.
Tak było? Kurde, to muszę jeszcze raz posłuchać.
Tak więc streaming zostawiliśmy sobie jako osobny, osobny kawałek, gdyż wymaga troszkę więcej czasu i troszkę większego wprowadzenia, że tak powiem. Ponieważ sam Event Driven… Event Streaming można traktować jako półkę wyżej ponad Event Driven w takim zwykłym, zwykłym podejściu, gdzie nasze eventy rzeczywiście się pojawiają i sterują jakąś naszą logiką. To te eventy, powiedzmy. Nie są jeszcze tak do końca takim obywatelem pierwszej kategorii, ale one oczywiście są jakoś tam ważne. Mogą jakieś nasze procesy wygenerować, jakaś notyfikacja może powiadamiać inne systemy, ale jeszcze nie do końca budujemy, jakby, cały system wokół tych naszych eventów.
Strumień eventów jako element budulcowy
Natomiast Event Streaming to już jest sytuacja, kiedy tak naprawdę stream, czyli strumień tych naszych eventów, już jest pełnoprawną jakby elementem, wokół którego budujemy całą aplikację. To też sprowadza się nawet troszkę i przekłada się na samą architekturę takiej aplikacji. Tutaj bardziej już wchodzimy w takie wzorce jak payment filters. To już niekoniecznie.
Czyli tutaj dopytam jeszcze tak dla porządku, że w tym ujęciu to właśnie ten strumyk naszych komunikatów byłby takim elementem, takim pojęciem domenowym. A nie sam komunikat. Bardziej oczywiście komunikaty jak najbardziej się wpisują pewnie w ramy jakichś tam obiektów domenowych, no bo po prostu głupio by było, jakby nie. Ale ich strumień, czyli to to, co do nas płynie ze świata, czy tam z jakiegoś komponentu przynajmniej, to jest właśnie to, na czym się tu skupiamy.
Grupowe strumienie i krzyżowanie danych
Tak, tak, tak, tak. Tak naprawdę ten strumień danych jasno nam wyznacza. Jakby ten kawałek, nad którym chcemy się skupić, jasno określa jakąś akcję czy interakcję użytkownika, czy systemu…
Czy być może nawet szereg…
…czy może nawet szereg. To tutaj generalnie staramy się to strumienie gdzieś tam, że tak powiedzmy, grupować według akcji, możemy oczywiście dominować, żeby, żeby je wzbogacać i jakoś tam.
Czyli strumienie, nawet liczba mnoga.
Tak, zdecydowanie właśnie o to chodzi. W takim pełnoprawnym streamingu tych strumieni najczęściej będzie więcej. No i będziemy się krzyżować.
No… To już nas uczono, że nie wolno krzyżować strumieni…
Nie wolno. W tym wypadku akurat często będziemy zmuszeni, gdyż. W jednym strumieniu. Nie zawsze będziemy mieli do dyspozycji wszystkie dane. Dotyczy to podjęcia decyzji biznesowych, czy do wykonania jakiejś akcji biznesowej. I tak jak wspomniałem, tego typu aplikacje budujemy też z punktu widzenia architektury. Możemy zbudować już w inny sposób.
Architektura Event Streamingu: Source, Filter, Sink
Najczęściej właśnie punktem wyjścia jest tzw. source. Czy to jest source kafkowy, czy gdzieś tam z jakiegoś innego, czyli źródło, nasze źródło tak, nasze źródło, które poddajemy jakiś tam jakiemuś filtrowaniu. Możemy to kluczowe dać i procesować ten event. Na końcu mamy tak zwany sink. Tutaj polskie tłumaczenie „zlew” to pewnie będzie troszkę mniej…
What are you sinking about?
Dokładnie. Ale koniec końców naszym sposobem nasze wyjście. Czyli po stosowaniu po jakiejś tam transformacji nasz event leci sobie do źródła, który może być. Oczywiście kolejny mikroserwis, kolejny i kolejna kolejka. Czy chociażby, czyli ze strumyka do strumyka, nawet ze strumyka do strumyka, ze strumyka na jakąś trójkę do bazy, gdziekolwiek, gdziekolwiek potrzebujemy.
Świeżość danych i Real-time Processing
To jest też kwintesencja takiego procesowania, ponieważ bardzo często zależy nam, żeby nasze dane były dostępne w taki transparentny sposób, ponieważ wiele różnych elementów systemu, czy też elementów, czy podmiotów organizacji może chcieć korzystać z tych danych i my często nawet nie wiemy, kto z tego będzie korzystał. To oczywiście jest też elementem pewnego wyzwania, gdyż musimy zapewnić oczywiście pewną spójną strukturę i validity tych danych, ale generalnie jakby nasz komponent, nasz jakiś tam kawałek systemu, wypluwając to dane. Pozwala większej ilości subskrybentów na to się zasubskrybować i dalej to przetwarzać.
Ale powiedziałeś o tej ważności danych. One są w kontekście tej domeny, z której wypływają, oczywiście ważne, czyli validne. Tak, oczywiście. No bo to ciężko by było tak, tak zakombinować, taki strumień. Zresztą byłoby to nawet niewskazane, chyba żeby on jakiś wykraczał poza swoją odpowiedzialność.
Tak, tak, tak. To właśnie dlatego będziemy potrzebowali najczęściej skrzyżowania, skrzyżowania tych strumieni, gdyż każdy z osobna ma tylko swój jakiś tam zakres danych.
Zastosowania Event Streamingu: IoT, interakcje użytkownika
To wszystko też, ten streaming, z czego właściwie to się wywodzi? Można powiedzieć. Tak naprawdę im dane są świeższe w rozumieniu właśnie takiego opóźnienia. Kiedy my je dostajemy, dane są świeższe, im szybciej jesteśmy w stanie. Gdzie dostać. Tym z większą dokładnością możemy podjąć jakieś decyzje biznesowe. Czyli to jest w opozycji do takiego procesowania bankowego, gdzie generalnie mówię tak, pobieramy te dane z pewnym opóźnieniem, czy trafiają one do naszych podsystemów z pewnym opóźnieniem. Natomiast w takim procesowaniu właśnie strumieniowym założenie jest takie, że te eventy docierają do nas w takim czasie zbliżonym do rzeczywistego. Dzięki temu możemy bardzo szybko rzeczywiście wykonać jakąś logikę biznesową i podjąć jak najlepsze decyzje biznesowe. No, najlepszym przykładem są chociażby jakieś dane z czujników IoT, jakieś pozycje z czujnika GPS, interakcje usera na stronie, jakieś kliki czy chociażby jakieś inne interakcje, które wynikają z aktywności użytkownika.
Dane ciągłe i ich przetwarzanie
I teraz mając dostęp do tych danych w czasie. Zbliżonym do rzeczywistego. Wiadomo, zawsze jest jakieś opóźnienie. Możemy w jakiś rozsądny i łatwy sposób wykonać na nich jakąś operację, jakąś transformatę i podjąć dalsze decyzje biznesowe czy przyczyny, czy zareagować w jakiś rozsądny sposób.
Wyzwaniem oczywiście jest to, że te dane spływają nam ciągle. To jest też ta różnica pomiędzy takim zwykłym Event Driven Architecture a tym streamingowym podejściem. Bo generalnie ono, jeśli w naszym systemie mamy notyfikacje eventu, który mówi nam, że user zapisał sobie profil czy coś takiego i to co widać raz na kilka dni… No ti wiadomo, że ciężko z tego wywnioskować coś bardziej konkretnego w czasie rzeczywistym, bo sama jeszcze tego, że tego eventu…
…user jest trochę leniwy. Bardzo często zapisuje ten tag, więc wiadomo, że z tego to raczej dużo sobie nie wywnioskowałem.
Skala i narzędzia do Event Streamingu
Natomiast tutaj mówimy o przypadkach, gdzie rzeczywiście te akcje w tym świecie rzeczywistym są po prostu w trybie ciągłym i z dużą częstotliwością. Dopiero wtedy możemy sobie rzeczywiście to procesować w takim trybie ciągłym.
Bo tym też się charakteryzuje ten przykład z IoT, który podałeś. To jest w sam raz ilustracja do tego, bo tam leci mnóstwo danych cały czas.
Dokładnie. Dokładnie, tam nawet mamy zależy na tym, żeby było mnóstwo danych i my musimy coś w sobie z nich wykrzesać ciekawego.
Tak. Tam nawet mamy ten problem, że tych danych jest za dużo, więc często do takiego zastosowania strumieniowego musimy wykorzystywać filtrowanie. Musimy wykorzystywać windowing, czyli zawężanie okna, dla którego te eventy agregujemy. To też są czasem jakieś…
…transformacje, o których wspomniałeś w tych oknach. Być może nawet tak, bo jakieś wartości z tego wyliczyć w locie.
Analityka na strumieniach i wykrywanie anomalii
Dokładnie, dokładnie, bo tych danych czasami jest aż za dużo, żeby tak od razu je i procesować, ale w związku z tym, że one przypływają do nas ciągle, mają też, to jest nieograniczony strumień tych danych do tego. No, są do tego też osobne, że tak powiem, techniki, technologie, żeby, żeby te daty się kłania podejście, reaktor procesować. Tak, tu się kłania podejście reaktywne.
Tu się kłaniają, tu się kłaniają rzeczy jak Apache Flink czy Amazon Kinesis Data Streams, czy odpowiednikiem też w chmurze Microsoft, Microsoft. Generalnie tego typu narzędzia wspierają właśnie te tego typu processing. To już nie jest zwykła aplikacja trójwarstwowa, gdzie mamy nasz standardowy i coś tam próbujemy w tym w tym zrobić. To zwykle wymaga troszkę innego podejścia. To też wymaga skalowalności naszych komponentów, gdyż strumienie tych danych wiadomo, że może być dużo i one też często występują w pewnych plikach, czyli wtedy, kiedy nasi użytkownicy czy nasze czujniki powiedzmy czy cokolwiek innego te dane wysyła ze zmienną częstotliwością, to nasze systemy też muszą być, muszą być do tego do tego przygotowane, żeby łatwo sobie z takim nawałem danych wrażeń.
Przykład z parkiem rozrywki i usługami streamingowymi
Po prostu wpuściliśmy hordę wygłodniałych dzieciaków do parku rozrywki. No i wtedy zaczyna się dziać np. tak.
Tak jak w naszym, tak jak w naszym systemie z parkami rozrywki, gdzie mieliśmy przykładowo się czujników IoT. I teraz kwintesencją właśnie takiego podejścia i obróbki strumieni jest też to, że właśnie różne komponenty, różne elementy w naszej organizacji mogą być zainteresowane tymi strumieniami na swoje własne potrzeby, które często są różne w zależności wiadomo od danego już use case’a.
I takim fajnym chyba przykładem jest taka funkcjonalność, którą ma praktycznie każdy powiedzmy dobry video streaming, usługa streamingu, czyli wznawianie oglądania. Tego typu funkcjonalność zwykle robi się poprzez wysyłanie co jakiś czas eventu na zasadzie: hej, jesteś w takiej sekundzie, w takiej minucie danego contentu, danego materiału i to eventy powolutku spływają w czasie jak sobie oglądasz dany, dany kawałek i dzięki temu. Dane, dane, dana usługa streamingu łapie, kiedy, kiedy wznowić. Jeśli wrócisz do oglądania jakiegoś materiału. I to jest podstawowa rzecz.
Wnioskowanie i skalowalność w streamingu
Tak to robią w tym Disney.
Tak, nie tylko w Disney, Netflix i w innych zapewne też. Wznawianie oglądających to tylko jedna funkcja, nośnik, która dzięki temu może być zrobiona. Bo zobacz, że tego typu eventy bardzo łatwo. I też tak Netflix m.in. to wylicza. Służą do mierzenia oglądalności danych materiałów źródłowych. Netflix nawet zmieniał swoje metryki na zasadzie, że jeśli obejrzysz tyle i tyle minut, to my traktujemy, że Ty obejrzałeś ten film czy odcinek już w całości.
To chyba wyłączyli to dla Wiedźmina, co?
Tak, możliwe, albo skrócili ten czas. Jeśli zleciały 2 eventy, to już coś zaliczone.
Business Value z Event Streamingu
Czyli Drwal miał jednak rację.
To już zostawmy sobie na inny odcinek podcastu, ale generalnie zupełnie osobne komponenty. Może dzięki temu zliczać faktyczną oglądalność naszych materiałów na naszej usłudze streamingowej. Inny komponent zlicza sobie i agreguje, w którym miejscu wznowić materiał źródłowy, który sobie oglądasz. Może jeszcze inny komponent będzie zliczał? Jakąś opłacalność. Podsumowanie finansowe dla jakiegoś działu. Jeszcze inny będzie mierzył, co Cię interesuje, bo jeszcze miałeś tutaj.
Znaczy, że straciłeś zainteresowanie.
Dokładnie, koniecznie, bo mogłeś np. wyjść gdzieś tam do sklepu. Cały, cały machine learning czy ogólnie wnioskowanie na podstawie tych eventów, gdzie zostało zaplanowane, gdzie zostało, ile sekund czy minut danego materiału zostało obejrzane. Albo np. czemu przewijać non stop do tej sceny, albo czemu przewijać. Dokładnie. Netflixowi to służy bardzo mocno, bo do takiego tworzenia. Może nie profili, ale pewnych wzorców, co się dobrze ogląda, co się dobrze sprzedaje. To są bezcenne dane tak naprawdę dla tego tego typu usług, coś, co jest tak naprawdę niedostępne w jakiś taki normalny.
Nie da się zdjęte z żywego organizmu.
Tak, tak, tak, tak i właśnie. Ale to jest jakby też kwintesencja, że ten jeden strumień danych wędruje do zupełnie różnych zainteresowanych komponentów, służy do zupełnie różnych funkcjonalności i gdzieś tam to sobie działa we wspólnym organizmie.
Event Sourcing a Event Streaming
No bo proszę popatrzeć, to tak jakby taki event sourcing troszkę na sterydach. Nie? Bo te eventy. One są na pewno zbierane, skoro później ktoś tam coś tam z nich robi, ale one zapisują się w czasie i jak się zapisały, to. Ktoś już wstanie.
No tutaj może taka mała różnica. Czym się właściwie taki event sourcing od takiego event streamingu różni? Bo i to i to jest na event something. Tak jak mówiliśmy w poprzednich odcinkach, bardziej tam mówi o tych eventach i o takim budowaniu naszego modelu. Źródła prawdy, źródła prawdy. Sourcing to jest od tego źródła. Tak, tak.
Natomiast streaming tak naprawdę tutaj nic jeszcze nie jest powiedziano. Równie dobrze i tak się często dzieje. Te komponenty nawet nie muszą nic protestować, one po prostu obrabiają. Dane event dane, strumień przesuwając gdzieś dalej. Może coś tam sobie w lokalnym stanie zapisują, może gdzieś coś wrzucają, a mogą nawet event sourcing stosować pod spodem, jak chcą, a to już za rozłączne element.
Kiedy stosować Event Streaming?
W tym momencie streaming polega tylko jakby jego kwintesencją dostarczaniu do strumienia i odrabianiu wysyłaniu dalej. Ktoś to może podłapie, jak ktoś może to może sobie coś dalej z tym, z tym zrobi. Więc jeśli mamy tego typu aplikacje, gdzie rzeczywiście jest ciągła interakcja, ciągły ruch, wiele się faktycznie dzieje w czasie rzeczywistym, no bo to jest za modelowanie pewnych pewnego konceptu, który mam, aplikacji, który się dzieje w czasie rzeczywistym.
Oczywiście nie mamy takich akcji, czyli po prostu mamy zwykłą aplikację klubową, user sobie coś tam klika raz na jakiś czas i zapisze to tutaj, może z tego niewiele wyciągniemy, poza może jakąś analityką na zasadzie. Coś tam się kliknęło w tym czy w tym miejscu i tyle. Ale tutaj może nie być miejsca na wnioskowanie z tego czegoś więcej.
Natomiast w rzeczach jak streaming wideo, jak wszelkie usługi bardzo teraz popularne w taksówkach na zasadzie Ubera i tego typu rzeczy. Tam tych strumieni krzyżujących się na pewno jest bardzo wiele.
Skala i kontekst biznesowy
Musi być przede wszystkim dużo rzeczy, które się dzieją, czyli takich generatorów eventów.
Dokładnie. Dokładnie musisz. One robią to strumieni dokładniej, musisz mieć konieczność biznesową łączenia tych strumieni i tych danych wynikających z tych strumieni. Czy strumień chętnych na zamówienia taksówki, strumień z dostępnymi taksówkami, kolejny pewnie jakiś strumień z przeliczanie kwoty za dany przejazd, który zależy od. Spróbuj na promocji Jumbo godziny. Jaka jest obecnie wiosna?
Daje to fajny przykład na to, że to strumieniowanie ma wtedy sens, kiedy jest skala tego odpowiednia, bo jak byśmy mieli 5 taksówek w Pcimiu Dolnym czy Górnym, już nie wiem dokładnie, i tam 12 klientów, no to tak by nie bardzo to strumieniowanie wyglądało.
Wykrywanie anomalii i nieinwazyjność
No tak, bo wtedy możemy tak, jak mamy takie Uber, który jest o zasięgu światowym, to pewnie te serwisy to tam nieźle się grzeją. No tak, tak to jest. Skala tutaj jest podstawą, Jeśli mamy skalę niewielką i niewielką tak naprawdę ciągłość tych eventów, no to możemy to standardowymi praktykami zrobić i nie musimy ładować się w zupełnie nowe architektury, które nie muszą być też takie proste od razu.
Natomiast tego typu, tego typu rozwiązania, jak przeglądanie w locie eventów, możemy też wykorzystywać do wykrywania anomalii chociażby w użyciu naszego API. Ten przykład z tym strumieniem eventów z oglądania. Możemy sobie wyobrazić, że jeśli teraz do jakiegoś użytkownika takich strumieni z oglądania jest więcej niż jeden, to znaczy, że ogląda na więcej niż jednym urządzeniu. Może to nie jest to samo, może to nie jest dozwolone w jego pakiecie. Może ten strumień tak naprawdę leci non stop przez X ileś tam godzin? No to też podejrzane. Ktoś ogląda tego Wiedźmina 24 godziny na dobę?
Analiza Legacy Systemów za pomocą Event Streamingu
Jak to było uderzone? Szczerze, ja bym nie oglądał.
Ale właśnie monitorowanie wszelkiej maści anomalii w zachowaniach użytkownika, anomalii w wykorzystaniu API, jakichś podejrzanych transakcji. Jeśli mamy do dyspozycji strumień transakcji, czy to finansowych, czy jeszcze takich bardziej wrażliwych operacji, to są to. Są też to takie przypadki użycia, które dobrze się nadają do takiego na bieżąco monitorowania i sprawdzania, czy rzeczywiście te wzorce zachowań, wzorce użycia są w ramach założonych, czy to się aż.
Aż się tutaj prosi chyba o podpięcie do tego przykładu z poprzedniego odcinka, gdzie mieliśmy np. podsłuchiwanie tego, co się tam na bazie dzieje. Mamy ten legalny system 30-letni, nie wiadomo o co chodzi. I podpinamy się jakimś zgrabnym narzędziem do jego bazy. I nagle się okazuje, że lecą sobie jakieś strumienie zdarzeń i wtedy np. odpalamy to nasze. Takie sprytne wnioskowanie. Co tam się może właściwie wyrabiać? Z tym starym systemem to możemy rzeczywiście w łatwy sposób już podpiąć nawet do istniejących systemów.
Statystyka i wnioskowanie z danych
Rzeczywiście, jeśli i tutaj zrobimy sobie to przez DC, to jest też jakieś wyjście, to możemy mieć troszkę większą trudność z interpretacją tych danych, bo jednak. One de facto nie będą, że tak powiem, może takim jasnym strumieniem o dobrze zdefiniowanej funkcji czy roli, no bo to jest raczej podpięcie się po prostu pod jakąś tabelkę, pod jakiś zbiór danych, więc tu niekoniecznie ona musi mówić o pewnym ciągu operacji.
Ale tutaj. Ale tutaj bardziej jakieś dane statystyczne mogą występować. Czyli np. że mamy. Ileś tam transakcji na sekundę określonego typu, a innego typu mamy dużo mniej. I dlaczego? Podoba mi się w biznesie, że jednak powinno to wyglądać inaczej, a tutaj życie nam pokazuje, że coś tam się dzieje i może coś jest na rzeczy, że tak się dzieje. Możemy z tego zechcieć jakieś wnioski wyciągnąć i pójść z tym gdzieś wyżej, niżej i coś zmienić.
Zaletą Event Streamingu: praca na boku
Jak najbardziej. Na pewno będzie to w części przypadków lepsze niż po prostu jakieś tam bankowe albo zgadywanie. Po prostu zgadywanie. To już w ogóle loteria, jaką kulę dobrać do tego wróżenia.
Tak jak zawsze problem możemy. Na pewno zaletą tego jest, że możemy cokolwiek byśmy chcieli robić. Czy to będzie to wykrywanie anomalii, czy czy może próba modelowania jakiegoś innego procesu biznesowego. Możemy to zrobić na boku, to jest najważniejsze w tym. W tym rozwiązaniu nie musimy tego robić na tym naszym żywym systemie. Gdzieś tam w naszym kolejnym serwisie, który dokładamy do kupki naszych serwisów. I nagle powstaje nam chęć zrobienia, wykrycia anomalii czy czegokolwiek i musimy to dorzucić do tego naszego systemu. A to jest w ogóle może nie być zupełnie odpowiedzialności nieinwazyjne.
Tak, możemy dzięki temu zrobić mniej inwazyjne rozwiązanie. Możemy szybciej to rozwiązanie dostarczyć. Możemy je zaprojektować bez prototypowania, znacznie szybciej, bo możemy to zrobić na boku, czyli jakoś bez stresu, z mniejszym ryzykiem.
Wyzwania systemów rozproszonych i Event Streamingu
Całkiem to sprytne, trzeba przyznać.
Całkiem to sprytne, ale jest to również sprytne coś, co też trudno. Czasami chyba możemy też przejść w ten sposób do wyzwań. Ze wszystkich sprytnych rozwiązań, które. Kogo dzisiaj wzywamy? I od czego? No cóż. No więc takiego to już wezwaliśmy od trudności.
Lista kandydatów jest długa. W dużej mierze może się pokrywa z ogólnie z problemami, które się wiążą z systemami rozproszonymi. Bo wiadomo, jeśli coś jest rozproszone, to trudniej jest wnioskować na temat działania danego systemu. Trudniej jest tego typu systemy debugować, monitorować. No i trzeba sobie jasno powiedzieć, że eventy latają jest fajniej i procesy jakieś tam się dzieją. Ale żeby mieć wgląd w taki rozproszony proces, którym sterują czy jakoś inaczej popychają eventy, no to musimy też mieć do tego odpowiednie narzędzia i infrastrukturę i pewnie też jakieś DevOpsowe narzędzia, które nam pozwolą te wszystkie narzędzia wdrożyć, żeby to wszystko zatrzymać. No i jeszcze dużo cierpliwości, żeby to wszystko poustawiać. I żeby to zaczęło nam wreszcie pokazywać to, co chcemy.
Eventy jako źródło informacji
Zapewne nie, ale tak, tak przez kontrast to też jakbyśmy mieli taki rozproszony system, ale pisany w starych architekturach i starych podejściach, gdzie polega się na stanie aktualnym na tych naszych przodkach. Gdzieś tam z dawien dawna wzmiankowanych. To wcale by nie było łatwiej, oprócz tego, że mielibyśmy złożoność pewnie DevOpsową tego wszystkiego podobną, to jeszcze nie mielibyśmy informacji o tak naprawdę o wnętrznościach tego całego ustrojstwa.
A tutaj mamy. Tutaj latają nam te eventy. Więc nawet jeżeli teraz, dzisiaj nie jesteśmy w stanie przerobić ich wszystkich, ale je sobie zrzucimy gdzieś do jakiegoś worka i leżą sobie w piwnicy i czekają, później możemy je odtworzyć i znowu w nowej maszynerii wpuścić te strumienie, powiedzmy, jako coś świeżego i tam sobie na nich strumieniować.
Atomowość transakcji i Event Sourcing
No tak, ale to wszystko tak naprawdę zależy od tego naszego biznesu, którym się zajmujemy. Ciężko sobie wyobrazić. Wracając jeszcze do tej analogii z serwisów streamingowych ciężko sobie wyobrazić takiego Netflixa czy Disney Plusa jako jakiś wielki monolit, no bo tam się zwyczajnie pod spodem dzieje za dużo rzeczy, żebyśmy to byli w stanie ogarnąć jakimś jednym komponentem. Siłą rzeczy musi to być realizowane przez wiele elementów systemu i w miarę niezależny sposób. Bo tych rzeczy po prostu jest za dużo. Skala jest za duża, liczba użytkowników jest za duża i to jest też system, który działa. Działa tak naprawdę na całym świecie, więc wiadomo, że słońce nigdy na nim nad nim nie zachodzi, jak na Imperium Brytyjskim, więc wiemy, że grubo.
Więc wiemy, że to tak naprawdę 24 godziny na 7. No cały czas musi być dostępny, przygotowany na napiwki użytkowników, więc tutaj tutaj. Siłą rzeczy też musimy być gotowi na złożoność.
No tak po prostu z definicji musi być rozproszony, żeby działał sprawnie.
Tak, to jest, musi być nieodłączny element, to ta złożoność. Ale za tym też właśnie idą, idą te wszystkie funkcjonalności, które możemy w ten sposób używać, czasami nawet nie zdając sobie sprawy, co się pod spodem dzieje. System rekomendacji, tego typu rzeczy to jest. To jest po prostu złożoność danego biznesu.
Rezyliencja eventów i wzorce
Natomiast. Mając troszkę mniejszy system, ale też próbując iść w tą stronę. Możemy też mieć. Nawet jeśli będzie to mniej komponentów technicznych. Ale może mieć też takie podstawowe problemy jak chociażby rezyliencja tych naszych eventów w kontekście np. atomowości. To jest też bardzo częsty. Często problemowe. Jeśli mamy naszą transakcję nową i mamy nasze eventy, to chcemy jednak zapewnić atomowość z tych transakcji. I to jest. To jest częsty, częsty problem i często się o tym zapomina. I to może prowadzić do rozpuszczenia jednak czasami danych.
No bo jeśli transakcja z jakiegoś powodu się wycofa, to co z tym eventem? Czy on musi pójść? Jeśli transakcja została wycofana, znaczy ta akcja jest zakończona niepowodzeniem, więc pewnie event też nie powinien nam polecieć. Więc tutaj warto pamiętać o granicach tych naszych, takich biznesowych.
I co robimy z taką wtedy komunikacją synchronicznym? Co robimy z tymi eventami? Tutaj wszelkie patterny w stylu inbox pattern i zapisywanie eventu do bazy i później go w uzyskiwanie i. I wysyłanie już poza commitowaniem transakcji czy chociażby narzędzia CDC. Tutaj mówiliśmy o Debezium. Właśnie możemy fajnie to zintegrować z na przykład mając Dynamo DB. Jednocześnie jest integracja z Kinesis Data Stream, która automatycznie nam właśnie poprzez CDC wysyła wysyła eventy, więc mamy tutaj do dyspozycji bardzo wiele rozwiązań, żeby to zagwarantować. Spójność zapisu i jednocześnie wysłania eventu.
Semantyka dostarczania i kolejność
No i mamy też ileś tam utrudnień, bo np. moglibyśmy wysłać taki event dwa razy, dajmy na to w lub więcej. Nie, bo jeżeli mamy czkawkę gdzieś tam pod spodem i już myśleliśmy, że. Że do tego jesteśmy, że jeszcze nie wysłaliśmy, a tu nagle się okazuje, że wysłaliśmy trzy razy, a my jeszcze ileś razy dokładamy, to może być z tego problem.
No tak, czyli semantykę delivery, czyli. Czyli co tak naprawdę wspieramy? Czy to musi być w naszym wypadku, czy może być? Może być większa ilość? Czy klienci, którzy korzystają z naszego systemu, którzy korzystają z naszych eventów, mogą przetwarzać ten sam event dwa razy? I czy to będzie miało znaczenie dla nich? Czy to będzie ten sam wynik, czy może coś się zmieni? To są też rzeczy, które trzeba pewnie w każdym kontekście rozważyć i zastanowić się co jeśli, co jeśli ten event przejdzie dwa razy? Co jeśli te eventy przyjdą w różnej kolejności?
Idempotencja i ewolucja schematu
To też jest bardzo często jakiś tam ważny, ważny element i ta kolejność. Zakładamy zawsze, że wszystko jest ok. Kolejność jest dobra, ale jeśli przejdę coś w innej kolejności, to może to też wpłynąć na nasz proces. Tutaj kolejki jakieś tam mają Kafki czy Kafka ma. Ma do dyspozycji narzędzia, które pozwalają nam zagwarantować kolejność w ramach danej partycji. Czyli przy odpowiednim próbowaniu naszych eventów mamy pewność, że trafią na tę samą partycję i tam kolejność będzie zagwarantowana.
Podobnie w SQL-owym również możemy sobie ustawić kolejkę z odpowiednią kolejnością, ale to są też zwykle ograniczenia, które nam wpływają troszkę na przepustowość tego typu kolejek, bo wiadomo, że musimy wtedy ograniczyć się do. To jest kwestia odpowiedniego rozdzielenia naszych naszych eventów, bo też trzeba o tym pamiętać i w zależności od naszego stylu zastanowić się, czy to jest ważne, czy ta kolejność dla nas jest. Bo może się okazać, że w niektórych przypadkach użycia po prostu wystarczy zagwarantować taką cechę tych komunikatów, jak idempotencja, idempotencja może nawet i handlerów, czyli po prostu odebranie tego samego komunikatu więcej niż jeden raz nie zmienia stanu systemu, bo już pierwsze odebranie, tak jak wszystkie kolejne wprowadzają go w pożądany stan. I tyle.
Kanoniczny format i jakość danych
Czyli. Ale to jest też chyba taka wskazówka ogólnie dla systemów jakkolwiek tam sterowanych albo wykorzystujących chociażby komunikaty, żeby nie traktować tych komunikatów jakby były. Jakby musiały być przetwarzane implementacje, bo wtedy to jest proszenie się o problemy. Wtedy na pewno musimy już mieć zagwarantowane, że ta kolejność jest dobra i że ilość ich w ogóle jest dobra.
No tak, tak, tak, tak. Bo czasami możemy kolejność wywnioskować z samego samego komunikatu, więc to możemy sobie lokalnie posortować i jakoś to sobie zagwarantować. No ale nie zawsze to jest takie możliwe.
Kolejnym problemem. Problemem jest też sama struktura tych naszych naszych eventów. Bo jednak. Musimy, musimy. Po pierwsze to pewnie będzie bardziej widoczne w jakiś większych organizacjach i właśnie w przypadku np. tego event streamingu. W jaki sposób zagwarantować, że wszystkie strumienie czy wszyscy producenci naszych eventów podlegają tym samym ograniczeniom na zasadzie struktury danych? Czyli zwykłego formatowania eventu. Jak wygląda ta koperta naszego eventu? Powiedzmy?
Ewolucja schematu i Avro/Protobuf
Pewnie dobrze by było ustalić jakiś wspólny schemat. Dobrze byłoby założyć albo wiedzieć, że zawsze mamy jakiś nagłówek, zawsze mamy jakieś metadane. Payload wygląda w ten czy inny sposób. Jak wygląda sama jakość danych? Czy jesteśmy pewni, że systemy produkujące tę jakość, produkujące eventy, zawsze te eventy mają odpowiednią jakość? W sensie, nie są, są dobrze sformatowane, zawierają poprawne dane, tak żeby nie psuć konsumentów, którzy korzystają z tych, z tych eventów.
No bo my, jako twórca takiego eventu, możemy nawet nie być świadomi i nie jesteśmy zwykle, bo o to chodzi, że pod spodem działa ileś tam tych klientów, konsumentów naszego eventu, robiąc coś biznesowego z tym eventem. No i my musimy. Zrobić wszystko, żeby to, co wyprodukujemy, nie zepsuło innych, innych konsumentów. Chociażby taki najprostszy poziomy dobrego sformatowania i dobrej struktury tego eventu.
To też jest ważne w kontekście ewolucji tego schematu. Wiadomo, z czasem pewnie byśmy chcieli jakieś pole dodać, może coś zmienić nazwę, może jakieś pole usunąć. Część z tych zmian to są takie breaking changes, coś, jakieś wersjonowanie, czyli pewnie jakieś wersjonowanie mile widziane. Generalnie pewnie jakiś większy Schema Registry czy czy jakieś miejsce, gdzie te modele są w miarę w miarę w miarę, ze tak powiem, określone.
Protobuf i bezpieczeństwo danych
Może autogenerowane? Może, może jakiś Protobuf, który fajnie w takim meta języku opisze nam ten model, a my tylko weźmiemy i wygenerujemy w naszym języku, w naszym. W naszym systemie to jest fajne, bo ma integrację z wieloma językami. Możemy sobie wygenerować kod na podstawie takiego właśnie prostego opisu danego obiektu i w różnych systemach możemy współużywać danego danego obiektu i tam jest.
On też nie jest taki zły. To jest. On też nie jest taki zły, ale wiadomo to samo jeśli chcemy mieć troszkę więcej wydajności. Proto jako binarny format jest może ciut bardziej skomplikowany. To zepsujemy w locie i oczywiście możemy czytelniejszy dla człowieka. Taki tak jest typowany.
Kanoniczny komunikat i RODO
No raczej. Ale to np. w kontekście zapewnienia takiego schematu dobrze rozumianego, dobrze zdefiniowanego, to już nasi pradziadowie tak ze 20 lat temu na oko. Jak tam były rozważania snute o takim wdzięcznym wynalazku ESB? Enterprise Service Bus ukuli pojęcie postaci kanonicznej komunikatu, bo tam już wtedy przewidywano w różnych tam szynach danych. Zresztą to z tamtych czasów jest chyba właśnie ten termin przeniesiony teraz do naszych.
No i jak była sobie taka korporacyjna szyna danych, do której różni tam producenci mogli się podpinać i tam chciałem powiedzieć strumieniowanie, ale to jeszcze chyba za wcześnie było. Trzeba tam po prostu wysyłać jakieś tam swoje komunikaty, to dobrze by było, żeby one były czytelne dla całej infrastruktury. Więc musiały być opakowane chociażby w jakąś jednolitą kopertę, czyli w zestaw metadanych, które opisywały, co to właściwie za komunikat, skąd pochodzi, co można z nim zrobić, kiedy się zaciął i w ogóle tego typu rzeczy. Czyli to, to wszystko byśmy teraz przenieśli do tego nowego świata, naszego obecnego. I pewnie chciałoby to jakoś działać w ten sposób, żeby, żeby przynajmniej można było. Każde nowe źródło takich komunikatów, które by chciało coś nam tam nowego wrzucić, zrozumieć.
Bezpieczeństwo/prywatność danych i zapomnienie użytkownika
Tak, tak, tak. Wtedy to troszkę inaczej na to patrzono. I rzeczywiście nie wszystkie te wszystkie te wymagania czy obostrzenia były aż tak ważne. Tutaj pewnie też warto przytoczyć, przytoczyć wszelkie względy bezpieczeństwa czy data security, data privacy też danych. No bo w dzisiejszych czasach wiadomo, wszelkie wszelkie ograniczenia w stylu RODO czy chociażby zabezpieczenia naszych danych. Po to musimy też wiedzieć, żeby zapewnić, że nasza cała komunikacja będzie też będzie też bezpieczna.
In-transit, czyli także kanał komunikacyjny, musi być zabezpieczony, zaszyfrowany, ale też miejsce, gdzie ewentualnie będziemy przechowywać te eventy, czyli właśnie adres. Ono też musi być, musi być bezpieczne. No i też musimy wiedzieć, że jeśli coś już wyślemy w świat, to to już może my w świecie gdzieś pozostać, więc na pewno pozostanie i na pewno pozostanie. Więc Więc dobrze też jakby pod tym kątem i rozważyć, czy rzeczywiście nie wysyłamy może jakichś danych wrażliwych.
Co zrobić, jeśli nagle w systemie przyjdzie nam request o zapomnienie użytkownika? Czy my musimy teraz jakoś te eventy pozbierać, je pousuwać?
Mark mówi: zapomnieliśmy i wszystko.
No właśnie. Ale jeśli użytkownik powie, że chce mieć paczkę ze swoimi wszystkimi danymi, które macie w systemie, to musimy pewnie pozbierać taką. Iluś set głową paczkę naszych eventów. Zapomnianych, zapomnianych. A jednak przypomniało nam się, bo one tam leżały w szufladzie.
No właśnie. Więc to są też aspekty, które jeśli mieliśmy tylko bazę danych, no to nie było problemu. Robiliśmy SELECT * FROM i zaraz mieliśmy wszystko na temat użytkownika. Ale jeśli to gdzieś poszło w świat w postaci eventów, to też pewnie warto sobie zadać to pytanie, czy my jesteśmy w stanie kontrolować te nasze strumienie, czy w ogóle musimy? Bo to może są dane anonimowe albo limitowane na tyle, że nie musimy.
Można powiedzieć, że po prostu nikogo to nie boli, że nikogo to nie boli, że nie da się zaszyfrowane. No bo weźmy taki blockchain na przykład. To tam są, niezależnie od tego, do czego go tam pewnie wykorzystujemy, ale można sobie wyobrazić sytuację, kiedy faktycznie są tam dane wrażliwe, ale one są zaszyfrowane odpowiednio mocnymi algorytmami, z dużymi kluczami, odpowiednio przyjemnymi. I uważa się, że złamanie tego jest na razie, przynajmniej dla komputerów kwantowych, średnio opłacalne. Chciałem powiedzieć nieopłacalne, ale wiadomo, że tam różnej maści ataki się zdarzają cały czas. W każdym razie ten, ten, to rozwiązanie zastosowane tam to to jest też może jakaś sugestia, jak moglibyśmy zabezpieczać nasze dane.
Tak, to już podpis za pomocą jakiegoś szyfrowania. To już może być taki dość najmocniejszy przykład. A no, rzeczywiście tak. To, to, to pewnie jest średnio jedno z rozwiązań. Najprostsze tak naprawdę jest pewne ograniczenie zakresu danych, które gdzieś tam wysyłamy i albo przynajmniej niemożność identyfikacji i powiązania tych danych z jakimś konkretnym użytkownikiem. I pewnie to wystarczy jako jako jako element, powiedzmy, takich prywatności danych.
Krzyżowanie strumieni i wzbogacanie danych
O właśnie, niemożność ich powiązania. Na pewno dobra rzecz, ale czasem możność ich powiązania to jest jeszcze lepsza rzecz. Bo jak mamy teraz, chciałbym wrócić do tego krzyżowania strumieni. Jak mamy te strumienie, które tam sobie latają stąd, tam z powrotem i je krzyżujemy, to po czym musimy to skrzyżowanie połączyć i rozpoznać? Ja czyli tutaj jakieś pewnie dane relacyjne by się przydały w tych naszych modelach danych.
Bo tak. Otóż będą takie dane techniczne, czyli jakieś ID, jakieś przez system, a dane identyfikatory i to są już to nie będą dane wrażliwe w rozumieniu RODO. Znaczy tu będziemy bezpieczni, można by karty kasować, można by od tych problemów nie tylko chciałem wrócić do tego, co wcześniej opowiadałeś o tych takich szybkich, bardzo dużych strumieniach, które musimy w czasie rzeczywistym przetwarzać. Ale to nie wystarczy, że one sobie zawierają jakieś tam przypadkowe dane. Bo jeżeli musimy połączyć dane z jednego strumienia z drugim strumieniem, to dobrze, jak byśmy mieli jakieś kryterium, na podstawie którego się łączą.
Oczywiście tak. Tak, to jest podstawa, bo ten tzw. enrichment, czyli wzbogacanie jednego strumienia o dane z jakiegoś innego źródła. Wiadomo, musi nastąpić punkt zaczepienia, musi mieć punkt zaczepienia. Nie da się po prostu wziąć dowolnego strumienia i połączyć z dowolnym rozwiązaniem. Tylko, że to nie będzie miało sensu. Żadnego. Tak, to zwykle to. To jest jakiś kontekst, czy to użytkownika, czy jakiejś transakcji, czy jakiegoś innego elementu biznesowego, który w różnych. Że tak powiem, skutek naszego systemu ma różne właściwości, które chcemy, chcemy połączyć. Zawsze jest jakiś kontakt i właśnie po tym kontekście staramy się to łączyć i wzbogacić te dane tak, żeby czy to ten komponent, czy jakieś komponenty niżej nas kupujące miały z tego jakiś sensowny zestaw danych wzbogaconych. Dokładniej, podobna technika.
Correlation ID i procesy biznesowe
W tych przykładach z poprzedniego odcinka mogłoby mieć zastosowanie. Jeżeli np. w takim systemie opartym o CQRS i Event Sourcing chcielibyśmy jakiś proces biznesowy zamodelować, to. Wprawdzie nie wspominaliśmy o tym poprzednio, ale tutaj bardzo ważne jest, żeby wszystkie komunikaty w obrębie tego procesu miały ten sam Correlation ID tzw. To jest taka może dość często używana nazwa na taki element łączący te wszystkie rzeczy, ale ponieważ one mają różne typy i różną. Różne odpowiedzialność, różny zakres działania, ale mimo wszystko musimy je w którymś momencie zebrać w jeden taki strumień. Nie w rozumieniu takiego event streamingu, o którym mówimy dzisiaj, tylko po prostu strumień komunikatów, który opisuje, jak powinien proces ten proces biznesowy dla danego agregatu biznesowego o określonej tożsamości. To wtedy też musimy je połączyć i to na różnych poziomach. Ten wzorzec inaczej pewnie by nie wyglądał, ale naturę ma podobną.
Tak, tak. No to powiem tak, jak mówisz, to jest też pewne łączenie i pewna agregacja tych eventów, ale troszkę innej płaszczyźnie, w płaszczyźnie procesu biznesowego. Natomiast taki event streaming, no to tutaj najczęściej mamy do czynienia jakby bardziej w takiej płaszczyźnie. W takim kontekście danego, danego bytu, danego podmiotu i wtedy te dane staramy się, staramy się łączyć.
Apache Flink i przetwarzanie stanowe
Tutaj mieliśmy okazję do pracy nad tego typu systemami u kilku klientów i właśnie event streaming też był wykorzystywany. Przechodząc może też częściowo do naszych case studies, które które którym czas najwyższy, czas najwyższy i do rozwiązania.
W systemie event streamingowym mieliśmy akurat do użycia bibliotekę Apache Flink. To jest taka całkiem, całkiem fajny kawałek kodu, który służy do procesowania eventów w trybie w trybie w trybie takim bez końca, ale też możemy sobie równie dobrze procesować eventy w streamingu w trybie. A może by w trybie po prostu unplugged, czyli. Czyli np. nasłuchując pliku z Kafki czy chociażby nasłuchując na jakimś katalogu z dysku? Bo to też jest fajnie wspierane i mamy różne konektory do różnych źródeł, które wpinamy w nasz flow. Mamy mamy filtrowanie procesowania. Tutaj fajne jest, że tym źródłem event może być cokolwiek.
Tak po prostu. Musimy tylko umieć podpiąć pod to źródło. Tak? A dalej to już poleci.
Tak to możemy oczywiście też robić nasze własne, customowe źródła. Jeśli mamy jakiś specyficzny przykład, czy to jakieś API, do którego nie ma konektora czy coś takiego i Flink też ma tą zaletę, i to też w tym projekcie było wykorzystywane, że wspiera z automatu też stanowe procesowanie, czyli. Bo generalnie processing. Niekoniecznie musi się wiązać z zapisem, zapisem czegoś, z jakąś prezentacją, bo to może być kwestia tylko przerobienia czegoś na inny topik. Natomiast w Flinku istnieje też opcja i jest automatycznie jakby wspierana do takiego lokalnego stanu. Polega to na tym, że procesując każdy event, zwłaszcza w takim kluczu strumieniu, automatycznie dla danego eventu lub dla danego klucza mamy dostęp do lokalnego stanu, lokalnego w rozumieniu procesingu danego elementu i w tym stanie możemy sobie zapisać wszystko. To może być. Ten stan zresztą jest wspierany, czy to implementacją zapisu na dysk, czy czy do rozbicia. I dzięki temu bardzo szybko możemy sobie. Procesując pewne pewne elementy, możemy dostać się do jakichś rzeczy, które są z tym eventem powiązane, albo do jakichś danych, które sobie gdzieś tam zapisaliśmy. I to, to, to bardzo fajnie, bardzo, bardzo szybko też działa. Nie musimy robić żadnych jakichś tam ekstra gratów do śledztw, to do bazy czy tego tego typu rzeczy.
Skalowalność i wyzwania w Event Streamingu
Cały ten steryd i generalnie też streaming bardzo fajnie się skaluje, gdyż to jest ogólnie rozwiązanie przeznaczone do takiego skalowania na wiele maszyn, więc fajnie wspiera jakieś takie znaczne strumienie. No i rzeczywiście w tym projekcie sprawdziło się to całkiem nieźle.
Ale nad tym czemu też trudności, tak jak na początku powiedzieliśmy, no to jest też. Troszkę rzadziej spotykany paradygmat. Tego typu architektura jest troszkę bardziej skomplikowana też niż taka tradycyjna, warstwowa. Skomplikowana. Może nawet nie tyle skomplikowana, co koncepcyjnie, koncepcyjnie, może troszkę też. Tych elementów ogólnie w takim prostowaniu jest już więcej. Nie mamy do czynienia na co dzień z tego typu podejściami, albo większość powiedzmy programistów nie miała do czynienia, więc pewnie trzeba troszkę przyjąć pewien inny model tworzenia aplikacji. W tego typu podejściu trzeba. Na pierwszym miejscu postawić to procesowanie i patrzenie z punktu widzenia tego jednego eventu, które stosujemy i cała otoczka nas aż tak bardzo nie interesuje, bo mamy ten event, mamy ten nasz lokalny stan, mamy źródło, mamy, mamy ten nasz sink i. No i sobie robimy jakąś tam transformację.
Agregaty i źródło prawdy
Więc to jest troszkę, troszkę inna. Ten przykład właśnie z tym lokalnym stanem to tak, jakbyś żywcem wyjął z agregatu, który procesuje jedną, kolejną komendę. Było też w takim przypadku i o tym wspominaliśmy, zdaje się, poprzednio też musimy mieć informację o aktualnym stanie tego agregatu, czyli musimy ten lokalny stan jednak zbierać. Czyli tak po to nam właśnie było to tworzenie eventów poprzednim razem, żebyśmy ten aktualny stan zbudowali. Bo jak przychodzi kolejny komunikat, w tym przypadku komenda, która ma. Wymusić jakąś tam akcję biznesową, to my musimy wiedzieć w tej akcji biznesowej, co się właściwie dzieje. A więc te wszystkie eventy, które się do tej pory wydarzyły dla tej instancji agregatu, muszą zostać odegrane i my łapiemy te stany. Znowu po raz kolejny mamy ten sam wzorzec, tylko trochę w innym ujęciu, gdzieś tam inaczej zastosowany, może nawet innych realiach wydajnościowych, ale dalej jest to ta sama koncepcja.
Tak, tak, tak, tutaj było to właśnie w sposób realizowane i też ten system akurat był też fajnym połączeniem event streamingu, ale też event sourcingu, bo tam rzeczywiście cały model, który był już ostatecznie ten fosa widoku była przechowywana w Elasticu i cały model mogliśmy bezpośrednio sobie stworzyć zabawkowych eventów, które były naszym źródłem, źródłem prawdy.
Integracja narzędzi i zmiana mentalności
Czyli no to co, sink? Jak to co jest trzecią wykładnią w. Więc procesowanie następowało w Flinku, event source Flink, czyli rezyliencja po stronie Kafki no i Elastic jako taka warstwa, że tak powiem, odczytu. Więc wszystkie te elementy tego naszego event driven były użyte i. Sprawdziły się na pewno, ale trzeba to sobie jasno powiedzieć. Trzeba było troszkę jednak takiego zmiany metalu doświadczyć, żeby, żeby dobrze taki system zrozumieć, trzeba jego charakterystykę zrozumieć. I też. Bo tu już nie wystarczą proste SELECT SQL. I wszystkie te problemy, o których mówiliśmy, czyli czy to kolejność eventów, czy właśnie semantykę delivery. Wszystkie te tematy były tam szeroko omawiane i implementacja ich pociągnęła też odpowiednią ilość czasu, więc trzeba być na to przygotowanym, że jednak tymi rzeczami, z tymi rzeczami możemy się nie spotkać w takim normalnym systemie. Te charakterystyki są troszkę inne, problemy są troszkę inne, ale jak już przywyknie do tego normalnych, starszych, rzecz jasna tak.
Tak. Nie to, że mieliśmy jakieś nienormalne. System, na który skądś nie było. Dobra, czyli to co tutaj było. Ciekawie się działo.
Message Driven w sektorze finansowym
I tak całkiem podobnie się działo w tym takim siostrzanym projekcie. Dobra, inna domena, bo to był projekt z branży. Jak to nazwać się finansowo-konsultingowej?
Tak, tak to ustaliliśmy przed nagraniem, że tak to się będzie nazywało. Więc tego się trzymam i tam, i tam nie było ani takiego typowego event streamingu, ani sourcingu. Tam po prostu było. Message driven to właściwie w tym wypadku to event driven. Było, bo było sobie N systemów wejściowych, które pluły sobie na swoje topiki jakimiś tam modyfikacjami. No właśnie, to były takie leciutkie, malutkie notyfikacje, które tylko niosły ze sobą informację: hej, zdarzyło się coś tam i czasami niosły jeszcze taki tyci tyci balonik. Pod tym nikiem znajdziesz te dane, bo np. te dane to był jakiś taki wielki dump z czegokolwiek, który ważył tam 90 mega i głupio byłoby tak apkę wrzucić coś takiego, bo to już jest katastrofa. Ale mając taką notyfikację i Analytics można było sobie ze źródła danych wyciągnąć to do dalszego procesowania. No i ten procesor, który tam sobie to procesował, dalej coś tam chciał sobie zrobić, więc pchał sobie kolejnego i na kolejny topik, gdzie ktoś tam sobie słuchał, że właśnie o to zadziało się z tym czymś i to taka powstała taka pajęczyna tych topików. Może niekoniecznie pajęczyna, bo to tak szybko. W dobrze określonym kierunku.
Orkiestracja mikroserwisów i BPMN
Czyli taka ukierunkowana sieć. Można by powiedzieć nie, bo one tam się mogły ze sobą przeplatać, jakby chciały, chociaż niekoniecznie zawsze chciały. Czasami następowało jakieś łączenie, bo trzeba było sobie na podstawie kilku notyfikacji taką namiastkę procesu biznesowego zrobić, czyli po prostu poczekać trochę tu, trochę tam, coś tam się zdarzyło. Mamy komplet danych. No to siup, jedziemy dalej.
Czyli de facto gdyby to teraz eskalować, to by się okazało, że i ileś tam strumieni właśnie nam się skrzyżowały i wyprodukowaliśmy całkiem coś nowego. I ktoś tam następny jest zadowolony, bo dostał właśnie dane wejściowe.
Czy tam bardziej był przykład synchronizacji tych usług, czy bardziej to była jakaś orkiestra nadrzędna jako takie dwa przeciwstawne podejścia?
Tam to niekoniecznie synchronizacja była. Tam, tam było. Jakżeż by to określić tak, żeby nie zdradzić szczegółów. Bo tutaj to tak trochę oględnie musimy o tym mówić. Tam chodziło. Bardziej o procesowanie taki danych cząstkowych troszkę, które się musiały w coś tam innego poskładać i no i dać jakieś tam wnioski gdzieś tam dalej, tudzież trochę orkiestracji też było, bo to coś co powstawało, to klikało z kolei kolejne elementy systemu. Ale głównie to chodziło o to, że że jakieś tam korporacyjne systemy plują swoimi danymi i my musimy je procesować zgodnie z wymaganiami tej domeny, która tam. No właśnie, właśnie ten system to była ta domena zbierająca to wszystko i układająca w odpowiednie przegródki. Tak można by to określić jakoś w miarę bezboleśnie, bez prywatności, bez zdradzania szczegółów.
Narzędzia BPMN i ewangelizacja
Tak właśnie zapytałem, bo mieliśmy też w innym projekcie u klienta właśnie przykład systemu. Stricte z taką implementacją orkiestracji mikroserwisów. To był projekt z branży ubezpieczeniowej z jednej firmy w A i problemem tam była w pewien sposób dogadanie tych wszystkich mikroserwisów, które były, które były na podorędziu tej firmy i generalnie. Chodziło tam o pewien sposób zamontowania takiej konwersacji, która która miałaby nastąpić pomiędzy mikroserwisami w kontekście np. załóżmy wyliczania wartości polisy. Zakładając, że użytkownik chce sobie wyliczyć wartość polisy ubezpieczeniowej, wchodzi na stronę, wpisuje swoje dane i pod spodem musi się wykonać ileś tam operacji, ileś ileś tam zapytań do przeróżnych systemów, żeby pobrać jakieś dane. I starać się tego użytkownika jakoś dobrze określić, zobaczyć, jakie ma jakieś ryzyka, połączyć z interesami zewnętrznymi, systemami. I cała ta konwersacja musi być realizowana i też była przez różne integracje i różne osobne komponenty. Natomiast szukam jakiegoś sposobu, żeby to wszystko jakoś zorkiestrować.
Czyli jakby tutaj same poszczególne mikroserwisy nie wiedziały za bardzo nic o sobie. Nie było takiej synchronizacji pomiędzy nimi, one nie były świadome, na którym etapie tego procesu są i co on właściwie realizują. Po prostu realizowały swoją funkcjonalność, nie wiedząc nic o otoczeniu. Natomiast ta orkiestra, co miała sprawić, że cały ten proces zostanie właśnie zamontowany w taki jeden spójny sposób. Natomiast też wymogiem dość takim ciekawym było to, że. Orkiestracja ma być też taka łatwa do modelowania, że tak powiem. No i wiadomo oczywiście tam zmiany z warstwą modelowania tej tego procesu i orkiestracji tego procesu. Były narzędzia BPMN do do modelowania właśnie Business Process, tj. właśnie to są narzędzia, które swego czasu były dość popularne i miały służyć jako. Może nie takie panaceum, ale takie rozwiązanie, które jest w stanie zamodelować dowolny proces. My z tego wygenerujemy jakiś kodzik i będziemy mieli gotowy system. Oczywiście obietnica tego nie została do końca spełniona.
Przejście na Event Driven w dużych organizacjach
Natomiast narzędzia takie jak Camunda czy Flowable, które de facto wywodzą się z jednego jakby z jednego jednego frameworka. Gdzież tam, gdzież tam! W branży finansowej ubezpieczeniowej są dość używane. I tutaj właśnie też była by użyta jedno z nich i generalnie spięte właśnie spięte. Jako takiej orkiestry. Autor, można powiedzieć tych naszych mikroserwisów, które gdzieś tam się asynchronicznie komunikowały. Rozwiązanie było dość. Możemy oczywiście dyskutować jakby. Na temat sensowności tego podejścia czy nie? Ile będzie osób, tyle będzie odpowiedzi. Natomiast to tam się jakoś to fajnie sprawdziło, sprawdziło, no i zainteresowało pewne problemy, które które ta firma ta firma miała.
Nie da się też ukryć, to trzeba było dużo osób przekonać do tego rozwiązania. I tutaj ewangelizacja była bardzo duża. Jakby. No może nie twórcy, ale. No bo to też było takie rozwiązanie platformowe, które miało oczywiście, jak to Platforma służyć całej firmie i wszyscy mieli z tego korzystać i łatwo się integrować, wpinać i wszystko miało super działać. Wiadomo, jak to z takimi rozwiązaniami. Trzeba też w ogóle uświadomić użytkowników organizacji, że tego typu rozwiązanie istnieje. Co ono właściwie daje? Po co nam jest potrzebne? Przecież my tu mamy naszą własną. Tutaj taki piękny monolit stoi od 10 lat i robi już te usługi. I dobrze, i dobrze to robi. Co tu, co tu więcej zmieniać?
Integracja Legacy Systemów
Więc to też niosło ze sobą pewną pewną dozę i taką nutkę ewangelizacji, o której mówiliśmy w poprzednich odcinkach na temat zmiany. I tutaj ta zmiana, właśnie ten paradygmat, to takie przejście właśnie na. Na Event Driven i na właśnie orkiestracji tego procesu i na modelowanie flow biznesowego w osobnym narzędziu. Oczywiście graficznym z kwadracików strzałkami. Muszą być. Więc to było. To było spore.
Można było przypinać pałeczki z jednego na drugi frak, co bułeczki można było przypinać. Powiem więcej, nawet można było sobie w tych kwiatkach w atrybutach wpisywać nazwy topików, do których się chciało coś wysłać, więc super coś wysyłały i wysyłały. Tak, tak to, bo to na tym to polegało. Więc generalnie metody dobre, te kwadraciki jednak dobre, dobre. Tak, tak.
Więc zdaje się, że to wszystko było całkiem, całkiem przemyślane. Ale w każdym bądź razie to też był taki przykład. Takiego Event Driven właśnie w dużej organizacji. Czyli raz, że trzeba to było niejako zapoczątkować jakby troszkę użytkowników organizacji. Jakby twórców poszczególnych komponentów wprowadzić w to. Ale to na pewno był taki element, który w dużych organizacjach, czyli właśnie ten, to taki back-up link i ta komunikacja właśnie polegająca na eventach. Coś, co w takiej organizacji na pewno się. Lepiej sprawdzi na zasadzie lepiej. Pozwoli nam zintegrować to nasze rozproszone klocki.
Specyfika domen i formatów danych
No bo musimy. No tak, tak, te klocki i tak chcą się rozpraszać wcześniej czy później. Więc w którymś momencie pojawia się pokusa, żeby je zechcieć zintegrować. I właśnie. No tak, tak, no bo to pytam o to, jest skala. Była, była bardzo duża, zespołów jest bardzo dużo, więc mimo wszystko mimo wszystko jest to forma, tak jak to przedstawiłeś, forma jakiegoś jednolitego procesu jednolitego. Tam na pewno było bardzo dużo składowych tego procesu i pewnie były jakieś procesy, które tam się gdzieś tam przewijały, więc to się jakoś wszystko musiało ładnie uzupełniać i czasami, czasami pewnie to w ogóle to musiało być z tego, co wnioskuję, bardzo rozbudowane.
Ja akurat nie byłem w tamtym projekcie, więc mogę wnioskować, ale jednak domena była zdefiniowana. Właśnie jako jako ten obszar ubezpieczeń. I chodziło o rzeczy związane z polisą, czyli tak jakbyśmy się skupiali na jednym aspekcie. Mamy dużą domenę. Wiadomo, jest skomplikowana, ale wiemy, wiemy, czego się można spodziewać w tym projekcie, o którym ja z kolei wspomniałem. Domeną można by powiedzieć było całe przedsiębiorstwo i to przedsiębiorstwo ma różne swoje oddziały. Te oddziały tam akurat departamentami nazywane szumnie to używały. Od już niepamiętnych czasów różnych narzędzi. Te narzędzia wydawały swoje dane w różnych dziwnych formatach. Czasem nie wiem, czy nam wolno takie nazwy wypowiadać, ale był tam na przykład SOAP, który tamte swoje mydlane XML-e wypluwał. Były jakieś cacka, które tworzyły jakieś wielkie pliki, jakieś takie raporty właśnie te po kilkadziesiąt mega. To chyba taki już gdzieś na początku projektu dostawaliśmy po prostu takie Restore response, które ważyły po 113 mega. Jedno z nich coś tam zawiera, także to aż się prosiło, żeby coś z tym dalej zrobić.
Content-based routing i Anti-corruption Layer
I to chyba. Te fakty chyba pokazują, że w końcu ktoś poszedł po rozum do głowy i stwierdził: no dobra, może jednak zróbmy coś z tym, niech te różne narzędzia, póki jeszcze nie wymrą, a produkują nam jeszcze do tej pory użyteczne dane, niech jednak gdzieś tam świat o tym usłyszy, a przynajmniej jakiś kolejny departament, który może z tego zrobić jakiś użytek. I zróbmy im taką przyjemnie laurkę. Dlatego właśnie ciężko powiedzieć, w którą stronę, z której strony, w którą stronę, bo to mogłoby z dowolnej strony w dowolną przepłynąć. I dlatego właśnie tam takiej analogii do pajęczej sieci użyłem.
Była cała horda. Topików. Kafkowych, na których się pojawiały te notyfikacje. Były jakieś tam źródła danych, z których trzeba było do ciągać te dane, ale tak naprawdę przepływ nie był jasno określony. Czyli tutaj było. Był taki model stosowany na zasadzie: ja mam takie coś, to dzielę się z wami i róbcie z tym, co chcecie i przy okazji takie sterujące przerabiają. Co maszyneria chwytała, to jakoś starała się. Format tego przynajmniej dopasować do tego, co reszta świata chociażby mogła spróbować z tym zrobić. Nie męczyć z parkowaniem tego nieszczęsnego co jest Pawła, który tam waży 100 mega. Tylko jednak wystarczy to w bardziej sprawnej formie gdzieś tam.
Czy to co mówiliśmy schemat dobrze jest, jeśli to organizacja czy elementy tego strumienia jednak mają wspólny schemat, bo to będzie znacznie prostsze w implementacji we wszystkim tak naprawdę. No, tutaj to jest jeden z elementów. Może schemat tutaj jest tak trochę nie do końca precyzyjnie, bo format po prostu, żeby ten format był strawny dla dla innych, a w tym akurat projekcie schematy wszędzie różniły się między sobą. 1 jeden jeden taki element spójny do wszystkiego to były właśnie te notyfikacje, które sobie hulały po tych naszych plikach. To były takie sobie leciutkie eventy, bo. Teraz mi wyleciała z głowy nazwa tego wzorca. Może podpowiesz, ale taki był fajny wzorzec stosowany właśnie do transportowania tego, opierający się o ten magiczny ID do contentu, który gdzieś tam daleko leżał.
A mówisz o Anti-Corruption Layer? Tak, tak jest dokładnie. Dzięki.
Event Storming w praktyce: bramka płatności
No to takie różne ciekawostki mogą się zdarzyć tu i ówdzie. I taką jedną z tych ciekawostek, takiego może mniejszego kalibru, ale jednak. Kto wie czy nie ciekawszą nawet od tych ciekawszą. Zależy co kto lubi. Ja tam lubię Agaty Christie. To było właśnie wpięcie się z Anti-corruption Layer do potrzebnych modułów różnych w takim fajnym easy projekcie, w którym sobie dawaliśmy tom i na początku nie było wiadomo, jak to się tam dzieje, bo co, co tam się dzieje to tam z grubsza wiedzieliśmy, tylko nie wiedzieliśmy jak. No i zaczęliśmy to dłubać tak, żeby jednak się dowiedzieć, jak to się dzieje. I pojawiły się tam w pewnym momencie takie pojęcia jak szyna danych, jak jakiś tam event, który sobie leci z tego czy tamtego, projekt, który ja zaczynałem, kiedy jeszcze był Greenfield.
No tak, tak to się zaczyna legacy, tylko patch chyba. Tak, tak to wrócił. Wrócił do nas jako Legacy. I bardzo dobrze, bo ile to się człowiek nauczył na tym projekcie, to już w ogóle o Anti-corruption Layer. A może nawet jak ją wplatać tak, żeby się jego miłość nie zorientował? I to się nawet udawało, bo chyba się nie zorientował do końca.
Chyba nie wgryza się w kosmos. To chyba nie. Jemu tam wystarczy. Tak, tak.
To jak byśmy mieli tutaj eventy w Select? Aha, w bazie danych to byłoby trudniej. No to byśmy się nie zamaskowali. No ale jakoś nie dopatrzył się. No i te eventy nam się tam potworzyły i hulały po tej szynie i mogliśmy, mogliśmy je sobie podglądać, a w którymś momencie, tak jak to nawet wspomnieliśmy poprzednio, doczekał się ten czy tamten moduł. Swojego agregatu, agregat robota, który tam obsługiwał biznesowe encje. Tak, to było w taki sposób. Całkiem, całkiem przyjemnie. Tak, to była, myślę, dość udana próba włączenia takich nowszych podejść w dość statyczny kod, który jednak ma już kilkanaście lat. Potrzebowaliśmy troszkę, troszkę bardziej rozluźnić to pewne powiązania, więc trzeba przyznać, że udało nam się to dość organicznie zrobić. Tutaj. Tutaj to wymagało trochę cierpliwości. Takiej, bo nie mogliśmy tego zrobić od razu. Musieliśmy przygotować grunt pod to. Wiadomo, że to był projekt Legacy, ale kiedyś też mieliśmy taki epizod, gdzie nawet jeszcze jedno pojęcie z eventem i na końcu tworzyliśmy. I to znamy i też na S w środku i też nam się dobrze sprawdziło. Tak, tak, tak. Zamontowanie pewnej domeny. Event Storming z kolei.
Tak, tak, to jest bardzo ciekawe zagadnienie, gdzie, gdzie też tak naprawdę odwróciwszy kota ogonem możemy zobaczyć to, co powinno być na początku. Jeżeli wiemy, czego się spodziewać na końcu tak, czyli. Czyli wniosek z tego płynie taki, że wszystko, co zaczyna się na event i będzie na nim jest ona S w środku, jest dobre, to jest dobre.
Podsumowanie i przyszłe tematy
Ja tam lubię. Z tego ostatniego projektu, to mi takie wrażenie pozytywne utkwiło w pamięci, jak wprowadzaliśmy zmiany do niego, bo zamodelować tam proces. Może tam bez wnikania w szczegóły, możemy wyjawić, co to było, bo była to po prostu implementacja bramki płatności, która obsługiwała iluś tam dostawców pod spodem. I w którymś momencie przyszedł. Przyszedł. Przyszło zgłoszenie biznesowe na dodanie kolejnego procesu z kolejnym dostawcą. Albo może. Inny wariant usługi od jednego z obecnych dostawców i tak naprawdę przeszliśmy do tej ściany, na której jeszcze karteczki różnokolorowe z Event Stormingiem sobie wisiały. Niektóre poodpadały, które podpinałem to były te zbyteczne to ich nie podnosiliśmy. Te co zostały to były dobre, więc my do tych co zostały dolepiłyśmy kawałek procesu biznesowego i okazało się, że że można ten proces tam wszczepić totalnie bezboleśnie dla całej reszty. Praktycznie z tego co pamiętam ze zmian w kodzie to pojawiło się kilka nowych klas, właśnie tych opisujących komunikaty. I chyba pojawiły się tylko nowe handlery dla komend i eventów w istniejących agregatach i nic więcej niż nowe, które po prostu się spełnią z istniejącym już procesem biznesowym. Rdzeń pozostał nienaruszony, dokładnie co było widać fizycznie po po zmianach w repozytorium, że faktycznie ten rdzeń jaki był taki został.
Co dowodzi tego, że a rdzeń był dobry. B Event Storming jest super i cała impreza jest w ogóle fajowa. Ja swoją.
I chyba tym optymistycznym akcentem i wnioskiem możemy zakończyć, bo tak jeszcze pogadamy. Będziemy musieli pogadać o jakimś debugowaniu tego wszystkiego. A to może następnym razem, następnym razem.
Dobra, no to fajnie, To dzięki Wojtek. Dzięki za dzisiaj.
Do następnego.
Do następnego.