Over deze aflevering
Deze keer is Raymond Roestenburg te gast. Ray Roestenburg werkt bij Lightbend als Tech Lead in het Akka Platform team met Cloud-native initiatieven met een focus op Akka en Kubernetes. Daarnaast werkt hij ook aan Cloudflow. Hij is de auteur van 'Akka in Action' voor Manning publications. Aan het coden sinds de Commodore 64 in de 80's..
Delen
// Gasten
Wat je leert#
- •Wat het actor model inhoudt en waarom je het gebruikt
- •Hoe je concurrency problemen aanpakt met Akka
- •Waarom microservices organisatorische problemen oplossen
- •Hoe je een technisch boek schrijft en publiceert
- •Wat event sourcing en persistence in Akka betekenen
Transcript
Welkom bij aflevering 16 van CodeKlets. Vandaag zijn we weer de host Kishen en ik, zoals verhoudt.
Dat is alweer een postje gelegen dat wij met z'n tweeën deden.
Yes, sir.
Ja, zeker. En we hebben vandaag weer een hele leuke en interessante gast.
En dat is Raymond Roestenburg. Ja, welkom Raymond.
Dankjewel.
Oh, sorry. Nu zeg ik Raymond en niet Raymond. Maakt dat nog uit?
Nee, dat maakt mij niet uit. Raymond, Raymond, dat maakt niet uit.
Misschien moet ik gewoon Ray zeggen, dat is het makkelijkste.
Maar goed, Ray Roestenburg werkt bij Lightband als tech lead in het Akka platform team.
Ray werkt tegenwoordig aan cloud native initiatieven van Lightband met een focus op Akka en Kubernetes.
Daarnaast werkt hij ook aan Cloudflow, een open source project voor distributed streaming applications op Kubernetes.
Hij is de auteur van Akka in Action, daar komen we strakken natuurlijk ook op terug, voor Manning Publications.
Manning is best populair, daar hebben we steeds gast van.
Ja, zeker. De tweede, vorige was Meint.
Ja, dat klopt. En hij is aan het coden sinds de Commodore 64 in de jaren tachtig.
Kijk, dat is al een poos gedeen.
Welkom, welkom Ray. Cool.
Dank je wel.
Ja, waar zou ons gaan beginnen?
Want je zegt net, of jij zegt niet, in je bio staat mooi dat je bent begonnen met programmeren met de Commodore 64.
Is dat ook echt de eerste programmerervaring of was er nog iets geks daarvoor?
Nee, dat was wel de eerste programmerervaring.
Ja, dat was echt, begon natuurlijk heel simpel zoals iedereen met je eigen naam op het beeld zetten.
En dat soort dingen, weet je, loopjes maken en dat ging verder naar spelletjes aanpassen en wat met sprites sloten en dat soort dingen.
Dat was wel heel leuk.
Ja, dat klopt. Ja, dat klopt ja.
En welke game heb je, kan je dat nog herinneren, welke games je hebt aangepast?
Nou, die games aanpassen was pas later op de MSX. Ik had later een MSX, een andere homecomputer, als je het wilt kennen, denk ik.
Nou, nu zijn we weer vrienden.
Ja.
Want je begon met de Commodore en dan denk je, ja, wacht eens even. Nee, nee, oké, cool.
Ja, Commodore 64 was de eerste en toen vriendje van mij had een MSX en dat kwam op bepaalde spelletjes heel erg leuk.
Dus toen MSX 2 uiteindelijk.
En daar had je een aantal games die, ja, dat kon je redelijk eenvoudig, kon je teksten in aanpassen of je kon verschillende dingen uitproberen met peaks en pokes.
En ik weet de helft wel niet meer van, maar dat was wel heel leuk om te doen.
En ja, een spelletje heet The Feedback, maar ja, het lijkt een beetje op een spel van Sega, waar ik ook wel de naam meer van weet.
Maar het is al een tijd geleden.
Maar genoeg spelletjes die je het simpelweg aan kon passen in die tijd, omdat de code natuurlijk eenvoudiger was op dat moment.
En kan je nog herinneren in wat voor programmeertal het was?
Dat was in Basic. Ja, dat was voornamelijk in Basic.
En er waren ook wel wat spelletjes die waren waarschijnlijk in december gemaakt.
Maar daar kon je dus, daar verander je niet zozeer de source code, maar gewoon de, ja, ik neem aan dat het binary code was.
Ik weet al helemaal niet meer hoe dat deden, maar je had ook bepaalde hex editors voor.
Dan kon je hex editors, dan kon je gewoon dingen aanpassen.
En dan veranderde er wat in het spel en dat vonden we wel heel gaaf om te doen.
Als je jongen kiest van een jaar of 11, 12, zeg maar.
Dus je moet er niet altijd veel bij voorstellen. Maar het was wel heel erg leuk.
En ja, met de Commodore een aantal sprites gemaakt en te kijken van wanneer is het botsen, zeg maar, wat je dan moet doen.
Dus dat was al heel snel, voor mij was het van, oh, dat lijkt me heel erg gaaf om een eigen spelletje te maken.
Dat soort dingen. Daar was er nooit echt helemaal van gekomen.
Ik heb wel wat gehobbyd met een aantal shoot-'em-ups van die ouderwetse shoot-'em-ups gebouwd.
Game level designers gemaakt, dat soort dingen met DirectX en zo.
Dat was al weer een tijdje verder natuurlijk in de tijd.
Maar dat was meer zo van, oh, hoe zou het eigenlijk moeten?
Wat heb je er eigenlijk allemaal voor nodig?
En als het op een moment erachter kwam van, oh ja, dit werd ongeveer zo, dan hield het er vaak mee op.
Dus ik heb een aantal halve games gemaakt, zeg maar, als hobby ooit.
Gaaf, man.
Leuk tijd ook, denk ik.
Ja, het was super.
Ik weet ook nog dat je een spelletje van de radio op kon nemen, weet je wel?
Ja, dat is gewoon heel apart.
Op de trost zat dat toch?
Ik weet niet hoe het programma heet.
Ja, dat klopt, ja.
Dat is echt bijzonder, toch?
Dat je een radio programma neem je op en dan kun je dat afspelen en dan laat je dat programma heen.
Ja, dat was een hele interessante tijd inderdaad.
Het was allemaal gewoon helemaal nieuw.
En ja, je ging gewoon naar vrienden of naar andere mensen die je dan tegenkwam van, oh, weet je hoe dat moet?
En had iemand weer een tooltje om wat te kopiëren of wat dan ook?
En zo ging het verder.
Ja, dat was nog echt innovatie.
Ja.
Ja, precies.
Voor ons was, voor mij, ik zat ook een beetje in die tijd, want Conde64 was ook een beetje mijn...
Die heb ik nooit gehad, maar daar ben ik wel door mee in aanraking gekomen met programmeren.
En later ook de MSX 2 jaar.
En alles was gewoon, dat hebben we eerder ook wel eens besproken, maar alles, je had geen internet.
Dus je moest gewoon boeken en via andere mensen moest je aan informatie komen of zelf uitvinden.
Precies.
Ja, dat is wel bijzonder.
Kun je je eigenlijk niet meer voorstellen dat je dat nu...
Iedere drie regelscoden die ik schrijf hebben Google nodig.
Dus dat is echt...
Ja, ja, ja.
Ja, ik weet ook nog, met mijn studie moesten we een soort van animatieprogramma maken.
Dat was op de HTS.
En dan moest je een paar momenten bitmaps inladen.
Ik had een boek van Charles Petzold en dan ging ik echt gewoon pagina voor pagina overtypen, weet je wel.
Die had gewoon niks.
Nee, klopt, ja.
Ja.
Ja, en ik kan me ook nog herinneren op school over HTS gesproken.
Dat ik ook een keer zo'n gameontwikkelvak had, een module of zoiets had gekozen.
Dan was het inderdaad echt zo'n heel dik boek.
Waar al die sprites ook in uitgelegd werd en zo.
En dan was het inderdaad letterlijk gewoon...
Het was volgens mij heel veel in C, dacht ik.
Ja, ja.
En ja, dat was inderdaad gewoon overtypen, weet je wel.
En dan hopen dat het weer ging werken.
Dus ja, dat was geen internet.
Ik las trouwens ook een heel interessant artikel van Container Solutions.
Een tijdje terug.
Die ken je wel, hè.
Dat is best wel een gaaf bedrijf ook.
Wat heel erg gericht is op Container Solutions.
En die vertelden dat er iemand was die allemaal Sega games, ook in docke containers...
Ja, ik zal hem straks...
Ik zal hem ook even in de notes delen.
Ik vond dat ook wel bijzonder.
Om het in een container te doen, ja.
Ja joh, bizar, ja.
En daarna ben je zeg maar...
Nou goed, je zei net dat je op de ATS gezeten hebt, software ontwikkeling gedaan, bla bla.
Ja, ja.
En wat ben je daarna gaan doen?
Ben je meteen...
Whatever.
Ik weet niet welk jaar hebben we het eigenlijk over.
Ik ben begonnen met zijn werk in 97.
En toen heb ik een tijdje Oracle gedaan, Oracle Development gedaan.
Dat was op een bepaalde moment toch een beetje saai.
Toen ben ik toch weer op meer Java gaan doen, want ik was op het ATS op het einde ook op het Java bezig.
En een tijdje bij de telegraaf gezeten, bij de financiële telegraaf.
Wel wat leuke dingen gedaan.
En zo was het eigenlijk gewoon consultancy zeg maar.
Java consultancy is dan voornamelijk het werk geweest voor best wel wat jaartjes eigenlijk.
Even kijken hoor.
Toen ben ik zo rond 2003 naar Zuid-Afrika verhuisd.
Mijn vrouw komt daar vandaan.
Dus ben ik daarheen gegaan om daar te gaan wonen.
Toen heb ik daar vier jaar gewoond.
Toen heb ik ook daar eerst wat Java gedaan.
En toen .NET, het bedrijf switchte over van Java naar .NET.
Dat heb ik een paar jaar gedaan.
Toen heb ik naar Nederland gekomen met situaties.
En toen heb ik daar ook weer .NET gedaan voor zo'n twee, drie jaar denk ik.
En toen weer een opdracht gedaan in Java.
En dat was een message broker voor wegverkeer in Nederland.
En toen kwam ik erachter van, oké, dit is toch wel vervelend af en toe, de concurrency problemen.
Het was best wel pittig.
En toen had ik mijn eigen soort van herbruikbare dingen gebouwd.
Maar ja, goed, natuurlijk niet helemaal volledig.
Het moest ook wel in dienst zijn van het project.
En toen kwam ik op een bepaald moment Akka tegen.
Volg op dat moment Dean Wampler.
Hij heeft ook wel het boek over scalen geschreven en dat soort dingen.
En die heb ik later nog mee gewerkt bij LiveBait.
En die zei ze van, oh, je moet Akka 0.7 uitproberen via Twitter.
Ik denk, wat is dat nou, Akka? Weet je wel.
Dus ik ben gaan kijken en dat ik, oh, dit is precies wat ik moet hebben.
Het is gewoon helemaal, wat ik ook eerder eigenlijk zelf,
maar ja, in een veel minimaalere zin natuurlijk,
gemaakt heb met threads en mailbox en queues.
Het handelen van exceptions.
En toen heb ik dat gebruikt in een project bij bedrijf Wijktoenwerk de CSC.
Voor de Konker commercial C.
Dat is een systeem om bij de grens
allerlei activiteiten in de gaten te houden via camera's en radars,
maar ook via patrouille auto's die rondrijden.
En dat was dus een gedistribueerd systeem met allerlei sensorlocaties.
En ik zag daar al aankomen, al die verschillende sensoren,
verschillende systemen, zowel in auto's gebouwd als boven de weg.
Om al die informatie terug te brengen.
Dat dat een hele uitdagende case zou zijn met de traditionele concurrency en distribution tools.
En toen kwam ik Akka tegen.
En toen zag ik al heel snel, het zag er vroeger anders uit die website,
maar daar hadden ze een klein stukje code over,
over wat een actor is, zeg maar.
En dat sprak me meteen aan.
En na even in de code te kijken en wie eraan gewerkt had, et cetera,
was al weleens nou duidelijk van dit is niet zomaar een framework
dat iemand eventjes open source heeft gezet.
Het zijn gewoon een aantal vooraanstaande mensen die aan de internals van de JVM
bij J-Rocket volgens mij hebben gewerkt.
Dus ja, dat was ik wel meteen geïnteresseerd.
En zo ben je daar terecht gekomen bij die Akka technologie, zeg maar.
Ja, oké.
Dus dat is wel grappig, want dat je dan eigenlijk,
ten eerste de ideeën die je zelf ook al had,
dat je die dan ergens anders, ja, op een grotere schaal misschien,
dat je die dan weer terug ziet.
Dat is wel een soort van bevestiging van, ik zie je wel, ik zat goed.
Ja, het is heel lastig met threads.
Als je, oké, ik wil iets concurrent doen, oké, dan start ik een thread.
Oké, hoe communiceer ik nou met dat ding wat in die thread draait,
in die run method, wat ga ik doen?
En dan kom je de primitieve tegen, dan kom je de verschillende queues tegen.
Oké, ik kan iets op een queue gooien en dan kan ik het daar weer afhalen.
Nou, dan gebruik je de verkeerde queue een keer en dan loopt het helemaal mis, zeg maar.
En daarnaast, er kunnen exceptions gegooid worden in die thread.
Ja, wat doe je daar dan precies mee? Hoe communiceer je die?
Nou, dan moet je eigenlijk weer een soort van queue voor hebben of iets anders,
of een mechanisme dat je kan zeggen van, hey, dit ding is kapot,
hij moet opnieuw beginnen.
En daar had ik een hele gelimiteerde, of tenminste,
ik had het, zeg maar, het probleem door mij en had ik gelimiteerd gezien in mijn applicatie.
En dat ging toch ook niet altijd helemaal goed, zoals bij iedereen.
En ja, dat was af en toe best wel pittig met de low-level primitives, zeg maar, van Java concurrency.
Ja, dat is in Java toen, ja.
Want ik, het enige wat ik, goed, Kishen zei toen van oké,
we kunnen iemand uitnodigen die iets met Akko heeft gedaan.
Toen dacht ik, ik ben een .NET ontwikkelaar, dus ik dacht, oh ja, dat is een .NET.
En je weet gewoon, dat is bij heel veel van die projecten, zeg maar, opstorspecten,
waar .NET achter staat, dan weet je, waarschijnlijk is er een project, zeg maar,
wat eigenlijk van Java afkomt.
En daar hebben ze een .NET variant van gemaakt.
Ja.
En dan komt Microsoft en die zegt van, hey, die open source shit moet je niet doen,
joh, we gaan het voor je doen.
En dan is de open source u weg.
Ja, dat is wel waar, maar dat is me eerder als gelukkig,
maar dat zul je misschien zelf ook wel een beetje mee hebben gekregen,
dus de laatste vier, vijf jaar is dat wel heel erg omgeslagen, gelukkig,
want Microsoft is gewoon open source all the way tegenwoordig.
Ja, precies.
Dat is wel veranderd, maar dat is wel zeker zo, zeker,
onder Steve Ballmer was het wel een beetje evil,
of ten eerste not done om iets over open source te roepen.
Dus aka.net, ja, dat kende ik zeg maar.
En ja, dat was een beetje het uitzoeken van hoe het nou zat.
Ik heb eerlijk gezegd nog nooit met het,
en dat is trouwens wel een vraag ook,
het actor model heb ik niks mee gedaan,
want ik heb wel iets in productie gezet met event sourcing en CKRS.
En gedistribueerde systemen,
dat is ook wat we voor de opname ook al een beetje zei,
van ja, het is een beetje, hoe zeg je dat?
Systemen worden steeds, ja, complexer misschien wel.
Het is helemaal heel gangbaar.
Nou ja, misschien worden bijna alle,
nee, niet bijna alle systemen,
maar heel veel systemen worden in de cloud geontwikkeld.
En dan is het gewoon belangrijk om na te gaan denken over ja,
hoe werken nou gedistribueerde systemen?
Hoe zet je die goed op en hoe moet je met performance omgaan?
Wat voor architectuur ga je gebruiken?
Ga je een monolith gebruiken of neerzetten?
Of wil je microservices gebruiken?
En daar komen best wel allerlei vraagstukken naar boven.
Want het is, ja,
iemand die enorm veel ervaring heeft,
zal nooit zeggen dat het ingewikkeld is of moeilijk,
maar het is wel een complex verhaal.
Je moet aan best veel dingen denken.
Dus binnen die gedistribueerde systemen, zeg maar,
is ACCA een van de manieren om, zeg maar,
zoiets op te lossen?
Zie je dat anders of kun je dat toelichten?
Ja, ACCA is begonnen als een soort van toolkit,
waarin je een aantal tools hebt,
die voor dit soort situaties handig zijn.
En daar is het mee begonnen.
Dus initieel was het een actor-based library, zeg maar,
en daar werd steeds meer bovenop gebouwd.
Het was altijd wel vanuit het begin al bedoeld
als actors zijn zowel lokaal als distributed.
Dat was altijd de idee.
En daar zijn over de jaren heen verschillende modellen voor gebruikt
om dat te uiten, zeg maar.
Dus initieel kon je twee actors met elkaar praten
over een remote connection.
En nu is dat uiteindelijk terechtgekomen in een cluster-technologie.
Dus je kan actors in een cluster hebben.
Maar dat is niet het totale beeld,
want je kan alle dingen in de toolkit gebruiken
of een klein gedeelte ervan.
Dus daar zit best wel veel ruimte in.
Je kan zeggen, die dingen wel, die dingen niet.
Er zit bijvoorbeeld ook CRDT-support in
voor de Conflict-replicator-data-types,
om bijvoorbeeld zoiets als docs.google.com te maken,
dat je tegelijkertijd schrijft in documents
maar dat het wel uiteindelijk eventually klopt,
wat je opgeschreven hebt.
Maar er zitten dus ook bijvoorbeeld persistent actors in.
En die kan je weer gebruiken voor een situatie
waar je je systeem partitioneert of shard
in verschillende entities,
waarbij je heel erg hoog kan schalen
in de zin van in-memory stateful processen.
Dus het extra model bestaat eigenlijk uit
een aantal onderdeeltjes of het bestaat uit een...
of nee, dat is misschien niet de makkste manier om het uit te leggen.
Wat het lastig maakt, zoals ik al eerder ook al zei met die threads,
is dat het lastig is om te communiceren tussen threads
of om ervoor te zorgen dat je niet enige andere fout maakt
in concurrency, waardoor je race condition krijgt
en al dat soort dingen.
Dus het actor model is een ander soort model
waarin je praat in vorm van actors.
Een actor is een soort van object
waar je berichten naar kan sturen.
En je actor kan dan weer reageren met berichten.
Dus het is heel erg berichtgedreven, als je dat zo kan nog kunnen zeggen.
En een aantal garanties worden daarbij gesteld.
En dat is dat als jij een actor schrijft
en je krijgt een berichtje binnen, of je krijgt berichten binnen,
dan krijg je die berichten altijd één voor één binnen.
Dus je kan een soort van, ja, wat heet het, een receive kan je schrijven
waarin verschillende soorten berichten binnen kunnen komen.
Dus bijvoorbeeld een bericht heet ping
en dan stuur jij een bericht terug pong.
Dan maakt het niet uit van wie die berichten komen
of hoe concurrent ze aankomen.
Als actor zijn, dan kan je ze één voor één verwerken.
Het sturen van de berichten en het ontvangen van de berichten
is allemaal asyngroon. Dus je wacht eigenlijk nooit.
Je bent nooit aan het blokken op iets.
Dus je bent geen fret aan het vasthouden of wat dan ook.
En alleen dat al, alleen dat principe al, zeg maar,
dat je heel eenvoudig één voor één berichten kan afwerken,
dat is een heel groot voordeel.
Een actor kan ook andere actors maken.
Dus je kan een soort van hiërarchie maken
van parents and children, om het zo maar even te zeggen.
En wat daar ook heel interessant aan maakt,
is dat als een actor, als er wat fout gaat in een actor,
dan is het standaardbordeel om er eigenlijk niet veel aan te doen
en gewoon om die actor te laten crashen.
Wat er dan gebeurt, is dat de parent van die actor
doorheeft van oh, er is iets verkeerd gegaan
en die kan dan bepalen wat er moet gebeuren.
Dus in plaats van dat je alle problemen op moet lossen
op het laagste niveau van je applicatie kan je zeggen,
ik hou er gewoon mee op, ik geef het door naar boven.
En dan kan op het hogere niveau,
misschien ook wel op basis van meer informatie,
want er kunnen meerdere actors zijn,
kan dan een beslissing genomen worden.
Dus dat is in zekere zin,
als ik het zo heel snel uit probeert te leggen,
je ontvangt berichten, je verstuurt berichten
en alles wat je doet
is eigenlijk in zekere zin single-threaded.
In de zin van je elke keer heb je een berichtje.
En wat nog belangrijker is,
die actors daar kan je er miljoenen van hebben.
Een thread is heel erg zwaar.
Misschien heb je max 400 threads of 1000 threads,
maar bij de actors kan je naar de miljoenen actors gaan
als je dat wilt.
Dus ze hebben sowieso veel minder geheugen nodig.
En eigenlijk wat ze doen onder water,
delen actors een threadpool.
Dus al die actors die draaien op een threadpool,
dat heet een dispatcher,
en al die berichten die gaan op
een soort van queue,
elke actor heeft een mailbox.
En die mailbox die wordt door
de dispatcher heen geduwd
naar de actors die die berichten
kunnen verwerken. Dus daar zit een samenspel.
Maar door die opzet
kan je dus ook kiezen voor een andere dispatcher
voor jouw toepassing.
Als je zegt, ik wil gewoon een fixed thread dispatcher,
ik wil gewoon 4 threads hebben, en daar ga ik al mijn actors op draaien.
En dan gaan die actors die draaien dan boven op die 4 threads
en die gaan dan automatisch, zeg maar, krijgen ze een bericht
om het zo maar even te zeggen.
Ja precies, dus je kunt aangeven
van hoeveel resources mag dit systeem als het ware
dus het volledige gebruiken
door een restrictie uit te geven.
Oké, ja.
Nou hoor ik in ACCA
dat de actor model een rol speelt.
Zijn er ook andere dingen die een rol spelen binnen ACCA?
Ja, er zijn best wel veel.
Het heeft wel altijd
qua concept te maken met actors.
Er is nog iets anders en dat heet streams.
En streams zijn eigenlijk
een hoger level programmeer model
bovenop actors. Dus daar kan ik misschien zo meteen
het concept van actors
staat wel heel erg centraal in ACCA.
Daar is het wel zo dat er ook natuurlijk
het ACCA team heeft ook allerlei dingen gemaakt met actors.
Niet per se om
de gebruiker te forceren
om actors te laten gebruiken. Dus bijvoorbeeld
er is een library ACCA Http.
En daarmee kan je Http afhanden
in ACCA GRPC is een andere.
En die hebben allemaal api's
of DSL's hoe je ze wil noemen. Die niet per se
het noodzakelijk maken dat jij een actor maakt.
Dus je kan dan gewoon zeggen van als het een get of een post
complete met een ok,
dan schrijf je geen actors. Maar
ACCA Http is wel geschreven
bovenop streams en streams zijn bovenop actors.
Dus de actors zijn zeg maar
de core primitive ofzo.
De building block.
Dus het is
een manier van hoe je het gebruikt
merk ik. En je kan het ook zonder actor
models eventueel.
Het is zeg maar de primaire building block van de toolkit.
En in de toolkit zitten andere tools
die het net een level hoger maken.
Dus dan hoef je niet met de primitieve tool
te werken, maar met een DSL.
Maar in sommige gevallen is het heel erg handig
om de manier van
de actor model te gebruiken.
Wat ook heel eenvoudig is in actors is state machines schrijven.
Fijne state machines.
Want je kan in die actor zeggen ik ben nu in state A.
Dan krijg ik een berichtje. Oh, ik heb een berichtje gekregen.
Ga nu naar state B. Dus dan verander je je
receive method, zoals dat heet.
Dan zeg je van nou, tenminste dat is de oude manier.
Er is een aantal nieuwe APIs bijgekomen, maar
je kan op basis van een bericht naar een andere state switchen.
En die state switchings zijn ook weer
per bericht. Dus je krijgt nooit het probleem
dat je, oh ik heb in concurrently nog een bericht binnen gekregen.
Nu zit ik ineens in het verkeerde state.
Dus je kan heel netjes eigenlijk al die state machines
maken. En dat kan je van hele simpele dingen doen
of hele complexe dingen eigenlijk.
Als ik het mag samenvatten, een state model
zou je daarmee kunnen maken? Of zie ik dat verkeerd?
Nou ja, ik weet niet wat je daar precies mee bedoelt.
Nou, een model wat de
staat van het systeem beschrijft.
Ja, dat ga ik er zeker mee doen.
En dat je dan akka, noem het maar even,
gewoon al die details uitwerkt.
Ja, dus een van de dingen
die daarna vaak gebeurt, is
iemand maakt bijvoorbeeld een actor,
om een of andere businesslogica vast te leggen.
Dat is heel erg handig, want je schrijft
de API van de actor in vorm van berichtjes.
Get article, put article, weet ik veel.
Noem het maar op, ik ben al slecht in voorbeelden.
Maar zeg maar een shopping basket, waar je
een artikel terug toevoegt.
En nog een artikel toevoegt, waar een paar mensen zegt
ik ga dit spul kopen, dan ga ik naar een nieuw estate
misschien wel. En zo verder en zo verder.
En wat in ak ook mogelijk is,
om te zeggen van nou, ik wil, want al die informatie
die je een paar momentjes hebt, misschien wel een shopping basket
niet zo heel relevant, omdat die,
nee, gewoon een shopping basket.
Ik wou gewoon zeggen,
je wilt natuurlijk wel die blijk bestaan.
Als er wat crasht of terugkomt.
Als er even wat fout gaat, ok, maar je webbrowser refresh
wil je gewoon dat je shopping basket er weer is en niet dat je
20 artikelen bij de bijeenkomst, weet ik veel, dat die een keer weg zijn.
Dus
een techniek die bestaat in akka om
die state in die actor, dat state model vast te houden en ook weer terug
te krijgen na een crash.
Dat is de akka persistence module.
En dan kan je in een event sourced
manier, kan je de
dingen die gebeurd zijn met die actor, kan je vastleggen
in een journal.
Dus een event journal.
En dan kan je ook weer na een crash of
misschien gaat je shopping basket,
wordt er voor even niet gebruikt als je passivereert hem.
En dan na een tijdje komen we terug met shopping basket, dan wordt die weer
gerehydrate of deserialized
van de journal. En dat werkt gewoon
volgens de principes van event sourcing, zoals je die wel kent, denk ik.
Of wat je ook al even over zei.
Ja, die events worden zeg maar opgeslagen
en dan kun je eventueel, ten eerste bij
event sourcing, database of
whatever, je kunt dat snapshot eventueel, dan zou je ook
heel snel naar een bepaalde moment kunnen.
Ja, cool.
Dat zit ook in Acca persistence inderdaad.
Dus als ik het goed begrijp, zou je
Acca kunnen gebruiken, of nee, je gebruikt het vooral om
je applicatie zo robust en schaalbaar mogelijk te maken, toch?
Klopt, ja.
Zodat je de high performance kan
garanderen. Ja, high performance en schaalbaarheid
zijn wel de redenen waarom je Acca gebruikt.
En ook de robustheid, zeg maar, dat je ervoor kan zorgen dat het blijft
werken. En het geeft je een hele manier van werken
voor het maken van robuste software.
Door middel van
het feit dat die actors elkaar dus ook
kunnen opvangen, als het ware. Als zo'n probleem ontstaat.
ja, die
