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
Acca persistence daarin
is er ook een module die hoeft niet per se te gebruiken, want dat gaat al bijna iedereen.
Dat heet cluster sharding. Dus dan kan je
eigenlijk ook heel erg schalen.
En cluster sharding,
ik wil eigenlijk wat je opdraaien.
In Acca heb je dus actors. Die actors kan je draaien
in een actor system.
Zo heet dat. Als je programmeert, dan zeg je, nieuw actor system, of actor system in schalen.
En dan zeg je, oké, ik start
mijn main actor. Dat is gewoon een hoofdactor.
Een guardian, wat het vaak gaan noemt. En dan
daaronder maak je meer en meer actors die het echte werk gaan doen.
En dat is natuurlijk wel leuk, maar dan heb je
maar één JVM die draait met een aantal actors erin.
En Acca heeft
daarnaast dus ook Acca Cluster. En Acca Cluster
zorgt ervoor dat die actors die je in je actor system hebt,
dat die over een cluster van nodes
aanwezig zullen zijn.
En dan in cluster heb je weer een aantal tools.
En een van die is cluster sharding. En die zorgt ervoor
dat als jij zegt van, ik moet
shopping basket 1 hebben, dan weet Acca Cluster
wacht even, er is nog geen 1, die ga ik aanmaken.
Ik ga hem aanmaken op node 3 bijvoorbeeld.
En dan houdt hij bij, qua partitioning
als er berichten komen voor shopping basket 1,
dan ga ik altijd naar node 3, want daar zit een region
met allerlei actors erin,
die daar worden gespawned, die daar worden gecreëerd.
En zo kan je dus een heel schaalbaar systeem maken
die over meerdere nodes heen
al die state, al die actors
verdeelt.
Oké. Maar wat ik dan wel begrijp,
als ik het goed begrijp, dan zijn er qua
infrastructuur, voor lack of better word,
infrastructuur, want er is iets waar
al die actoren in leven, dus als je net
ook aangaf, dat systeem start en dan maak je actoren
daarin aan. En dan zijn er dus bepaalde
ja, is daar iets, ja daar hoef je niet
zelf te proberen, maar dat wordt door AKA aangeleverd
om te zorgen dat dat dan kan plaatsvinden,
zeg maar, dus dat ze eventueel messages
met elkaar, aan elkaar doorgeven of
hoe moet je daar zelf iets voor doen?
Dus stel dat bijvoorbeeld actor 1 iets wil
sturen naar actor 2, wordt dat dan voor jou
gedaan of hoe? Dan wordt dat
in zekere zin voor je gedaan.
Dat is niet, als jij zeg maar van
actor 1 met actor 2 wil praten, dan
moet je van actor 2 de actor
reference hebben. En die actor reference
die kan je op verschillende manieren krijgen, je kan ook
vragen aan het actorsysteem, heb jij
een actor met dit pad, dus alle actors zitten
achter een soort van uniek pad, als het ware.
En actor references kunnen ook wijzen
naar een remote machine of kunnen ook wijzen naar
een actor op het cluster.
Dus er zijn verschillende manieren daarvoor.
Alleen in zo'n algemeenheid
wat je normaal gesproken
zou doen, is dat je zegt van nou, ik ga gewoon een aantal
JVM processen opzetten. En die JVM
als onderdeel zijnde van hetzelfde cluster, die hebben
ook allemaal gebruiken dezelfde code.
En bij het opstarten van zo'n cluster
is er een bootstrap moment om het cluster
aan elkaar te connecten als het ware.
Dus die actorsystems die zien, oh, er is eentje up.
Ik ga ook up. Dan is er een bepaalde leader, een soort van exchange
en een soort van handshake die gewoon gebeurt. En op een bepaald moment
worden die nodes, al die nodes worden onderdeel van dezelfde
groep, krijgen dezelfde group membership, zoals het heet.
En op dat moment kunnen de actors in de tusser met elkaar
praten. En wat er vaker gebeurt
is dat je gewoon zegt van nou, ik ga een cluster
sharding systeem opzetten voor shopping baskets bijvoorbeeld.
En de ene shopping basket praat niet met de andere shopping basket.
Dat is niet zo snel iets wat er gebeurt. Maar het zou wel kunnen
zijn dat je misschien een andere
service of iets wat gedeeld is door
verschillende actors aanspreekt via een bepaalde actor reference.
Alleen
ja, er zijn dan wel wat
ja, er zijn heel verschillende
manieren om het natuurlijk te doen. En wat wij nu proberen
te doen bij Lightband is ook om op een platform guide
of we proberen hem niet te hebben. We hebben een platform guide
om je uit te leggen van hoe ga je dit nou allemaal doen?
Want er zijn heel veel keuzes en ik weet nog van heel lang geleden
dat ik als consultant akka overal ging
doen zegmaar. Dan werden altijd
veel dezelfde vragen gesteld van ja, hoe gaan we
waarom moet ik hier nu een actor gebruiken? Of hoe gaan we ervoor zorgen dat
ze allemaal in het cluster draaien? Of hoe zorgen we ervoor
dat die altijd blijft bestaan? Of dat er
van sommige dingen moet ik er altijd één hebben in plaats van
één in het hele cluster, want er is één
centraal ding hoe je zegt. Dus daar
omdat het dus zo'n toolkit is waar je heel vrij uit kan kiezen
is het ook voor veel mensen best wel een lastig
ding om zomaar even
mee te beginnen, want er zijn heel veel onderdelen.
En daarom hebben wij
ik weet niet hoe lang we dit al doen, in ieder geval wel een paar maanden
hebben we de akka platform guide
en die laat je zien
hoe je microservices met akka schrijft op een
terminatet manier, in de vorm van event sourcing
in de vorm van events, in de vorm van
views, we noemen dat projections
en in de vorm van
in de vorm van die
persistent actors die ik net zei.
En dat ook in combinatie met GRPC.
En daar hebben we nu
ook recentelijk hebben we daar een product voor gebouwd
voor Amazon.
Dus in Amazon kan je de
akka cloud platform vinden.
En daarmee kan je
gemakkelijker op Kubernetes zo'n akka microservice
deployen.
Dus dat is wel een goede vraag, want er zit heel veel infrastructuur
altijd bij, van hoe start ik nou het hele systeem.
En dat is best wel een uitdaging voor veel mensen.
En dat is ook een van de redenen
waarom ik eerder aan Cloudflow gewerkt heb.
Cloudflow is ook een project van lightband.
Het doet iets vergelijkbaars, maar dan voor streaming applications.
Dus voor realtime streaming applications en in combinatie met
streaming platforms.
Want er wordt gewoon altijd weer wat ergens draaien, weet je wel.
En tegenwoordig is het bij altijd Kubernetes, dus
daar heb je gewoon wat hulp bij nodig, vaak.
En ja, je noemt net lightband.
Kan je daar iets meer over vertellen voor
mensen die het nog niet kennen?
Ja, lightband is het bedrijf dat achter
ACA zit eigenlijk. Het heet vroeger TypeSafe.
Op een bepaalde manier hebben ze die
namen veranderd, want ze werden elke keer verkeerd aangeschreven
als Typeface of iets anders.
En dat ging ook op een bepaalde manier.
Het is meer dan alleen maar
TypeSafe programming languages, weet je wel.
Dat is ook een naam vanuit Scala.
Dus de bedenker van ACA,
Jonas Bonner, die heeft op een bepaalde moment
begonnen met ACA,
een bedrijf vormeentjes gestart, het heette
Scalable Solutions. En uiteindelijk
zijn ze gaan praten met Martin Odersky, de maker van Scala.
En die hebben toen samen een bedrijf gestart
10 jaar geleden denk ik.
Ja, 10 jaar geleden ongeveer.
En die zijn een bedrijf gestart, TypeSafe.
En die wilden die combinatie van Scala
en ACA aan de markt brengen.
En uiteindelijk is Lightband de nieuwe naam van dat bedrijf al een hele tijd.
Maar dat is het bedrijf dat
achter Scala zit en achter
ACA de toolkit. Maar we hebben ook
we doen nu al iets minder mee, maar we hebben ook
Play en Lightbombs, andere frameworks die we ook doen.
Ja, vind ik zelf wel
we zijn ook heel erg gefocust op de Java community.
Want er zijn gewoon veel meer Java-programmeurs dan Scala-programmeurs.
Ik vind het zelf
ja, vele malen fijner in Scala.
En ja, Java is natuurlijk
wel heel erg gegroeid over de tijd en heel erg verbeterd.
Het gaat ook steeds sneller nu met die
nieuwe versies en zo. Maar ja, voor mij zelf
persoonlijk is Scala nog steeds favoriet.
Ja, voor je favoriete taal.
Ja, nee, dat maakt niet uit. Het is voor mij, ik kijk van buiten
zeg maar. Ik weet je, ik ben net ontwikkeld.
Dus dat is echt precies het andere kant zeg maar.
Maar dan hoor ik, ik hoorde wel heel vaak mensen
over Scala spreken en heel positief zeggen oké,
als ik in Scala doe, dan wil ik eigenlijk niet meer terug naar Java.
Dat hoor ik wel vaker, dat sentiment.
Nou, het is ook zo dat ik op een bepaald moment
deed tot Java en toen ben ik in zekere zin geforceerd
hem tot net te gaan doen. Dat maakte hem trouwens niet uit.
Ik vind het gewoon allerlei tools die je gebruikt.
Zo simpel is het.
Maar toen kwam ik in C Sharp
en dat was toen net framework 2.5
en dan 3.5.
Dus ze hadden een 2 codebase
en toen zijn we naar 3.5 gegaan.
En daar zag ik al heel veel voordelen van dingen als link
en andere functional programming style
kwam daar steeds meer naar voren.
En first class functions en dat soort dingen.
Dus dat vond ik eigenlijk wel heel erg gaaf.
Toen kwam ik op een ander project van
we moeten het in Java doen, oké.
En toen, oh man, dit is toch wel even weer een stap terug.
Op dat moment.
Toen ik daarna Akra zag staan met een voorbeeld uit de scale
dacht ik, wow, dit is precies wat ik wil.
Dit is eigenlijk nog beter dan C Sharp
in die functional programming zin.
En wat het allemaal bood.
Dus een soort van
een style waar je
veel minder hoeft te typen. Een concise
af en toe ben ik Nederlands een beetje kwijt, maar
een beknopte taal.
En ja, een hele goede
support voor collections en dat soort dingen
en voor alle dingen die je normaal gesproken tegenkomt.
Er is iets, er is niets, de option
types en
alle andere dingen die je zo tegenkomt.
Dus ja, Scala is
wel steeds een favoriet.
Wat ik ook wel zorg voor mensen is, ja, dit is gewoon veel te moeilijk voor mij.
En het komt
ook omdat er zijn mensen ook bezig met Scala
om die lat nog verder te leggen.
Dus die doen research en die gaan hele
complexe dingen proberen
die voor iedereen, niet voor de meeste mensen
te ver gaan of onnodig zijn, maar
in Scala zelf zit ook een hele
functionele, en dan bedoel ik niet
functional programming, maar een hele functionele core van
simpele dingen die heel goed werken. Dus je hoeft niet al die hele
moeilijke dingen te gebruiken, maar daar worden mensen wel door afgeslikt.
Dus dat wordt nu een beetje in de
nieuwe versie, moet het getracht om het een beetje
simpeler te maken voor iedereen.
Want ja, wie wil nou iets zo complex?
Ik zat laatst nog een artikel
te lezen over Scala en
het vinden van goede developers
in Scala. Wat is jouw blik
daarbij? Wat vind je daarvan?
Heb je daar zelf ook een beetje ervaring mee, dat je
echt denkt van nou, er zijn toch echt wel schaarse
Scala developers out there?
Ja, dat is een beetje een gek verhaal, want
toen ik dat project begon, voor het eerst met
Scala, toen waren er geen Scala mensen.
En toen heb ik gewoon een aantal collega's gevraagd, wie wilde graag
eens nieuws doen? Nou, er waren er genoeg.
En toen ik mensen
mee ging interviewen, een ervan was
de jongen waar ik samen in het boek mee geschreven heb,
Rob Bakker. Die was ook geen Scala programmer,
maar dat was een hele ervaring Java-programmeur.
En die zag het ook wel zitten om wat nieuws te gaan doen.
En toen waren we als team, denk ik met een man of vier,
initial, we waren binnen
nou, misschien twee weken of zo waren we
gewoon, twee weken misschien,
waren we zeker gewoon goed bezig, zeg maar.
Dus ik denk niet dat je
per se iemand moet hebben die al
jarenlang Scala doet of zo. Het is natuurlijk wel leuk, maar
ik denk niet dat het heel ver weg is
voor mensen om daarmee te beginnen. Alleen je moet wel
naar die kleinere set, naar die simpele set
van dingen kijken.
Dus als je meteen gaat naar...
Er zijn veel mensen die in de Scala wereld die
veel meer geïnteresseerd zijn in de pure functional
programming kant. En de pure functional programming
kant in de zin van Haskell.
Dus dan krijg je heel veel
abstracte modellen, et cetera.
En dat is gewoon niet voor iedereen,
simpel gezegd. Dus als je dat soort mensen
wil vinden, dan moet je of een Haskell persoon vinden,
of iemand vinden die echt die hele
manier van Scala in pure functional programming
echt ziet zitten en ook goed begrijpt.
Daar zijn zeker voor- en nadelen aan, maar...
Ik denk dat goede programmeurs sowieso
lastig te vinden zijn, die echt goed zijn.
Maar tegelijkertijd denk ik ook dat
een goede programmeur niet alleen maar door technische skill
wordt bepaald, zeg maar.
Ik heb ook weleens met mensen gewerkt die
technisch heel goed waren, maar daar kwam
toch eigenlijk niks uit, op wat voor manier dan ook.
Dus ja, het is wel zo, als je puur
kijkt naar, ik wil een Scala-programmeur hebben
met vijf ervaring, of zoiets, dan wordt
dat een lastige uitdaging inderdaad. Dat is
wel zo, als je zegt, dat is mijn maatstaf.
Als je zegt, ik wil gewoon een goede programmeur hebben.
En iemand die graag Scala wil leren,
dan is het weer heel anders, want wij hebben
ook iemand in ons team, al heel lang,
en die had wel wat Scala gespeeld,
maar die was gewoon 20 jaar C++ programmer.
Dat kan helemaal goed. Maar ja, er zit ook wel
een risico aan als je alleen maar blijft bij wat je al kent.
Want juist in deze business moet je blijven
leren. Ik bedoel, ik heb nu denk ik
zo'n 3 jaar met Kubernetes gewerkt.
Ja, dat moet je toch allemaal gewoon oppakken.
Dan kan het niet zeggen, dat wil ik alleen maar in Scala doen.
Dat kan helemaal niet. Dus je moet ook
wat HelmCharts en wat Golang
en allerlei verschillende dingen komen langs.
Bash Scripts, maakt niet uit, Makefiles.
Je hebt gewoon heel veel verschillende dingen nodig
om echt iets werkend te krijgen.
Ik kijk altijd naar mensen van, kan jij iets werkend
krijgen? Kan je iets voor elkaar maken? Dat is eigenlijk het belangrijkste.
Ja, zeker, zeker.
Ja, nee, maar ik begon even over dit onderwerp
omdat, ja, we zijn toch ook wel
het is best wel schaars om Scala developers
en misschien ook wel de goede, hoe je ze ook
wil noemen, zeg maar, om die te vinden.
Dus ik was even nieuwsgierig naar hoe
bijvoorbeeld Lightband daarna kijkt.
Ja, dus wat ik aan jou hoor
is dat het voornamelijk gaat om
dat je waarschijnlijk ook gewoon
goed in concepten denken bent
en dat je inderdaad wil blijven leren, nieuwe dingen
blijven proberen.
Wij nemen niet alleen maar mensen aan die alleen maar
Scala programmeren, dat is sowieso niet.
Maar we hebben natuurlijk wel een voordeel
als we mensen willen aannemen die Scala programmeren.
We zijn nogal een focal point,
zeg maar, voor Scala programmers. Dus het is voor ons
veel makkelijker om een Scala programmer binnen te krijgen dan
een bedrijfje ergens in Nederland die wat
Scala programmers doet.
Ik wilde kort nog even over jouw boek hebben.
Misschien ook wel leuk om even daarbij
te staan.
Dat was weer een tijdje geleden.
Wanneer is je boek uitgekomen?
En kan je er iets meer over vertellen?
Ik krijg het gewoon.
Ik weet het niet meer.
Het is al wel, even kijken,
in ieder geval 5, 4 jaar geleden.
Het heeft me ook heel lang geduurd.
Ze zeggen ook altijd tegen je van
als je denkt dat je een boek gaat schrijven, doe het niet.
Je kan nog meer geld verdienen
als je zavond bij de Burger King gaat werken.
Voor sommige boeken natuurlijk niet waar.
Maar voor de meeste IT-boeken
je wordt er niet schatterijk van.
Dat is ook niet de reden waarom je het doet.
Maar het is zeker een hard werk.
Dat heb ik ook wel het onderschatten.
Gelukkig had ik iemand
die het samen met mij wilde doen.
Dat was Rob Bakker.
Een van de eerste projecten die we samen deden.
Menning was aan het zoek
naar iemand om het akka-boek te schrijven.
Die hebben natuurlijk het akka-team zelf gevraagd.
Hebben jullie interesse?
Ja, die hadden we niet heel de tijd.
Ik was ondertussen alweel bezig als contributor
op het akka-project.
En uiteindelijk zijn ze dan bij mij terechtgekomen.
Dus ik weet niet hoeveel mensen er mee hebben gezegd.
Om het zo maar even te zeggen voordat ze bij mij kwamen.
Toen dacht ik al van dit is zoveel werk.
Maar tegelijkertijd ook wel heel erg leuk om te doen.
Een mooi doel om te hebben weet je wel.
Ik had een boekopje in je kast met je eigen naam erop.
Dat sprak me wel aan.
Maar ik wist al wel van dat gaat me nooit lukken in mijn eentje.
Dus toen heb ik aan Rob gevraagd of ik mee zou doen.
En zo is het eigenlijk begonnen.
En later heeft een andere jongen uit Amerika
meegeholpt met de tekst, Rob Williams.
Maar wij zijn toen met z'n tweeën daarmee begonnen met het boek.
En hoe lang heb je er ongeveer over gedaan?
Weet je dat?
Ja, dat weet ik nog. Dat is ongeveer vier jaar geweest.
Kijk, eigenlijk wil zo'n publisher
dat je ongeveer binnen zes maanden klaar bent.
Wat er gebeurde was...
Ik had er nooit een boek geschreven, Rob ook niet.
Dus je krijgt dan eerst een development editor.
Die gaat je uitleggen, zo moet je een boek schrijven.
Of dit zijn onze manieren van hoe je een boek schrijft.
En het is daar ook heel lang bezig geweest met het eerste hoofdstuk.
Waarom zou je nou Akka moeten hebben?
En dat is niet een heel eenvoudig verhaal
om het heel goed uit te leggen op dat moment.
En Akka veranderde heel erg veel over de tijd.
Die was nog erg in ontwikkeling.
Dus we hebben ook hoofdstukken geschreven
die nooit in het boek terecht zijn gekomen.
Want die zijn in een latere versie van Akka
verwijderd of vervangen door iets beters.
En ook weet ik nog dat we waren op een bepaald moment klaar.
En toen kwam net een heel belangrijk ding uit.
Akka Streams.
En ja, nee, dat moet toch in, hè, de boek?
Ja, hoe gaan we dat doen? Want dat hadden we zo niet mee gewerkt.
Dus toen was het ook van, oké, dan moet ik eerst leren hoe het werkt.
Precies weten hoe het werkt. En dan kan ik er een hoofdstuk over schrijven.
Dat kan je wel merken in het boek dat we daar wat minder kaas van hebben gegeten.
Het blijft redelijk op een beginners niveau.
Maar dat soort dingen maakten het heel moeilijk.
En als je dan niet...
Je moet zo'n 16 uur per week aan je boek werken.
Als je het redelijk op tijd wilt doen.
En dat was best wel veel.
Dat is zeg maar heel weekend, elke week.
Elke week ben je je weekend kwijt.
Of je moet heel gedisciplineerd elke dag en twee uurtjes werken eraan.
En op een bepaald moment wordt dat gewoon te veel.
En dan stop je die weer even mee.
En dan heb je weer later een plek.
Dus als het je heel goed ligt, is dat misschien makkelijker.
Ik vond het wel altijd heel leuk om dingen uit te leggen.
En om ook presentaties erover te geven.
Mensen in teams dingen uit te leggen.
En daar heb ik zeker wel veel van geleerd.
Dus dat zou ik wel aanraden.
De ervaring heeft zeker wel grote voordelen.
En ook, ik denk, een van de belangrijkste skills die je moet hebben als een goede programma is schrijven.
Dus schrijven van tekst.
Niet zozeer schrijven van code.
Schrijven en communicatie zijn enorm belangrijk.
En ondergewaardeerd.
Iedereen denkt alleen maar van, hoe kan je deze bubbelsoort, weet je wel.
Wat kan je deze, schrijven zijn van een paxos ofzo.
Maar daar gaat het eigenlijk niet om.
Naar mijn mening hoor.
Het gaat voornamelijk veel meer over hoe je communiceren met je team.
Hoe zorg je ervoor dat je je gebleem op kost en dat soort dingen.
En schrijven heeft daar ook mee te maken.
Je moet je designs delen met mensen.
Je moet van alles schrijven.
Dus ik dacht, nou ja, daar heb ik wel een voordeel aan.
Ik heb ook een keer ergens iets over gelezen.
Van dat het moment als je het gaat uitleggen aan een ander.
Dan pas ga je echt leren wat je geleerd hebt.
Je bent gewoon constant in practice mode.
Dus als je iets aan het bouwen bent of wat dan ook.
Het zou best zelfs wel kunnen zijn dat het je linker oor ingaat.
En dan doe je je ding en in je rechter oor gaat het eruit.
Ben je het al even vergeten?
Maar het moment als je dan echt een training of een boek gaat schrijven.
Dat is denk ik wel het moment dat je een reflectie doet over wat je echt weet.
Ja, want wat mij betreft, vooral in dit vak.
Misschien wel met bijna alles, maar vooral in dit vak.
Weet je eigenlijk niet hoe het in elkaar zit.
Dus je hebt een soort van mentaal model.
Van hoe het werkt.
En dat mentale model hoeft helemaal niet te kloppen.
Het hoeft alleen maar te kloppen zoveel als jij kan zien.
Dus als jij met Akka werkt en je werkt een paar weken ermee en alles gaat goed.
Dan denk jij misschien wel dat het op een bepaalde manier werkt.
Maar het hoeft helemaal niet erg te zijn dat het verkeerd is hoe je erover denkt.
Totdat je het opschrijft, want als je dan gaat uitleggen.
Ja, mijn mentaal model zit zo in elkaar en dat het moet kloppen.
Dan ga je jezelf vragen, wacht even, zit het eigenlijk wel zo?
Hoe zit het eigenlijk precies?
Dat is wel interessant aan het uitleggen aan een ander.
Je hebt gewoon wat meer diepgauw nodig dan wanneer je het zomaar gebruikt.
Dat vind ik wel heel erg interessant van dit werk.
Dat je in zekere zin helemaal niet door alle lagen heen kan overzien wat er precies gebeurt.
Maar dat iedereen voor zichzelf een mentaal model maakt.
En daarmee uit de voeten kan.
Dat we dan toch nog dingen kunnen bereiken.
Dat vind ik wel een heel interessant idee.
Dat je op de schouders van de shoulders of giants, weet je wel.
Dat je daar bovenop staat.
Dat is wel heel gaaf.
Ja, gaaf joh.
En het schrijven van het boek zelf.
Hoe is je dat bevallen?
Kan je daar iets meer over vertellen?
Initieel was het wel leuk.
En aan het einde dacht ik, wanneer houdt dit op?
Het is echt, nou ja, je gaat op een bepaalde moment.
Wat ik heel lastig vond, was goede voorbeelden bedenken.
Want voorbeelden moeten ten eerste niet te groot zijn.
Als ik een heel echt systeem ga uitleggen aan je.
Dan ben je een paar met de draad kwijt.
Dan leer je meer over het echte systeem dan over bijvoorbeeld akken.
En als er te weinig vlees aan de botten zit, zeg maar.
Dan denk je van, ja, dit is een hele world-ding.
Hoe ga ik dat dan gebruiken in mijn project?
Dus je brengt op een bepaald moment een bepaald voorbeeld.
En dan kan je er ook niet meer echt van af.
Je hebt er allerlei dingen omheen geschreven.
En op een bepaald moment ga je het voorbeeld steeds minder leuk vinden.
Dus totdat je denkt van, oh, man, waarom heb ik nou dit voorbeeld gekozen?
Dus het is best wel...
Ja, er waren wel leuke dingen aan.
Maar ja, tegelijkertijd de werkdruk die je dan gewoon in je normale dagelijkse werk hebt.
En dan dit nog erbovenop.
En dan je wilt nog een leven hebben, et cetera.
Dus dat is best wel tricky.
Ik zou het als waarschuwing geven aan mensen die...
Als je lekker veel tijd over hebt, moet je het doen.
Maar het is...
Het is wat wel heel leuk was.
Je gaat weer met die publisher, de mensen die helpen je daarbij.
En die geven je allerlei tips.
En dat is allemaal heel erg leerzaam.
En dat je het dan ook samen doet.
En dat je dan uiteindelijk het voor elkaar krijgt.
Dat zijn allemaal hele leuke momenten.
En dat je dan voor het eerst je boek binnenkrijgt op papier.
Dat is echt heel gaaf.
Ik heb later ook...
Ze hebben het boek ook in het Japans en in het Koreaans uitgegeven.
En daar heb ik ook copies van gekregen.
Ik kan het niet lezen natuurlijk, maar het ziet er wel heel gaaf uit, weet je wel.
En blijkbaar vinden ze het ook een goed boek in Japan.
Een oud collega van ons, die woont nu in Japan.
En die heeft contact gehad met de mensen die daar wat hebben geschreven.
Of zeg maar de Japanse versie van hebben geschreven.
Dat zijn allemaal hele leuke dingen.
Dat je het voor elkaar hebt gekregen om het boek af te maken.
Maar het was zeker bloedswetende traan, laat ik het zo zeggen.
Net nadat we beide bij Xebia zijn weggegaan, heb ik je een beetje gevolgd via LinkedIn, geloof ik.
Ik merkte wel dat je hier en daar in het buitenland bent gaan hoppen.
Je hebt toch wel wat landen mogen werken, of heb ik dat verkeerd gezien?
Ja, dat klopt.
Ja, zoals ik al zei, ik heb in Zuid-Afrika gewoond.
Maar ja, mijn vraag komt daar vandaan.
En op een bepaald moment een lange afstandsrelatie.
Dat moet op een bepaald moment een korte afstandsrelatie worden, anders wordt het niks natuurlijk.
En dus daar.
Maar ook op een bepaald moment een leuke opdracht.
Als Scala freelancer in City bij Commonwealth Bank gekregen.
En ik werd gewoon door iemand benaderd.
Van, ja, gewoon, wil je dat doen?
En ja, is goed, zeg ik.
Maar dan moet je wel alles regelen.
En ja, is goed.
Oh, wacht even.
Dit wordt interessant.
Dus ja, zo ging het.
En de eerste drie maanden ben ik dan met familie, zeg maar, daarin gegaan.
Dat was echt heel gaaf.
We hadden midden in de stad daar.
En dan ging ik, daarna ging ik elke, wat was het?
Elke drie maanden ging ik drie weken naar Sydney.
En dat heb ik zo'n tweeënhalf jaar gedaan, denk ik.
Ja, tweeënhalf jaar gedaan.
Maar het maakt niet uit waar ik was, zeg maar.
We hebben ook twee keer een half jaar in Sarasaka weer gewoond.
En dan kwam mijn vrouw weer bij haar ouders en zo contact.
En ook onze dochter kon dan met grote ouders en zo contact houden.
Dus het was ideaal op dat moment.
Rockstar.
Geluk, hou geluk.
Nou, het lijkt me wel leuk om de Developer Dilemma's nog eens een keer te gaan doen.
Ik weet niet wat het is.
Het is een beetje gejat van developerdilemma's.org, geloof ik uit mijn hoofd.
Dat is een website, ja.
En daar, ja, eigenlijk is het gewoon heel simpel.
Er wordt een kaart getrokken en pick one.
Dus er zijn twee stellingen op die kaart.
En dan moet je iets kiezen.
En ja, kijk, het is natuurlijk leuk om jou gewoon helemaal te verrassen.
En dan jou in die zin te betrappen.
Dus ik dacht, laten we het gewoon even vier keer even doen.
En dan leren we je gewoon op die manier kennen.
Dus ja, let's go.
De eerste.
A monolith of microservices?
Je moet eentje kiezen.
Microservices.
Oké, waarom?
Als je moet kiezen, ja.
Ja, ik verwacht dat we het hebben over een groot systeem.
Want anders dan heb je het niet over het een of het ander.
Dan heb je het over een klein dingetje.
En microservices zijn wel een manier om...
Het gaat eigenlijk weer terug naar die communicatie wat je eerder over hadde.
Als jij aan één systeem met heel veel mensen moet werken,
dan krijg je steeds meer communicatie over het.
Dus een grote systeem opsplitsen in bekende interfaces,
in een duidelijke verantwoordelijkheid per onderdeel,
is een goede manier om een grote problemen op te splitsen in kleine problemen.
En in die zin zie ik dat een microservice daarin een goed idee is.
Ook omdat je daarin als team of als subteam
verantwoordelijkheid kan nemen voor een kleine onderdeel van het probleem.
Waar je ook redelijk vrij in bent in het aanpassen en het veranderen van de software.
Bij de monolith zit je meteen weer vast aan,
we moeten alles samen deployen, maar ook samen version control, samen alles.
Dus bij de microservices moet je wel wat meer qua design doen,
en wat meer nadenken over die juiste kaders, die juiste constraints.
Maar bij grotere systemen zie ik daar wel een voordeel in.
Natuurlijk hebben microservices ook een nadeel, de chaos die er kan ontstaan,
maar er zijn ook wel weer methodes en technieken voor waar je ervoor kan zorgen
dat het minder een gevaar wordt voor standaard protocolen kiezen,
voor standaard dingen als Kafka of message buses kiezen.
Dus ja, ik ben er wel uit.
Dus we zouden je niet gelukkig maken als een project voor je uit kiezen waar monolith wordt gekozen?
Nee, dat maakt het project niet uit.
Kijk, je moet het probleem oplossen en je moet gewoon,
wat je ook moet doen, je moet het voor elkaar krijgen.
En ook een monolith kan je mooi doen.
Ik bedoel, al die jaren voordat mensen microservices benoemden,
hebben we ook genoeg gemaakt.
Het is niet een, hoe zeg je dat, een zilver bullet.
Nou, hartstikke goed. Fijn, dankjewel.
Het is goed om ook weer jouw kant van het verhaal te horen.
Nou, we gaan nu door naar de volgende.
Hang on, monorepo of multiple repos?
Oeh, ja, vanwege de microservices kan ik zeggen multiple repo,
misschien, af en toe als je verschillende teams hebt.
Maar ik vind dat wel een lastige,
want ik heb allebei gedaan in vorige projecten
en ook geswitcht van de een naar de ander.
Zowel van de een af naar de ander.
Een monorepo heeft natuurlijk duidelijke voordelen in
dat je niet elke keer hoeft te releasen, et cetera, van je sub-onderdelen.
Dus dat geeft wel een beetje de voorkeur.
Alleen, dat kan dus niet in elke situatie.
Bijvoorbeeld in dat microservices systeem dat we net overhadden,
is dat duidelijk een voordeel,
omdat als je hele duidelijke kaders hebt,
hele duidelijke afscheiding hebt in systemen,
dan kan dat wel zin hebben.
Maar ja, goed, er zijn natuurlijk ook genoeg bedrijven
die hun hele bedrijf in een monorepo doen.
Dus ik heb wel het idee dat dat redelijk zwaar wordt
in Gitflow of iets anders,
om het allemaal een beetje in kaartjes te houden.
Ja, volgens mij hadden we ook een keer een aflevering,
toen hadden we het over dat sommige repos echt zo groot werden
dat men echt met USB-sticks en zo met elkaar moesten gaan delen.
Weet je nog?
Zo, ja, echt.
In ieder geval via USB had je alles binnen kunnen trekken.
Maar ja, dan moest je dan ook weer...
Ja, het is echt bizar af en toe, maar goed.
Het blijft lastig, he?
Deze is inderdaad een it depends.
Dat gevoel krijg je ook een keer weer.
Ja, ik heb ook eerder wel eens...
We hadden allerlei losse repos,
maar na een tijdje krijg je een verschrijdend inzicht.
Ik kwam erachter van, dit heeft eigenlijk allemaal met elkaar te maken.
Nou, dan zijn die allemaal weer naar één repo gegaan.
Dus ik denk dat dat ook iets heel natuurders kan zijn
om die vraag telkens te blijven stellen.
Niet per se te zeggen het is het een of het ander,
maar op basis van context te bekijken.
Ja, het is wat mij betekent ook vergelijkbaar met best practices.
Best practices die volgen je als je het nog niet helemaal weet.
En nadat je dat al heel lang gedaan hebt,
kom je er misschien achter van,
wacht even, dit is helemaal niet het ideale ding in onze context.
Dus ja, niet vast komen zitten is een heel belangrijk ding om voor te waken.
Zeker?
Zeker.
Oké.
Nou, gaan we door naar de derde.
Assembly of COBOL.
Wow.
Ik moet kiezen.
Man.
COBOL.
Ja, ja, COBOL.
Van wat ik moet doen elke dag?
Ja, COBOL.
Nee, als ik gewoon iets,
als ik een perl interface ofzo moet schrijven
of iets voor een, voor een of andere chipje ofzo,
dan Assembler.
Maar als iemand zegt van,
maak even een website in Assembler,
no ways.
Nee, dat kan niet.
Gewoon te veel werk.
Als je zegt,
als je zegt welke vind je leuker,
dan is Assembler veel leuker.
Je kan daar hele leuke dingen mee doen.
Er zijn allerlei trucjes die je kan vinden.
Oké, nou dan gaan we naar de laatste.
Clean code of good documentation?
Clean code.
Ja, clean code.
Ja, clean code heeft geen documentatie nodig dan.
Ah, oké.
Dat is een open deur deze.
Ja, wat voor een documentatie, right?
Documentatie op code is,
in een uitzonderlijke situatie,
noodzakelijk.
Als je iets heel complex doet,
dan zou je dat kunnen doen.
Ik moet zeggen dat ik tegenwoordig steeds minder
documenteer op code.
We hebben er nog geen nadeel van gehad,
maar het kan soms zijn dat de opdrachtgevers
die dat niet verijzen.
Of je schrijft een API,
dan moet je heel veel documentatie hebben
voor de API,
maar niet voor de private parts.
En clean code,
dat moet je sowieso doen,
in de zin van,
ja, code wordt vaak weer gelezen,
dan geschreven, et cetera.
Maar ik ga er ook niet te ver in.
Dus je kan ook te veel polijsten.
Je kan te veel daarmee bezig zijn
en niet je deadline halen, bijvoorbeeld.
Dus technical debt is oké,
zolang als je maar het wel in de gaten hebt.
Je kan niet te gek gaan,
maar alleen maar puur focussen op clean, clean, clean.
Ja, daar kom je ook weer nergens mee, zeg maar.
Je moet vooral doelgericht bezig zijn.
Dat waren ze.
Ja, joh.
Wat vond je ervan?
Ben je aan het zweten geweest, Remo?
Nee, ik vind het wel leuk.
Ik vind het sowieso wel leuk om daar
code in het algemeen te praten
en wat er toe duwt.
Daar ben ik wel al veel mee bezig ook.
Hoe ga je met je team echt het verschil maken?
Dat is toch altijd maar de vraag.
Zeker.
Dat is een mooi bruggetje ook.
Meestal doen we in elke aflevering,
proberen we in ieder geval even
een beetje te kijken van goh,
wat is er de afgelopen tijd op Twitter gebeurd?
Ik zag wel een linkje naar een Twitter feed
van een der Obasanjo.
Obasanjo, ja.
Carnage for Life heeft hij als Twitter.
Ja, dat is echt...
Opinions about product management,
technology news,
inclusivity in tech.
Diversity is about demographics.
Inclusion is about creating a sense of belonging.
Nou, hele wijze woorden.
Maar wat hij zei,
dat was trouwens 1 oktober afgelopen jaar.
Dat is een beetje lang geleden, maar goed.
The longer I'm in tech,
the more I'm convinced
that microservices were a technical solution
to our organisational problem.
Ja, dat klopt wel, ja.
Ik bedoel...
Ja, ik denk dat het wel...
Er zit wel een waarheid in in ieder geval.
Ik denk dat jullie ook al bij wel gehoord hebben
van Conway's Law.
Of van Conway's...
Conway's...
Dat het...
Dat het organisatie zich afspiegelt naar...
Of nee, dat...
Het gedrag zich afspiegelt naar de organisatie.
Of het draait nu misschien even een beetje verkeerd om, maar...
De hele reden voor verschillende teams
die werken aan iets
en die organisatorische reden daarvoor
die zorgt vaak voor de microservices.
Het feit dat bepaalde mensen in een bepaalde afdeling zitten,
andere mensen in een andere afdeling, die gaan allemaal wat maken,
maar ze kunnen niet per se samenwerken, want ze zitten in andere afdelingen.
Dat zorgt in zekere zin voor
het moeten maken van afzonderlijke afdelen van software
en die weer aan elkaar knopen.
Ik weet niet hoe jullie zijn, maar ik werk het liefst met een team
van ongeveer 5, 6 man.
Weet je wel, als het groter wordt, dan wordt het allemaal weer heel moeilijk
met communicatie en met wie gaat wat doen.
Dus dat probleem van
hoe organiseer je jezelf om grotere dingen te maken,
dat kan je wel afspiegelt zien in die microservices manier van weten.
Dat denk ik wel, ja.
Nou goed, Ray, ben je een nieuw boek aan het schrijven?
No way!
Eén keer en nooit meer.
Dat kost me gewoon te veel energie.
Het was wel leuk, maar ik heb er echt geen tijd meer voor.
Ik heb ook een paar mensen in Twitter ook wel aan me gevraagd
van wil je niet de tweede editie doen,
maar ik heb nu gelukkig een collega van mij gevonden
die het waarschijnlijk afgaat maken.
Je hebt mensen die elke paar maanden een boek doen.
Die hebben het helemaal gevonden.
Maar voor mij was het te veel werk om naast mijn werk te doen.
Dat is al veel eisend genoeg.
Ik moet mijn familie ook nog een foto zien.
Maar het was wel heel leuk om het af te maken.
Omdat we de checkboxen zetten.
We naderen eigenlijk al bijna aan het einde.
Maar voordat we dat gaan doen,
leek me leuk om even stil te staan bij wat tips en tricks.
Ray, heb jij misschien een paar leuke tips en tricks voor ons?
Ik zit ook te denken van, wat zou een tip zijn?
Ik probeer het een beetje on the spot te bedenken.
Maar wat zou nou een tip zijn?
Er zijn genoeg dingen op de lightband site die interessant zijn.
We zijn nu ook met AK Serverless bezig.
Dat is een nieuw product.
Dat is helemaal gebaseerd op stateful functions.
Maar ook event sourcing en dat soort dingen meer.
Dus dat is zeker interessant.
Dat is een beetje de nieuwe manier waarop we AK aan het publiek willen loosstellen.
Dus dan halen we een heleboel dingen.
Wat ik eerder al zei, die AK toolkit is een hele mooie toolkit.
Maar wat moet je allemaal gebruiken? Dat wordt heel lastig.
En eigenlijk willen mensen gebruik maken van de voordelen van AK.
Want heel veel grote bedrijven maken gebruik van die enorme schalen.
Zoals Apple, PayPal, doe ze maar op.
Allerlei grote bedrijven die er gebruik van maken.
Dus iedereen wil die voordelen.
Maar niet per se de hele diepe kennis van al die systemen.
Want die grote bedrijven stoppen daar veel meer tijd in.
En AK Serverless is een model waarin je ook in andere talen dan Java en Scala gebruik kan maken.
In zekere zin van AK.
Dus intern draait er een AK Cluster met persistence en alles.
Maar in AK Serverless kan je gewoon...
Eigenlijk JavaScript, Golang, allerlei andere talen kan je ook gebruiken.
Dus dat is misschien heel interessant om in te kijken.
Dat zou dan wel een tip zijn.
Ik zat toevallig vandaag op Twitter te kijken.
En ik zag iemand posten over GitHub.
Dat je ook Visual Studio Code in je browser kan openen.
Dus dan moet je...
Eén, ga naar elke repo op GitHub.
Twee, vervang GitHub in de URL met GitHub 1S.
Dus je voegt 1S toe.
En dan voila, heb je Visual Studio Code.
Ik ga het even proberen.
Dus dan heb je GitHub 1S.
Ja, nummer 1.
Dit is cool.
Ik zal ook straks de link even delen naar die tweet.
Er is ook iemand die dan gereageerd had daarop.
En het schijnt dus dat GitHub ook zijn eigen Codespaces maakt.
Sorry, ik bedoel het heet Codespaces.
Dat is dus ook zo'n instant dev-environment in je browser.
Dus ze zijn ook bezig om een cloud-editor.
Wauw, dit is wel heel nice.
Ja, ze zijn lekker bezig, zie ik.
En mijn laatste tipje, maar goed dat is meer persoonlijk misschien.
Ik wil ook inderdaad wat meer in rust gaan duiken.
Ik vind echt de documentatie van rust, die vind ik echt supergoed.
Want dat legt je echt in hele simpele stappen uit.
Dat doe je in kleine stapjes.
Ja, dan moet je maar eens een keer gaan naar docs.rust.
Ja, het is echt geweldig hoe ze dat doen.
Ze nemen je in baby-stappen naar Hello World.
En dan van Hello World weer naar het model dat rust omarmt.
Het is echt heel nice.
Daar wil ik ook meer mee gaan doen met rust inderdaad.
Heel interessant.
Mensen worden er rustig van.
Zo, beste mensen, dat was hem weer.
Ja, we gaan nu echt richting de afronding van onze podcast.
Allereerst wil ik Raymond weer bedanken.
Thanks man voor je deelname aan deze podcast.
Alsjeblieft.
We vonden het volgens mij allemaal hartstikke leerzaam.
Ik denk dat we ook nu elkaar beter begrijpen in de software development landscape.
Dus ja, super thanks daarvoor.
Ja.
Voor degene die nu zitten te luisteren.
Je kunt je abonneren op onze CodeKlets podcast.
In je favoriete podcast player.
Zoek daar gewoon op CodeKlets en voeg ons toe aan je favoriete.
Wil je ons spreken?
Of in ieder geval chatten?
Babbel dan met ons mee op Slack.
We hebben verschillende Slack kanalen.
Ga naar codeklets.nl om de link naar Slack te vinden.
We hebben ook een Twitter en een Instagram account.
Beiden zijn gewoon CodeKlets met een adje ervoor.
Retweets en likes zijn altijd lief.
Ik zal trouwens ook even de show notes en de linkjes naar de verschillende verdiepingen van deze podcast plaatsen.
En ja, dat resteert mij alleen nogmaals bedanken voor het luisteren.
En tot de volgende keer dan weer.
Mazzo!