#199 Prosto i praktycznie wyjaśniamy: Model aktora

Łukasz Kałużny: Bo dzisiaj to będzie seria prosto i praktycznie wyjaśniamy. To nie jest coś, co rzucamy się, implementujemy. Tak, więc jeżeli ktoś mówi, że robi dziedziczenie, to w definicji Alana nie programuje obiektowo. To tak jak miałeś problem z wydajnością i dołożyłeś cache, teraz masz dwa problemy.

Szymon Warda: Jak nie więcej. Doskonale wiesz kiedy tego użyć, bo masz dokładnie ten problem. A jak szukasz problemu do tej architektury, to robisz to absolutnie źle.

Łukasz Kałużny: Bo niestety krzywa wejścia potem jest duża, jakby nie powiedzieć, że po prostu pionowa skała w tym momencie.

Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie gdzieś tu na dole albo Patoarchitekci.io/199.

Szymon Warda: Czyli to oznacza, że nasza konferencja dwusetna to już.

Łukasz Kałużny: To już technicznie już po. Kto nie był, niech żałuje. My jeszcze nie byliśmy, ale już wiemy…

Szymon Warda: Ale było fajnie.

Łukasz Kałużny: Że będziemy żałować, że się, tak, ale było fajnie. Więc słuchajcie, to ostatni odcinek nagrywany w tej formie w tym sezonie. Za tydzień jeszcze nie wiemy jak to będzie wyglądało. Zobaczycie koniec sezonu. I w tym miejscu jedno takie ogłoszenie parafialne dla Was. Kto nie jest na newsletterze niech tam wleci, ponieważ będziemy, tak jak w zeszłym roku, w tej przerwie wakacyjnej trochę wrzucali od siebie albo jakieś przemyślenie, link, coś do poczytania w newsletterze co tydzień zamiast podcastu. Więc wracamy do tej całej koncepcji na czas… Wrócimy pewnie w drugim tygodniu września, o tak, patrząc na kalendarz urlopowy.

Szymon Warda: Dokładnie. Dobrze Łukaszu, o czym dzisiaj?

Łukasz Kałużny: Dzisiaj idziemy do czegoś, co mnie zaskoczyło na szkoleniu Agentic AI. Okazuje się, że duża część osób w ogóle nie kojarzy modelu aktora.

Szymon Warda: Ale wiesz, że to jest… W modelu, w którym było tak, że ok, on miał taki swój wielki hype jak pojawiła się Akka, ale to jest nisza bardzo mocna mimo wszystko.

Łukasz Kałużny: I zgodzę się z Tobą, że to jest nisza, ale tak jak wrócę, dobrze jest znać różne koncepcje, które się pojawiły w IT i rozumieć je.

Szymon Warda: Oczywiście, to jest też, do czego dojdziemy, bo w ogóle mieliśmy na przygotowanie jak i pierwsze omówienie, to było te same w ogóle zdania nam chodziły po głowie. To jest coś, co warto wiedzieć, szczególnie w kontekście developerki i w ogóle innego sposobu myślenia.

Łukasz Kałużny: I tyle. W sensie inaczej, prawdopodobnie to, co mogę Wam powiedzieć, macie zrozumieć myśl, bo dzisiaj to będzie seria prosto i praktycznie wyjaśniamy. To nie jest coś, co rzucamy się, implementujemy.

Szymon Warda: Dokładnie tak.

Łukasz Kałużny: Dobra i słuchajcie, zanim wejdziemy w ogóle w początek, Oskar podziękowanie za pewnego linka, bo byłeś trochę ojcem znowu odcinka w pewnym sensie. To jest to, że bardzo dużo wydarzyło się w latach 70. Jak całe IT tak naprawdę. I w tym miejscu słuchajcie, najbardziej zgwałcona koncepcja, bo tak to nazwijmy, programowania, czyli object oriented, przecinało się z właśnie, ojciec terminu Alan Kay, który uknuł small talka i całą tą część wokół tego z ojcem Model Actora, Carlem Hewittem, mieli ze sobą styczność. I te koncepcje, jeżeli popatrzycie, rodziły się równocześnie. To jest bardzo istotna rzecz, że równocześnie budowało się object programming, a z drugiej strony model aktora powstawał w tym samym czasie i znali i nawzajem czerpali z siebie, ze swoich pomysłów.

Szymon Warda: Czyli można powiedzieć, że model aktora jest wdrożeniem dobrze rozumianego programowania obiektowego.

Łukasz Kałużny: Jeżeli tak, to byśmy Szymon, można byłoby tu utknąć, bo z jednej strony Carl, gdzieś tam można to powiedzieć, że brakowało mu współbieżności w small talku. To można tak w ogóle określić i izolacji, bo to był taki, bardzo upraszczając w tym miejscu.

Szymon Warda: Powiedz mi jedną rzecz, bo zacząłeś od takiego, że rzuciłeś takie spychacze tutaj właściwie, że niezrozumiany object programming. To ja teraz wrzucę to zdanie, które ładnie bardzo pokazuje, co tam jest niezrozumiane. I tam jest taka definicja w small talku, że jak wygląda komunikacja między obiektami: obiekt wysyła komunikat do obiektu. Teraz to słowo komunikat, czym się różni? Funkcja, to jest ja Ci każę i czekam nad Tobą aż to zrobisz. (…) to jest: wysyłam i narka. Nie czekam, może się nie udać i tak dalej i tak dalej. Ten element.

Łukasz Kałużny: I teraz…

Szymon Warda: Skupiliśmy się na obiekcie, a nie na komunikacji.

Łukasz Kałużny: Czyli 50 lat temu Async i event driven były w myślach koncepcyjnych.

Szymon Warda: Tak, jak o dziwo idea była fajna, a wyszło co innego.

Łukasz Kałużny: Tak, więc jeżeli ktoś mówi, że robi dziedziczenie, to w definicji Alana nie programuje obiektowo. Inaczej, jest też bardzo fajne, zostawię linka do tego, jego wypowiedź, że żałuje tego, że nazwał to object, bo całość chodziło mu o messaging i izolację a nie o obiekty.

Szymon Warda: Tak, a potem na studiach mamy generalnie, że mamy obiekt samochodu…

Łukasz Kałużny: Jako, że to prosto i praktycznie, to teraz wyjaśnijmy sobie czym jest aktor, bo to jest chyba najważniejsza taka część, jeżeli popatrzymy.

Szymon Warda: Tak. Dobra, to jest samodzielna, niezależna jednostka, która ma swój stan, umie odbierać wiadomości, umie wysyłać wiadomości, może powoływać do życia innych aktorów albo ich nadzorować. I to właściwie byłoby na tyle.

Łukasz Kałużny: Tyle.

Szymon Warda: Jest unikalna, bardzo ważne.

Łukasz Kałużny: I żyjący sobie w runtime obiekt. I teraz jak popatrzymy chyba 2 przykłady, żebyście załapali. Zróbmy z jednej strony czujniki IoT, bo to jest w ogóle, akurat to jest digital twin, czyli ten cyfrowy bliźniak, jest idealną rzeczą. Czyli mamy coś, co symuluje kod takiego urządzenia IoT i podaje mu dane z czujników, czyli wrzuca do niego informację, wysłała mu wiadomość, że teraz masz taki stan i dzięki temu jesteśmy w stanie zrobić bliźniaka fizycznego urządzenia, żeby zachowywał się na tym kodzie, podając mu takie same dane na przykład z czujników.

Szymon Warda: Tak i jednocześnie nas nie interesuje, czy to urządzenie jest teraz dostępne, ma dostęp do internetu czy nie ma, po prostu wykonujemy operację i zakładamy, że stan naszego digital twina zsynchronizuje się z realnym czujnikiem, kiedy tylko ten będzie dostępny tak naprawdę.

Łukasz Kałużny: Tak i będzie odwzorowywał, tak. Druga rzecz to halo i do tego też jeden z największych implementacji aktorów Halo i tutaj sesja gracza. Czyli gracz jest zalogowany, jest jednym aktorem w tej sesji gry w multiplayerze, pamięta jego pozycję, punkty, ekwipunek i inne takie rzeczy. I nie ma tutaj race condition czy innych takich elementów, ponieważ aktor po stronie serwera odwzorowuje to, jak przychodzą sygnały tak naprawdę.

Szymon Warda: Tak. I jest jeszcze jeden przykład, który w ogóle mnie rozśmieszył bardzo mocno, bo miałem przyjemność właśnie projektowania systemu pod model aktorów, właśnie jak Orleans wyszedł, bo tam na przykład jest taki, że stan konta i dokładnie pod to właśnie jeden bank się zwrócił. Projektowaliśmy system po to właśnie, żeby mieć taki frontend, który będzie bardzo szybko zwracał, chyba tam było top 20 transakcji na koncie, stan konta i takie proste rzeczy ogólnie rzecz biorąc. I to się do tego nadawało fenomenalnie.

Łukasz Kałużny: Dobra, to przejdźmy do następnej bardzo ważnej definicji. O co Szymon chodzi w mailboxie i przetwarzaniu jednowątkowym?

Szymon Warda: Ale mailbox to właściwie można powiedzieć, że to jesto to samo co inbox, nawet nazywa się podobnie ze wzorców komunikacji systemów rozproszonych, bo model aktorów i przede wszystkim wirtualnych aktorów, jest nacelowany na to, żeby to jest przykrywka nad dowolną rozproszoność tych systemów tak naprawdę. Ona czasami jest leaki, nie do końca jest spójna, ale mimo wszystko model aktorowy, który jest przystosowany do skali, która w teorii ma dowolną ilość maszyn pod sobą. Więc ten mailbox to jest prosta rzecz, to lista komunikatów, które aktor ma obsłużyć. Tyle.

Łukasz Kałużny: Tyle. Nie ma tutaj… Dobra i powiedziałeś jedno słowo, trzeba sobie powiedzieć, że rozróżniamy w tym momencie klasycznego aktora. I to jest jedna rzecz, o której powiedziałeś. I druga rzecz, która…

Szymon Warda: Który jest (…) teoretycznym obecnie bardziej.

Łukasz Kałużny: Tak, jest teoretyczny, przy czym to sobie weźmiemy zaraz w różnicę. Oraz drugi, który użyłeś, bo Microsoft ma framework Orleans i Microsoft Research nazwał tutaj praktykę, to będzie na razie zajawka i potem wejdziemy w szczegóły, nazwał też swoją praktykę wirtualny aktor. Czyli to, że Ty tym nie zarządzasz, tylko wszystko jest robione za ciebie wokół cyklu życia aktora.

Szymon Warda: Właśnie. Poczekaj, doprecyzujmy w ogóle o co chodzi z nie zarządzasz tym. Bo problem z aktorami jest taki, że to jest jakiś tam obiekt, który sobie żyje w pamięci, zużywa pamięć, CPU i tak dalej. Z reguły tych aktorów aktywnych jest dużo mniej niż tych, których w ogóle, niż tych, których wszystkich możliwych. Więc to, co robi Orleans, to jest to, że usypia aktorów. Czyli deserializuje, zapisuje i jak aktor jest potrzebny, to on wraca do życia. Czyli robi hydrację i rehydrację aktorów, dzięki czemu zarządzamy lepiej zasobami, można tak powiedzieć.

Łukasz Kałużny: Czyli Szymon, możemy powiedzieć, że założenie tego klasycznego aktora, jeżeli go implementujemy, to my musimy wszystko zrobić samodzielnie, czyli zbudować discovery, zarządzać lifecyclem, zdecydować o placement, czyli na której maszynie ma to trafić, co zrobić, jeżeli maszyna padnie i inne tego typu elementy. A rozwiązania na bazie wirtualnego aktora mają obietnicę, że pod prostym API my za Ciebie zarządzamy tymi aktorami, Ty się skup na interfejsie i kodzie od samego, bebechów i logiki.

Szymon Warda: Tak, i to, co jest tam ważne, jak się w ogóle używa określonych aktorów? My zakładamy, że aktor zawsze istnieje. Nas nie interesuje czy on będzie powołany do życia od nowy, czy on będzie rehydrowany, czyli wzięty z pamięci, czy cokolwiek. Po prostu mówimy, że chcemy handle’a i tego handle’a otrzymujemy. Koniec, kropka. To bardzo mocno ułatwia.

Łukasz Kałużny: Tyle.

Szymon Warda: A jeszcze jedna ważna rzecz odnośnie Orleans. To jest projekt, który cały czas żyje. On ma prawie 10,5 tysiąca gwiazdek na GitHubie.

Łukasz Kałużny: Wiem, dojdziemy sobie do niego jeszcze. Polećmy teraz przez w sumie serce tego całego modelu, czyli messaging. To było już w tym o komunikacie, w sumie powiedzieliśmy, ale trzeba sobie powiedzieć o tym, że działają, tak nazwać to, wymiana wiadomości pomiędzy aktorami, do aktora jest w założeniu asynchroniczna i to jest zazwyczaj.

Szymon Warda: Powinna być.

Łukasz Kałużny: Powinna i powinna być fire and forget. Kolejną rzeczą, nie współdzielą pamięci, nie wrzucamy tam referencji i innych rzeczy, tylko nadajemy event, tak jak robicie to Event Driven Architecture. Po prostu jest event i koniec. I tak powinno być.

Szymon Warda: Jak powinno się to robić, bo Łukasz doskonale chyba wiemy obydwaj, że to jak ludzie robią nie zawsze jest zgodne z tym jak powinno być to robione.

Łukasz Kałużny: Frameworki tak to narzucają z założenia.

Szymon Warda: Niekoniecznie, na MassTransicie możesz zrobić request response na bazie messageingu, gdzie tam pod spodem masz busy waita, tego typu rzeczy.

Łukasz Kałużny: No i właśnie jest ten dodatkowy, jest też w niektórych miejscach request response i może być problematyczny, o tak, samo w ogóle zamodelowanie tego jest problematyczne. Dobra, kolejny element to będzie co Szymonie w tym? To jest też chyba clue problemów.

Szymon Warda: Brak współdzielonego stanu oczywiście. Bo to mówiliśmy, aktor jest niezależny, czy tam grain, jak tak będzie nazwany, nieważne. Na razie skupmy się na tym aktorze. On ma swój stan i go modyfikuje, trzyma go w pamięci, ten stan jest pod ręką od razu, więc jest szybko dostępny, załóżmy stan konta i tak dalej, robi się bardzo łatwo i przyjemnie, nie. I kolejna rzecz to jest to, że lokalizacja aktora transparentna, nas to nie interesuje gdzie on właściwie w ogóle jest.

Łukasz Kałużny: Tak i chyba trzeba tu sobie powiedzieć, że aktora powinniśmy adresować po identyfikatorze i nie interesować nas, gdzie w rozwiązaniu on siedzi, o tak, z perspektywy dotknięcia tego i zarządzania. I to jest rzecz taka, najbardziej chyba będzie problematyczna, jeżeli chodzi o modelowanie. I gdybyście próbowali użyć tego bez frameworków, bo tutaj całe systemy rozproszone i wszystkie błędne założenia nas bardzo szybko dotykają, jak nie jest to jedna maszyna.

Szymon Warda: No słuchaj, nie od parady Orleans ma ile lat? Z 8? I dalej się rozwija, bo tam jest sporo kodu.

Łukasz Kałużny: 16 Szymon, 16, to jest już 16. Do tego jeszcze przejdziemy.

Szymon Warda: Jestem starym człowiekiem.

Łukasz Kałużny: Tak. No i kolejna rzecz, to jest supervision i let it crush. Czyli drzewo, jest tworzony aktor, może tworzyć swoje drzewo, rodzic nadzoruje swoje dzieci. Czyli budujecie sobie taki graf zależności, drzewko. I gdy coś pada, to rodzic decyduje jak to eskalować, restartować, stopować. I to jest też filozofia z Erlanga, bo to jest bardzo ważne. W tym miejscu jest tak, że nie obwarowujesz wszystkiego try-catchem, tylko pozwól sobie paść, wystartować na czysto. Czyli Cloud Native Foundation i Golang, jeżeli popatrzycie, ma dokładnie to, czerpie z Erlanga, jeżeli popatrzy się na pewną filozofię. I ciekawostka, odnosimy się do Erlanga jako języka programowania. I teraz ważne, oni na podstawie wymagań telecomów, kiedy tworzyli Erlanga, doszli do podobnego modelu implementacji. Oni to nazwali Concurrency Model Programming, czy coś takiego, nie pamiętam dokładnej definicji w tym miejscu. Ale chodzi o to, że w równoczesnym czasie model aktora w Erlangu powstał w oderwaniu od tego wszystkiego, nie znając siebie nawzajem. To też jest dość ciekawy element.

Szymon Warda: Bo to było (…) połączeń telefonicznych.

Łukasz Kałużny: Tak.

Szymon Warda: Te same wymagania, podobny wynik, bycie wysoko niezależnym i wydajnym.

Łukasz Kałużny: Dobra, to co Szymon, teraz był aktor i messaging i teraz jego faktyczna implementacja, czyli virtual actor.

Szymon Warda: Tak, to co powiedzieliśmy, mamy sobie runtime, który nam powołuje dynamicznie, nie interesuje nas gdzie on żyje, jak on żyje. Mamy persystencję stanu, co nam też implikuje to, że drugą fajną rzecz, mianowicie, że z tych wielu źródeł mamy w ramach Disaster Recovery przełączanie się klastrów, wyłączanie node’ów i tak dalej. Tego stanu nie stracimy. No wiadomo, oczywiście ten, jest single point of failure naszego stanu zapisu, ale to też możemy zrównoleglić, że tak powiem, i uodpornić.

Łukasz Kałużny: I teraz ja w skrócie, czym to się będzie różnić od klasycznego aktora? To jest tylko jedna prosta rzecz. Wirtualny aktor z założenia zdejmuje od Ciebie zarządzanie wszystkiego na rozproszonym klastrze i całą logikę lifecycle. Nic więcej. To jest jedyna taka duża różnica. Ci, którzy programowali, wiedzą, że jest jeszcze parę innych…

Szymon Warda: Czyli ogromna.

Łukasz Kałużny: Tak, jest to, że jest jeszcze parę detali implementacyjnych innych. Ale jeżeli zaczynacie, to wirtualny aktor z założenia ściąga na nasz cały lifecycle.

Szymon Warda: No i realnie do tego Akka też finalnie doszło tak naprawdę. Dlatego właśnie powiedziałem, że ten czysty aktor już jest takim teoretycznym bardziej, już prawie wszyscy wchodzą w wirtualnego aktora.

Łukasz Kałużny: Dobra, chyba pora teraz przejść do wielu maszyn i skalowania tego. I słuchajcie, jeżeli teraz popatrzycie, to wszyscy borykają się z tym samym problemem w technologiach. I jeżeli weźmiemy Kubernetesa i StatefulSeta, czyli stanowe pody, mają dokładnie te same problemy. I o czym teraz mówimy? To są trzy problemy, jeżeli popatrzycie. Czyli gdzie umieścić aktora, czyli placement. I to jest tak jak na Kubernetesie, jak wybrać najlepszy węzeł, żeby umieścić. To jest pierwszy problem. Drugi problem, to jest service discovery, czyli jak wysłać komunikat do tego poda, a w tym miejscu do aktora. I trzeci, który jest najbardziej problematyczny, co zrobić w momencie awarii? Bo Kubernetes, jeżeli popatrzycie w jaki sposób zarządza stanem, to on nic nie robi z podami, które były w tym momencie na nodzie. I tu zaczyna się cała rzecz związana z (…) CAP-a, CAP Availability Partition. Czy doprowadzić do pojęcia split brain, czy nie? I co w tym momencie zrobić?

Szymon Warda: Ja bym tutaj zaznaczył, bo często jak mówimy o awarii, to mówimy o wyłączeniu node’a. A CAP cały jest, odnośnie tego też niedostępności albo tymczasowej niedostępności, albo braku widoczności i tak dalej. Tak że myślcie tu o awarii też jako sieciówkach, o całym spektrum, tym szarym, nie zerojedynkowym, że coś się wyłączyło.

Łukasz Kałużny: Czyli problem… Inaczej, split brain to z założenia jest to, że jakaś grupa węzłów nie może się dogadać sieciowo z innymi. To jest też bardzo ważna rzecz. Czyli może być awaria sieci, switcha, czegokolwiek. I stąd to się wzięło. Nie tylko węzła.

Szymon Warda: Dokładnie. Dobrze. To co, śmigamy dalej? Czyli storage, gdzie to przechowywać? Jak się łatwo domyślić, to jest dość prosty element. No bo co? No bo stan aktora jest dość trywialny, ponieważ jest to, nazwijmy sobie, jakiś blob. Nie przeszukujemy (…) stanów, to nie są operacje, gdzie my będziemy robili zapytania, kwerendy i jeszcze inne magiczne rzeczy. Orleans domyślnie lądował w SQL Serverze, ale to było wiele lat temu. Mamy sobie table storage’a, mamy sobie teraz wtyczki do Redisa, Blobstera, Cosmosa, Dynamo DB, kto co chce.

Łukasz Kałużny: Słuchajcie, więc założenie jest proste: stan agenta trzeba w jakiś, przepraszam, agenta, do tego przejdziemy czemu powiedziałem potem agenta. Stan aktora trzeba gdzieś po prostu zserializować. Czyli cały obiekt powinien być gdzieś serializowany. I tutaj, jeżeli popatrzymy na sposób działania, to witamy event sourcingu w wielu miejscach.

Szymon Warda: Bo szybko.

Łukasz Kałużny: Bo szybko, w teorii bo szybko, bo tanio i łatwo przez to, że jest ten nadpis stanu. Zobaczcie bardzo naturalne dokładanie stanów, można to w sposób realny snapshotować. Tak samo potem model odczytu, w którym gdzieś pojawia się CQRS. Przy czym to też szybko zawsze będzie problemem, tak jak z powiedzeniem, że event sourcing powoduje nam szybkość. Nie, nie, tam jest całe nowe piekiełko problemów, o których jeszcze nie wiecie. To trzeba sobie powiedzieć. To tak jak miałeś problem z wydajnością i dołożyłeś cache. Teraz masz dwa problemy.

Szymon Warda: Jak nie więcej. Dobrze

Łukasz Kałużny: Dobra , to co, było dużo Orleans. Ale może zacznijmy od tego co, na czym to budować można, popularne technologie, które istnieją. I chyba zacznijmy może od Akki Szymonie.

Szymon Warda: Ona zaczęła w ogóle ten cały szał, można powiedzieć, który wystąpił, czyli taki… Zacznijmy od tego, to jest na JVM-ie, czyli Scala, Java i tak dalej. Powstała sobie Akka.Net. Nie mam pojęcia jak ona długo jest rozwijana. To powinienem w ogóle sprawdzić jak to wyglądało, bo tam było różnie, że tak powiem.

Łukasz Kałużny: Tak, Scalowa Akka powstała w 2009 roku, została zrealise’owana, a Orleans, o którym mówimy, był w researchu w 2010 wyrzucony. To tak też w ogóle datami, żebyście wiedzieli, kiedy te technologie wjechały i one nie podbiły się tak strzałem szeroko.

Szymon Warda: Znaczy Akka odbiła się dość szeroko, jeżeli chodzi o, był hype na to, było o tym głośno bardzo, (…) Akki było ciekawe.

Łukasz Kałużny: W 2016. 2014-2016. Szymon 2014-2016,to był chyba szczyt hype’u tego.

Szymon Warda: To on się przez jakiś czas tam ciągnął, bym powiedział, to nie był takie coś, co wybiło przez dwa miesiące i zniknęło. On, było głośno wokół tego jak się działo. No i zaczęła się cała magia, dużo prelekcji na konferencjach, tego typu rzeczy. Potem co dalej? Poleciał Orleans.

Łukasz Kałużny: Jest Orleans, tak.

Szymon Warda: Tak, Orleans, które już powidzieliśmy co pozmieniał. On się przyjął bardzo fajnie, ale jak to z wieloma projektami Microsoftu przyjął się, jest używany, ale głośno o nim nie jest, trzeba powiedzieć. Wydaje mi się, że obecnie Akka jest dużo bardziej medialna.

Łukasz Kałużny: Raczej była. Pamiętaj, że to jest problem JVM versus .Net i chyba .Net nigdy nie był sexy. W szczególności, że Orleans, jak wychodził, to są czasy przed .Net Corem, przed działaniem na Linuksie. I to jest bardzo ważna rzecz w tym miejscu.

Szymon Warda: To się też zgadza, ale też uważam, że Microsoft, nie jest najlepszy marketing dobrych swoich pomysłów.

Łukasz Kałużny: Tak. Jeżeli teraz pójdziemy, to całość, ja to zostawię w ogóle na Discordzie Wam, tą notatkę, którą zobaczycie, bo jest tu trochę mięsa i kawałków kodu. To są przypadki w jaki sposób wygląda, że porównanie na przykład Akki.Net z tym, z różnicą do Orleansa, o ile mniej kodu się pisze wokół na przykład tworzenia aktora. I chyba ważną rzeczą, o której trzeba powiedzieć, Orleans skupił się na tym virtual actorze i na tym bycie i całej automatyzacji wokół niego, gdzie Akka ma cały taki zestaw klasycznego modelu aktora, gdzie skupia się też na tym, że możecie bardzo dobrze samodzielnie zarządzić hierarchią, nadzorem, sterowaniem shardingu w klastrze, podejściem do tego jak układać streamy, prezystencje. Czyli jest tutaj, jest to bardzo dojrzałe podejście i potężne narzędzie, ale wymaga od Was dobrze zrozumienia modelu aktora, bo niestety krzywa wejścia potem jest duża, jakby nie powiedzieć, że po prostu pionowa skała w tym momencie.

Szymon Warda: Znaczy dochodzimy powoli do tego momentu, żeby powiedzieć gdzie aktor ma sens, a gdzie aktor nie ma sensu. No bo ideowo to brzmi pięknie, zgodzisz się. Po prostu magia na magii, warstwa abstrakcji, która wygląda absolutnie fenomenalnie. Więc pytanie: czy ruszamy teraz z mówienie kiedy (…)?

Łukasz Kałużny: Wiesz co, przejdźmy, ja bym tylko dorzucił jeszcze, tak jak popatrzymy na technologię, bo znajdzie się teraz framework wieloplatformowy Proto.Actors, który gdzieś tam się rozwija z boku i zdobywa fanów. Następna wpadka też jest na Golangu pod spodem. Następna wpadka, która jest Microsoftu, nazywa się Dapr Actors. Czemu mówię wpadka? Pomysł był idealny z Daprem i aktorami. Wykonanie było niestety microsoftowe i mimo chęci, że użyli Golanga i innych rzeczy, oddali to do CNCF-u, nie wylazło przez swoje… Tak jak KEDA na przykład stała się new normal, bo to jest ten sam moment wydawania projektów. Tak Dapr w ogóle się i jego model aplikacyjny się nigdzie nie przebił. Plus…

Szymon Warda: Tak, Dapr (…).

Łukasz Kałużny: Plus ludzie, którzy pisali Dapra, tak, ludzie, którzy pisali Dapra, mieli dostęp do ludzi z Orleansa, bo to był Microsoft i podpatrzyli bardzo dużo konceptów.

Szymon Warda: Bo to idealnie, Dapr się bardzo ładnie uzupełniał z modelem aktorów. Abstrakcja nad to, czy go wykorzystujemy i tak dalej. No to super właściwie.

Łukasz Kałużny: Możecie zerknąć sobie jeszcze na Beama, czyli maszynę wirtualną Erlanga i Elixira i zobaczyć pradziadka tego wszystkiego, czyli pierwszą poważną implementację, jak popatrzymy, która była w tamtych czasach mocarna. I teraz jak Ty Szymon mówisz: skąd to w ogóle się ten? Gdzie to jest użyteczne? Ja bym wrzucił tutaj wątek Microsoftu, który tych aktorów pod spodem w swoich mikroserwisach, Azure i innych rzeczach naprawdę miał nawsadzane swego czasu i niektóre do dzisiaj koncepcje są. Jak pójdziemy, to tam była taka platforma do digital twin nazwana Fabric koncepcyjnie. I to jest 2001 rok, gdzie oni zaczęli w researchu i wokół tego budować, gdzie nazwali to potem Distributed Fabric, jak ogłosili Azure’a, a potem postawili na tym SQL Azure i inne silniki bazodanowe.

Łukasz Kałużny: Tam się dużo (…).

Łukasz Kałużny: Tak. Z czego wyrosło potem taka usługa znienawidzona przez wielu .Netowców bym powiedział albo, bo chcieli robić Kubernetesa i nazywała się Azure Service Fabric, który genialnie rozpędził całe klastrowanie i kupa usług w Microsofcie po dziś dzień na tym działa.

Szymon Warda: Ale to była kolejna usługa, która ok, była przeskomplikowana, za bardzo skomplikowana, ale która bardzo mocno wyprzedzała wiele rzeczy.

Łukasz Kałużny: Ale, tak Szymon i teraz tak, powiedzmy ten wzorzec reliable actors i inne rzeczy, które tam wprowadzili w tym Fabricu, ja uwielbiam definicję małego klastra w Microsofcie przy Service Fabric (…) rozwiązaniach. 5000 maszyn wirtualnych, to jest definicja małego klastra i małego high availability. I to jest, powinno dać do myślenia. Te technologie powstały po to, żeby… One są szybkie z perspektywy skali i problemów, które ma taki Microsoft. Czy tak samo jak pójdziemy do Borga w Google’u, to są ich problemy i one tam mają miejsce na modelowanie tego.

Szymon Warda: Znaczy, tam można wchodzić w szczegóły, ale tam idea programistyczna była bardzo fajna, bo ona była bardzo mocno odcięta, wycinała… To był znowu taki pradziadek właśnie tego Dapra, bo Dapr do podobnych celi próbuje dojść, tylko na trochę innym API.

Łukasz Kałużny: Słuchaj, główny ojciec Dapra pisał Fabrica. To jest też taka rzecz, bo Mark, bo Mark pisał Fabrica, więc… A teraz założył startup, bo ma jakiś standard celowany do Enterprise’u u boku Dapra. Dobra. I chyba pierwszą rzeczą, taką najbardziej popularną, jeżeli chodzi o modelowanie. I teraz uwaga, nie implementacja a modelowanie. Czyli to, co mówiliśmy na początku odcinka, to cały ten Agentic AI, jeżeli go poprawnie zamodelujecie i zobaczycie sobie, co Wam wyjdzie, jakbyście nie rysowali, to jest agent.

Szymon Warda: Aktor.

Łukasz Kałużny: Aktor = agent. I nie mówię od spodu o… To jest model mentalny, nie fizyczna implementacja od A do Z. Aczkolwiek może być, jeżeli pójdziecie w detale, w pewnym sensie.

Szymon Warda: No tak, ale wchodzimy, też drugi element to są te urządzenia IoT, które stały się już no po prostu przykładem takim koronnym. Azure IoT też tak śmiga, więc to jest ten obszar, gdzie to się sprawdza najlepiej tak naprawdę.

Łukasz Kałużny: Dobra, to chodźmy do tych realnych wzorców użycia. Słuchaj, ja bym tak powiedział sobie tak, że sztandarowym chyba będzie to, co będzie w Bloperze, które gdzieś pójdzie, to jest WhatsAppic, to jest sztandarowy przykład z takich bardzo dużych. Jeżeli zerkniecie teraz na różne informacje, to są wokół, znajdziecie trochę informacji wokół tradingu. Było to Halo, o którym powiedzieliśmy, jako multiplayer. Więc znajdziecie, że one w wielu miejscach, ten model aktora sam z siebie w wielu miejscach gdzieś komuś przeciekł i się chwalą tym, że to wykorzystali w ten sposób.

Szymon Warda: Ale to są konkretne miejsca. Miejsca, gdzie masz duży ruch, potencjalnie z dużymi wahaniami ilości tego ruchu i wysoce równoległy i potrzebujesz odwoływać się do pojedynczych instancji, czy to urządzeń IoT, czy rozgrywki, czy aukcji, czy czegokolwiek innego. Nie masz kwerend globalnych. To jest przede wszystkim bardzo ważne.

Łukasz Kałużny: Inaczej, tak i chcemy się pozbyć, to jest z mojej perspektywy, przez tą jednowątkowość chcemy się pozbyć też race condition i logów, na przykład na bazie danych i innych takich rzeczach, że nie musimy się o to martwić, że wszystko walimy w jedno miejsce i wiemy, że tam zostanie, w zależności jak mamy zaprojektowanego mailboxa i dostarczenie do niego, że tam zostanie to wszystko w jednym miejscu rozproszone. I w sumie można sobie teraz tak, jakbyśmy popatrzyli, kiedy się nie pakować? Bo to jest w ogóle idealny odmiennik. Czyli tak, bezstanowy chroot.

Szymon Warda: Łukasz, z definicji nie pakujemy się w aktorów. To jest jedna z tych architektur, gdzie generalnie doskonale wiesz, kiedy tego użyć, bo masz dokładnie ten problem. A jak szukasz problemu do tej architektury, to robisz to absolutnie źle.

Łukasz Kałużny: Tak. Czyli inaczej, czyli tak, bezstanowy chroot odpada, nie ma sensu. Uda Ci się, ale nie ma sensu. Transakcje przez wiele encji. Kiedy potrzebny Ci distributed transaction, no nie, na pewno nie zadziała. Globalne zapytanie i raporty, twarde limity na przykład, że tylko 100 sztuk w całym systemie. Inna rzecz to mała skala, też nie ma sensu. Całe batche i analityka. Rozproszone monolity, jak wam wyjdą w tym. I powiedziałbym, że brak naturalnej tożsamości. To mi w ogóle, jak tak popatrzyłem na to, to jest świetna definicja, czyli aktor per czasownik, to też nie ma sensu.

Szymon Warda: Znaczy tam jest jedna ważna rzecz, bo z tej całej naszej rozmowy, co tak sobie mówimy, mówimy, mówimy, to ten wirtualny aktor wygląda jako super sposób na hostowanie mikroserwisów. Nie, to nie jest do tego. Mikroserwisy są sposobem na rozbicie runtime’ów. A aktor rozbija runtime i stany, tą niezależność wprowadza, no nie. Więc takie małe ostrzeżenie, to nie do tego kompletnie.

Łukasz Kałużny: Więc zostawmy to sobie w miejscu, w takim modelu mentalnym w większości problemów, żebyście wiedzieli, że coś przypomina i można z tego czerpać inspirację do rozwiązania problemów, jeżeli na to traficie. I tutaj będzie teraz koronny przykład z hot tematów, to jest w tym miejscu, Agentic AI w ten sposób można zamodelować.

Szymon Warda: Dokładnie. Dobrze. Tyle Łukaszu?

Łukasz Kałużny: Tyle i dla nerdów takich jak ja czy Ty Szymon, bo niestety masz ten pierwiastek nerda w sobie głęboki, jak byśmy jeszcze poszli zaraz.

Szymon Warda: Ale ja się nie wstydzę, ja jestem z tego dumny.

Łukasz Kałużny: Ja wiem, ale żeby Was nie zanudzić, to zostawimy całą notatkę. Tak, wyjątkowo cała notatka idzie na Discorda, więc ją tam znajdziecie. A wrzucimy tam taką nerdowską zajawkę dlaczego jest to modelowane z perspektywy, aktor jest z perspektywy fizyki a nie matematyki.

Szymon Warda: Znaczy w ogóle notatki może będziemy wrzucali tak naprawdę, to są…

Łukasz Kałużny: Może tak.

Szymon Warda: (…) notatki.

Łukasz Kałużny: To zależy które. Niektóre nigdy nie powinny ujrzeć światła.

Szymon Warda: Tak i czy w ogól były, od tego zacznijmy też.

Łukasz Kałużny: Dobra, słuchajcie, dlatego że to jest ostatni odcinek, nazwijmy to, studyjny, to do usłyszenia przy dwusetnym i drugi tydzień września słyszymy się ponownie. A w międzyczasie Discord, newsletter i zostawcie pod tym znowu jakieś randomowe osiem słów na YouTubie, tudzież subskrybuj, lajka pod odcinkiem.

Szymon Warda: Dokładnie. Miłego! Trzymajcie się! Hej!

Łukasz Kałużny: Na razie. Hej!