Observability met Vincent Lussenburg en Jeroen Zeegers

Als je gaat starten met observability in de applicatie lifecycle, hebben jullie gemene delen daarin of is het echt heel specifiek op het domein waar je applicaties in gaat bouwen? Ik denk dat het heel domeinspecifiek is. Er zijn keekpunten. Eigenlijk het eerste dat in mijn hoofd te binnen schoot was error rate en dingen als bijvoorbeeld de response time aan de hand van je traces. Maar ik kan me ook voorstellen dat er omgevingen zijn waarin een bepaalde mate van betrouwbaarheid belangrijker is dan snelheid. Het is heel moeilijk te zeggen. Het belangrijkste is om gewoon het gesprek aan te gaan met je stakeholders en samen tot een set aan metrieken te komen. Die werkt voor jullie en die het geluk van je klant mee kunnen maken. Ja, precies. Observability voor pacemakers is heel anders dan observability voor jewels op je iPhone, zeg maar. Ja precies, het jewels op je iPhone, ja. Alhoewel zou dat een relatie kunnen zijn als je slecht... Nou, welkom allemaal weer bij een nieuwe aflevering van CodeKlets. Ja, vandaag ben ik in mijn eentje. Ja, dat is best wel jammer in die zin. We hadden echt wel zin om samen met Saber een leuke aflevering weer op te nemen. Maar helaas, ja, hij gaf me net zo net door dat hij, ja, hij werd wakker met gesloten ogen. En dan ga je je natuurlijk heel erg druk maken nu en dan denk je van jeetje, wat is er aan de hand? Maar ja, het is een beetje vaag, maar ja, hij heeft dus ieder geval wat last van zijn ogen, waardoor hij dus, ja, wat minder lekker, noem het maar even, in zijn vel zit. Dus heeft hij toch besloten om niet aanwezig te zijn. En uiteraard laten we wel weten hoe het met hem is, maar ik heb wel begrepen van hem dat het niet super ernstig is of zo en dat het wel oké komt, wordt. In deze aflevering van CodeKlets gaan we het hebben over observability. Ja, dat is een onderwerp waar onze gasten, want daar hebben we er twee van, veel mee te maken hebben in hun werkveld. En ja, ik ben zelf ook persoonlijk heel erg nieuwsgierig wat observability nou precies inhoudt en wat je er al mee kan en vooral hoe je, ja, software development lifecycle misschien wel mee kan gaan verbeteren. En ja, ik ben wel blij om deze twee gasten hier aan boord te hebben. Een van onze gasten vandaag is Vincent Lussenburg. Die werkt bij Backtrace IO, dat is een bedrijf van Solslabs. En hij is helemaal live uit San Francisco vandaag, de US. Eigenlijk Denver vandaag, maar dat is net wat dichterbij. Het is net een acht uur tijdsverschil in plaats van negen. Dus dat schildert voor jullie. Ja, want we doen meestal onze opnames in de avond inderdaad rond een uurtje of acht. Nou ja, heel fijn Vincent dat je er bent, van zo ver afstand. Het staat voor niks. Ja, precies. Ja, de introductie. Ja, ik ken Vincent uit mijn tijd bij Xebia. We hebben zelfs samengewerkt, Vincent, bij de ING bank. Ja, echt lekker aan het hacken geweest met de ING beleggen app, volgens mij. Ja, zeker. Ja, en nu al die jaren verder werk je nu als technical product manager bij Backtrace. En ja, misschien kan je nog even kort vertellen wat je doet. Ik ben wel nieuwsgierig. Ik ben ook wel nieuwsgierig. Wat doe ik eigenlijk zo min mogelijk? Nee, het is best wel veranderd voor mijn afgelopen periode. Wat ik deed hiervoor voor Backtrace is, ik was een sales engineer. Dus dat betekent demos doen van het platform, de proof of concepts begeleiden. Hartstikke leuke functie, vind ik. Maar technical product manager is meer gefocust op de groei van het product. Waar het product, of de producten naar toe zouden moeten gaan. Onderzoek doen naar waar gebruikers op zitten te wachten. Wat nou echt het verschil maakt tussen tien procent extra gebruikers tot het verdubbelen ervan. Dus onderzoek doen. Daar heb ik veel over aan het leren. En als onderdeel daarvan, Backtrace is recentelijk overgenomen door Source Labs. Dat is een acquisitie geweest, half jaar geleden of iets dergelijks. Dus we proberen het ook allemaal in elkaar te klikken, dat alle producten die in de Source Labs portefeuille zitten, met elkaar te maken hebben. Dus dat is een korte samenvat, ik ga vast nog wel vertellen over wat de producten precies zijn in context van observability, maar ik houd even kort nu. Oké, wat cool man. Ja, dat is wel een interessante overname dat Source Labs jullie hebben overgenomen. Voor de luisteraars die Source Labs niet zo kennen, zou je misschien iets over kunnen vertellen? Ja, absoluut. Source Labs is een, het bedrijf is groot geworden in de tijd en Kishen, ik weet dat jij en ik nog wel met Selenium gewerkt hebben in tijden van het ING projecten. Dus Selenium is een open source framework om automatisch met browsers te communiceren, dus net te doen alsof je gebruiker bent, zo kan je automatisch testen doen. En wat Source Labs mee is begonnen, is iets aan te bieden dat jij een browser als een service kan krijgen. Dus als jij wil safari op die versie van Mac of een Android Google browser, op die specifieke versie hebben zij grote farms van en dan kan je gewoon een sessie krijgen en automatische tests uitvoeren of handmatig testen. Wat ze daarna zijn gaan doen, omdat de markt is nu natuurlijk heel erg gestandardiseerd op Chrome. Als het op Chrome werkt, dan soms werkt er wel eens iets niet op safari of Brave of iets dergelijks, maar heel veel gebruikt dezelfde engine, dus die markt is kleiner en kleiner aan het worden. Dus waar het voornaamste werk nu op het moment in zit, is hun Virtual Device Cloud en Real Device Cloud, waar je dus je apps kan testen. Dus op het moment dat jij een ING bank of Apple bank of whatever bent, je wil zeker weten dat jouw app goed werkt op oude Android versies of een specifieke iOS versie, dat de thumbprint het nog doet in plaats van de Face ID, et cetera, et cetera. Dan kan je heel makkelijk zo'n device claimen zoals Device Cloud, zeg maar, en dan krijg je dan een apparaat dat wordt voor je geprovisiond, daar kan je een aantal minuten op testen en dan kan je de sessen weer teruggeven en dan kan je ook heel goed automatiseren. Er zitten meer tools, heel veel zit in het begin van de software delivery lifecycle. Ze hebben de acquisitie van Backtrace gedaan, want Backtrace nog niet zo heel veel over verteld, maar voornamelijk de meeste value brengt in productie. En for sauce is dat iets waar zij nog niet zo sterk in waren, ze zaten veel meer tijdens development en QA. En proberen daarmee een goede feedback signaal te geven van productie terug development in. En dat is de reden dat die acquisitie plaats heeft gevonden. Wauw, ja. Nou, bedankt voor je uitleg. Ja, nee, hartstikke mooi, man. Ja, en ik begrijp het ook waarom ze dan geïnteresseerd zijn in Backtrace, natuurlijk. Maar goed, ik weet net even iets meer, maar dan gaan we straks iets meer over vertellen. Nou, hartstikke goed. Dankjewel, Vincent, voor je introductie. Maar we hebben ook nog een andere gast om over observability wat inhoudelijker te gaan praten. We hebben dit keer Jeroen Zegers uitgenodigd. Die werkt nu op dit moment voor de Nederlandse spoorwegen. En ja, ik ken hem ook. Ik heb daar ook bijna een jaartje ongeveer gewerkt en wij hebben niet zozeer samengewerkt, maar hij werkt in een andere team genaamd Site Reliability Engineering en hij is nu ook een Site Reliability Engineer daar. En ja, misschien vind je het ook wel leuk om even jezelf voor te stellen, Jeroen? Zeker, ja. Mijn naam is Jeroen Zegers. Ik woon helaas niet in San Francisco, maar gewoon in Rotterdam. En ja, een van de dingen die ik super interessant vind, is teams helpen om betere en betrouwbare applicaties te maken. Ik doe dat vooral door ze te coachen op het slimme CI-CD trucjes, maar heel belangrijk, daarbij is ook teams laten zien hoe het echt met hun applicatie gaat en wat de ervaring is die gebruikers daadwerkelijk ondervinden bij het gebruik van die applicatie. Momenteel doe ik dat binnen de NS en dat maakt het extra spannend, omdat eigenlijk is iedereen op een bepaalde manier wel een paar keer per jaar en soms zelfs elke dag klant van de NS. Daardoor hebben de applicaties waar ik mijn druk over mag maken een heel groot publiek. Ja, precies. Dus des te meer misschien is, om toch een beetje een bruggetje te maken na zo'n opname, des te meer is observability misschien wel een noodzaak? Hoe ziet NS dat? Nou ja, dat is zeker waar. Je hebt een organisatie als de NS die is eigenlijk 24 uur per dag bezig. Je wilt het eigenlijk direct zien als er iets niet goed gaat met een van je applicaties. Als die applicaties niet werken kan het betekenen dat treinen niet kunnen rijden of dat kan betekenen dat personeel niet weet waar ze naartoe moeten gaan. Als je goed inzicht kan hebben in wat er onder de applicatie gebeurt, dan kan je dat soort dingen voorzien. Dat is iets waar ik me elke dag voor inzet. He, hartstikke mooi. Wat dat betreft echt twee perfecte kandidaten of gasten uitgenodigd over observability. Dus alvast aan mijn dank aan jullie. En over dank gesproken, ik wil ook even vandaag een speciale shoutout doen naar Wouter Dijks. Dat is een van onze CodeKlets.nl fans. En we spreken qua regelmatig ook op onze CodeKlets Slack workspace. Ja, en die heeft voor ons echt even de tijd genomen om alle vragen op te stellen voor deze aflevering. Dus ja, nogmaals heel erg bedankt Wouter voor je input. Ja, zonder jouw effort was deze aflevering een beetje leeg misschien. Dus ja, in ieder geval heel erg bedankt. En ja, je zal het horen, we zullen je vragen gaan stellen. Even kijken. Ja, we gaan nu even door naar het volgende onderdeel van onze podcast. Gewoon even wat meer jullie leren kennen. Ja, wij vragen altijd onze gasten om iets te vertellen over ja, wanneer het programmeren, zeg maar het coderen begon in je leven. Ja, dus ja, misschien Vincent zou jij daar misschien mee willen beginnen. Zou je eens kunnen vertellen wanneer het begon en hoe en wat en misschien wel waarom? Ja, Commodore 64. Dus dat is nou ja, jaar en een jaar geleden, ik zal denk ik negen of tien geweest zijn. En ik begon origineel met basic programma's over typen, want zo ging dat vroeger. Had je een boek en dan typte je gewoon letterlijk over wat er in het boek stond. En dan deed het programma wat. Ik weet dat ik een programma ingetypt had die in een of ander Beatles nummer 8-bit naspeelde, zeg maar. Toen ik ermee klaar was, realiseerde ik me dat ik het verkeerde hoofdstuk ingetypt had en dat nummer van de Beatles, dat kende ik helemaal niet. Dus dan moet ik de andere 64 pagina's intypen. Dat is langzaam steeds erger geworden in de vorm van ik ben toen, ik ben een Star Trek nerd, dus ik heb mijn eigen Star Trek simulator text based adventure in mekaar getypt. Een aantal van de herinneringen die ik heb is dat ik me kan herinneren dat basic in die tijd moest je altijd een regelnummer ervoor zetten, zeg maar. Dan kon je go to's schrijven, 10 go to 30, zeg maar. En ik kan me herinneren dat je je programma een instructie kon geven als je te weinig regelnummers had, want op een gegeven moment als je te veel go to's gemaakt had en je hebt 11, 12, 13, 14, 15 en weet je wel, dan kan je het programma zelf nieuwe nummers laten toekennen met een soort van 10 ertussen zodat je weer wat ruimte hebt. Ik kan me herinneren dat dat uren duurde voor zo'n simpele operatie als nummertjes toewijzen aan een aan een regelnummer. En weet je nog ongeveer wanneer dat was? 1990 moet het geweest zijn, denk ik. Daarom trend. Ik heb nog vergens toen ik verhuisde naar Amerika ergens een printout gevonden met zo'n matrixprinter van die dingetjes aan de zijkant. Ik heb gedeelte ervan uitgeprint. Supermooi. Ik denk zelfs dat ik nog een floppy disk heb waar het op staat die niemand meer kan lezen. Ik kan me nog een keer een filmpje herinneren van iemand die een YouTube filmpje had gemaakt met zo'n printer die de geluid nog eventjes wilde laten horen. Ik kreeg gelijk kippenvel. Ik kan me zelfs herinneren. Iemand die het Star Wars Imperial Marche nagespeeld had met zo'n printhead. Oh, wacht even. Deze gaat in de show notes, man. Ik ga het even opschuiven. YouTube film Star Trek. Hoe heette die printer ook weer? Imperial Marche van Star Wars in dit geval. En dan welke printers ook weer? Hoe heette die ding ook weer? Matrix printers. Die gaan we even opzoeken. Ik denk dat mensen wel geïnteresseerd zullen zijn. Wanneer ben jij daarna eigenlijk echt, weet je wel, Basic was je eerste taal. Heb je daarna nog een andere taal waarvan je die te programeerde? Ik heb aan een of andere taal geprogrammeerd die, weet je nog, voordat er smartphones waren, waren er, die apparaten heette Cyan, P-S-I-O-N, van die soort van super, ja, maar wel dat je een soort van open kon klappen, dat je een toetsenbordje had en zo. En daar kon je ook op programmeren en mijn ouders waren altijd super tech forward, zeg maar. Dus ik had op een gegeven moment de oude Cyan 3A ofzo van mijn vader of moeder, ik weet het niet meer precies. En daar kon je ook op in programmeren, iets van visual nog wat. Ik kan me niet meer exact herinneren, dus dat heb ik ook nog wel meegedaan. Daarna eigenlijk niet echt heel erg gediversificeerd tot ik begon met werken. En ik ben origineel opgeleid in Copel. Je gelooft het niet. Ik ging gelijk naar de middelbare school werken, zeg maar, een leer-werktraject. Dat je vier dagen kon werken, twee dagen naar school kon gaan. En een of andere heldere geest had het idee, laten we een 17-jarig mannetje, 18-jarig, laten we die Copel gaan leren. Ik heb het nooit wel meegedaan professioneel, dat ik ben daarna Java gaan leren en dat heb ik het vernoemdste van mijn carrière gedaan. En heel lang gedaan tot ik verhuisde naar Amerika en toen ben ik voor een ander bedrijf gaan werken. En sindsdien heb ik heel veel meer talen dingen moeten doen. Ik zal niet de hele twee uur vol kletsen. Ik kan het wel. Onze show heet natuurlijk CodeKlets, dus wat dat betreft komen we er vast wel op terug. Nou oké, dank je wel. Jeroen, hoe is het bij jou begonnen? Ja, eigenlijk best wel een beetje hetzelfde als bij Vincent. Ik vind het heel grappig. Ik ben ook in Basic begonnen. Dat was op een MSX computer van Panasonic en ik kan me nog goed herinneren zat ik inderdaad midden in de woonkamer bij mijn ouders. Want dat ding zat op de televisie aangesloten, dus dat ik hele boeken oogde. Soms dan begon ik gewoon te typen. Ik wist niet eens wat het programma deed. Ik denk dat ik acht jaar was. En toen had ik een boekhoudprogramma op mijn computer. Dan zat ik gewoon tegen mijn ouders van ja vertel maar wat jullie hebben uitgesproken deze maand. Super grappig was dat. En nou ja hele boeken weggetiep. Ik had ook heel veel applicaties kan je het niet echt noemen, maar gewoon een soort van scripts waren dat natuurlijk. Op cassettes. Dat heeft echt mijn ogen wat technologie betreft wel heel erg geopend. Toen ik mijn eerste DOS computer kreeg, ben ik ook nog verder gegaan in QBasic. Dat was een soort van basic interpreter voor DOS. Voor de mensen die nog niet afscheid konden nemen van die oude technologie. En toen later met Delphi aan de slag gegaan. Heel grappig heb ik ook een Star Trek applicatie gemaakt. Mijn eerste project was een quiz over de Star Trek The Next Generation. En dat was super tof. Heel nog met verschillende talen in de aanraking gekomen, maar eigenlijk sinds mijn grote mensenbaan voornamelijk in Java. En alle scripten automatiseren voornamelijk in Python en Bash. Ja, leuk om te horen. Je hoort het wel meer in alle afrevingen. Het begint altijd wel een beetje te knutselen met basic inderdaad. Ik hoorde ook de vorige aflevering ook met iets met gaming. Dat je echt een spel gaat bouwen en zo. Maar wel tof dat jullie beide dan ook iets met Star Trek hebben gedaan. Het is grappig, want de eerste programmerstappen die ik zette waren inderdaad om cheatcodes in te voeren in spelletjes. Dan moest je in een van pokecommando in typen om iets in een geheugenregister te gooien voordat je het spel startte. Daar begon het eigenlijk een soort van mee. Oké, dus je was toen al een beetje een hackertje. Ja, zo iets. Lekker kokken. Goed zo man. Ja, precies. Van al die glitches gebruik maken en zo. Ja, ik hoorde het ook al. Tof man. Nou, hartstikke leuk. Dat hebben jullie zo een goed verhaal. Ik stel voor dat we nu ook even doorgaan naar het onderwerp van deze podcast. Ja, observability. Nou goed, misschien vinden jullie misschien wel leuk om het even, ja, qua definitie misschien even neer te zetten, wat dat voor jullie betekent. Dus ja, misschien wel leuk om even met Vincent even te beginnen. Wat betekent observability? Zou ik het over observability hebben? Is het vaak ook aardig om het te vergelijken met iets dat de observability niet is. En het is makkelijk om te vergelijken met monitoring, want heel veel mensen denken daar op dezelfde manieren naar. Waar monitoring en logging en dat soort dingen je heel erg laten zien dat er rauwe stromen met informatie. En dan moet je dat interpreteren. Dus observability is er veel meer op gefocust. Eigenlijk is het niet helemaal vergelijkbaar, want het is een ander beestje. Het is meer mindset van ervoor zorgen. Dat door een combinatie van hoe je applicaties bouwt, maar ook hoe je applicaties, nou ja, niet monitort dus zeg maar. Maar dat observability eigenlijk ook neerkomt, dat het systeem je vertelt waarom het niet werkt. Niet dat het niet werkt of wat er niet werkt. Dus in plaats van dat je heel erg moet gaan zoeken. Dat de useful insights, hoe vertaal ik dat, de nuttige inzichten naar boven komen bubbelen zeg maar. En hoe ik het voor backtrace heel vaak, één van de zinnen die ik heel veel gebruik bij backtrace is signal to noise ratio. Dus wat wij voor game studios willen doen is ervoor zorgen dat als hun spellen problemen hebben, dat zij een goede signal to noise ratio hebben. En dan zie ik noise als monitoring. Je krijgt informatie binnen maar er zit geen betekenis aan vast. En signal is hetgene waar je naar op zoek bent. En in het geval van observability is hetgene wat je wilt weten, is waarom het niet werkt. Ik zit nu even te beseffen. Ja, backtrace dat is natuurlijk wel een bedrijf wat natuurlijk overgenomen is door source labs. Maar je hebt het nou net over games. Kun je misschien iets meer vertellen over backtrace voordat er misschien mensen denken ook thuis van ja, waar heeft hij het nou over? Ja, nee, dat is op zich wel goed idee inderdaad. Ik zal proberen semi kort te houden. Dat lastig voor mij. Backtrace waar het voornamelijk op gericht is, is het is niet alleen de games market, maar een groot gedeelte voor games is basically het error and exception monitoring voor de gaming vertical. Ik merk dat ik deze pitch over het algemeen in het Engels doe. Dus waar het op neer komt, is op het moment dat jij in game studio bent en jij maakt je spel, dan gaat dat vaak naar duizenden verschillende spelers en die kunnen op Playstation, op Switch zitten. Heel veel spellen tegenwoordig zijn op mobiele platforms en tablets en dat soort dingen. Dus een beetje succesvolle game studio heeft al snel naar duizenden mensen die dat spel aan het spelen zijn. Op het moment dat er dan iets fout gaat of iets gebeurt, met name massaal, zorgen wij ervoor dat al de informatie over de fouten die plaatsvinden, of dat nou een soort van soft fouten zijn, functionele fouten of harde crashes, dat we die allemaal verzamelen in één overzicht. Dus je hebt Playstation crashes naast je Switch crashes, naast je iOS, naast je Android, allemaal in één overzicht. Met de juiste context ook. En waar dan ook een onderdeel van is waar we heel erg veel op focussen, is het deduplication. Op het moment dat je tienduizenden fouten krijgt van duizenden verschillende apparaten, met name in een wereld waar je dus te maken hebt met gamers die allemaal op hun eigen apparaten zitten te spelen, daar kan je natuurlijk niet handmatig doorheen filteren, zeg maar. Dat is veel te veel werk. Dus we hebben een deduplication algorithm dat zegt oké, je hebt misschien 100.000 fouten binnengekregen, maar het zijn eigenlijk 150 verschillende buckets. En jouw meest veel voorkomende fout is, is deze. En zoveel procent van je spelers die worden daardoor beïnvloed. En dat is in nikt eraan is dat het heel erg lastig is om crashes bijvoorbeeld van Playstation en Nintendo en zo te krijgen. Dus uiteindelijk advocatenwerk om ervoor te zorgen dat wij bij de stores kunnen komen waar Sony en zo hun crashes opslaat. En dat is grappig genoeg ook alles wat ik erover mag. Oké, en goed dat je het even zo noemt. Maar eigenlijk beschrijf je dat toch ook een beetje waar observability dan over gaat, toch? Want je zei net van het is natuurlijk niet een een monitoring tool of iets dergelijks, maar het is echt daadwerkelijk de causes. Probeer het, ja hoe noem je dat? Ja, dat die in ieder geval de reden daarachter misschien iets over kan roepen. Ja, daar komt het inderdaad heel erg heerlijk op neer. Een combinatie van zowel op het soort van een individuele foutniveau, maar ook op trendniveau zeg maar. Want die beide inzichten die zijn natuurlijk heel erg heel erg belangrijk, want vanuit een observability perspectief wil je dat het systeem je heel erg helpt te prioriteren of eigenlijk al voor jou prioriteert. Ja, zodat je niet al die individuele prikkels hoeft te interpreteren en proberen wij zoveel mogelijk out of the box te doen. En je kan daar natuurlijk je eigen souchen ook nog over gieten, alerting instellen en dat soort dingen. Ja, wat het grote verschil ook is in vergelijking met monitoring, is dat monitoring dat is heel erg gericht op het meten van beschikbaarheid van applicatie. Is die er ja of nee? Dat is eigenlijk als je kijkt naar als je een goede observability inrichting hebt, dan kun je heel goed zien kan een klant of een gebruiker doen wat hij moet doen zonder dat er rare dingen gebeuren. En die metrieken die zijn in een eigenlijk een wereld waarin bedrijven eigenlijk alleen nog maar online interface met een klant. Dat is echt cruciaal. Ja, zeker. Maar voor wie denk je dat observability nou echt geschikt is? Wel een redelijk open vraag, maar goed misschien wel interessant genoeg om even te kijken van waar is de doelgroep? Ik denk dat het eigenlijk iedereen is die een applicatie of wat een ook digitaal aanbiedt en die zeker wil zijn dat zijn gebruikers daar tevreden over zijn. Uiteindelijk is het de betrouwbaarheid in de brede zin van een webshop of een spel of wat dan ook die gaat bepalen of een klant daar daadwerkelijk zijn aankopen gaat doen. Of die misschien nog een tweede deel van het spel gaat kopen. Dus ja, ik zou eigenlijk willen zeggen iedereen moet hier, iedereen die luistert in ieder geval, moet zich op een bepaalde manier gaan afdragen hoe kan ik observability een plek geven binnen mijn stack. Ja, want dat is eigenlijk wat je zegt, het is gewoon niet weg te denken. Dus het is niet iets wat je kan negeren. Op het moment dat jij echt een bepaalde kwaliteitsslat wil neerleggen en ook meten in hoe ver je die kwaliteitsslat haalt, dan is observability een heel erg belangrijk aandachtspunt. Zeker. Vincent, waarom vind jij het belangrijk? Ik vind het belangrijk omdat er alleen maar meer digitaal spul in de wereld komt en data interpreteren is moeilijk en duur en saai. En het nadenken over hoe je applicaties of hetgene wat je aan het drukken, hoe het met het ding gaat. Dus niet alleen of het stuk is of niet, wat Jeroen net al zei, maar wat de helft ervan is of inderdaad de doelen van de business behaald kunnen worden, oftewel de spelers kunnen spelen, of de mensen hun aankoop kunnen doen. Is essentieel de techniek overeind te houden en de business oftegene die uiteindelijk betalen voor IT op de best mogelijke manier kunnen bedienen. Ik denk ook dat observability, uiteindelijk is het een concept natuurlijk. Concept, model, whatever. En het heeft eigenlijk altijd bestaan. Je kan niet geen observability hebben, je kan slecht observable zijn, zeg maar, of niet ontworpen voor observability. Het is natuurlijk iets dat je altijd tot opzegere hoogte aanwezig is en dat het alleen een soort van een nieuwe term is om op die manier over na te denken. Omdat het niet alleen gaat om, monitoring is heel erg gefocust op, je monitort iets, zeg maar, je gaat van buiten, je gaat kijken hoe het het doet, terwijl observability van verschillende kanten afkomt. Dus het is meer mindset van hoe kan je observable zijn. Dus het is niet alleen, ik heb dat ding over daar en dat wil ik observeren of monitoren, zeg maar, het is meer dat het ding zelf ook nadenkt van hey, hoe kan ik de juiste signalen geven, zodat men weet wat er onder de motorkap plaatsvindt. En dat is gewoon essentieel om goede stappen te zetten en de business te vriend te houden, zeg maar, die uiteindelijk betaalt voor je mooie software. Nou ja, dan kom je ook in een situatie terecht waarbij je bijvoorbeeld kan gaan nadenken van ja, wat zijn metrics die ik kan exposeren om te zien in hoeverre mijn business doelen nog worden behaald. Dus ja, en dat is iets dat bij monitoring ben je daar totaal niet mee bezig. Kijk je alleen ja, werkt het. Maar bij observability kijk je echt naar bepaalde kwaliteitsdoelen. En ja, ik denk dat dat wel een natuurlijk het woord is nieuw, maar dat is wel iets dat daar nu pas over gesproken wordt. Het is eigenlijk heel raar. Ja, ja, ja, me eens. Ja, ja, wat ik vraag die me ook ineens te binnenschieten. Jullie gebruiken net de termen. Tracing werd net genoemd. Iets wat ik ook vaak hoor is metrics. Zouden jullie, want dat hoor ik ook vaak gewoon in de wereld van van van al die verschillende leveranciers rondom observability. Zou je het verschil kunnen uitleggen voor ons van wat het verschil is tussen. Ja, tracing of misschien moeten we wel beginnen bij monitoring, tracing en metrics. Dus de verschillen van die drie. Ja, dat is goed. Ik kan die wel even oppakken. Monitoring, dat is eigenlijk van buitenaf kijken, is een applicatie beschikbaar. Dat kan je doen door de API calls te faken richting een bepaald endpoint en te kijken of dat endpoint dan bijvoorbeeld te verwachten. En als je ook nog druk moet maken over de infrastructuur waar je applicatie op wijdt, dan kan je bijvoorbeeld kijken. Oké, lopen mijn harde schijven niet vol, maar dat soort dingen. Dat wordt steeds minder relevant in een tijdsberg waarbij alles in de cloud gaat en steeds meer dingen worden gedaan door diensten. Maar monitoring is voornamelijk, ja, checking of availability. Oké, goeie. Tracing is iets bijzonder krachtig en daar kijk je eigenlijk naar de requests die je applicatie ontvangt. En dan kun je bijvoorbeeld zien, stel dat er een bepaalde API wordt aangeroepen, hoeveel tijd is de applicatie kwijt met bijvoorbeeld het querien van de database. Of bijvoorbeeld het doen van een berekening of het ophalen van data uit een externe bron. En daarmee kun je heel goed zien als je dat juist inricht van oké, ik heb het naam nieuwe deployment van mijn applicatie, dat die 20 procent langzamer is geworden. En dan kun je zien, oké, dat mijn query's niet goed zijn. Dat is iets dat je vaak ziet. En metrics, dat zijn eigenlijk cijfermatige, een soort van KPIs eigenlijk, die voor jou interessant zijn. Dat kan bijvoorbeeld zijn het aantal winkelmantjes dat is betaald per uur of het aantal registratie-e-mails dat is verzonden per minuut. En als je daar in een keer een drop in hebt op een tijdstip waarvan je eigenlijk verwacht dat dat heel erg hoog zou moeten zijn, dan weet je van oké, er gaat misschien iets mis bij de creditcard provider of er gaat misschien iets mis bij mijn email provider. En dan kan je aan de hand daarvan aan de slag gaan aan de hand dus van real user data, van oké, ik moet iets gaan fiksen. En wat mooi is aan metrics is in veel gevallen kan die creditcard provider of die email provider gewoon nog steeds available zijn. Dus in je monitoring staan ze misschien allebei op groen, maar bijvoorbeeld door een configuratiefout of een deployment, dan heb je toch niet het resultaat. En dan kan je met metrics heel mooie problemen aan de kaart brengen. Ja, ik vind deze vraag ook wel goed van Wouter die die stelt. Hoe verschilt het dan, want we zijn net begonnen met monitoring of tenminste jij bent begonnen met monitoring uit te leggen, ten opzichte van tracing om die vergelijking te maken. Hoe verschilt dat ten opzichte van elkaar? Ja, het grote verschil zit er maar in dat monitoring is vaak aan de hand van synthetische data en tracing dat is gebaseerd op data van echte gebruikers. Dus dat zou de wijze van spreek je mijn moeder kunnen zijn die aan het wachten is op een scherm om haar belasting aangifte te kunnen doen. En zou je een voorbeeld kunnen geven van synthetische data? Ja, monitoring dat is vaak synthetisch en dan is het een gesimuleerde request die vanuit een datacentrum wordt gedaan en dat request dat is waarschijnlijk elke keer hetzelfde en als dat request niet werkt dan denk je van oké mijn applicatie is offline en ik moet iets gaan doen. Tracing dat is gebaseerd op dingen die echte gebruikers meemaken en dat is dus het grote verschil tussen synthetisch en daadwerkelijk real user metrics zoals je dat bij tracing hebt. Ja, monitoring kan ook heel belangrijk zijn bijvoorbeeld van verschillende datacenters dus dan ik het enige wat ik doe is aan de Albert Heijn API vragen hoe duur de kaas is dat doe ik dan vanuit Shanghai en Amsterdam en Berlijn en dat soort dingen super synthetisch maar het geeft je dan inderdaad aan van hey van waar is mijn applicatie bereikbaar het zegt voor de rest helemaal niets over wat er aan de hand is als je vanuit Shanghai niet kan vragen wat de kaas kost bij Albert Heijn. Ja precies ik heb het nog wel eens over gehad met iemand die ja bij de NS ook toevallig we werkte toen aan die digitale borden van NS dus al die analoge borden werden allemaal vervangen en ik weet nog wel dat we dan op een gegeven moment met een heartbeat ja wat is het een heartbeat ging ja noem het maar even meten dus dat is volgens mij wat jullie dan bedoelen met synthetisch dus dat je dus gewoon even een Ik ben nog levend. En dan niet zozeer van hey, dat werkelijk kijken of dat werkelijk het bord de juiste informatie geeft. Dus dat is misschien dan net even wat anders. Je hebt ja, dus observability, oplossingen en noem het maar even de traditionele tools om te monitoren. Kunnen jullie daar iets meer over vertellen? Ja, dat is eigenlijk meer een beetje in de richting van waar moet ik mee beginnen? Als ik echt observability wil gaan doen. Wat raden jullie aan? Even kijken. Het is een vraag die tijdens de sales trajecten waar ik doorheen ga natuurlijk eigenlijk vaak langskomt voor Game Studios. Dus ik kan het relateren heel erg aan praktijkervaring. Vaak is, dat is een trigger om te beginnen met monitoren. Soms zijn Game Studios die weten dat ze over een half jaar live gaan. Dus die denken van nou ja, dit is iets dat belangrijk is, want het staat in lijstjes en mensen hebben er ervaring mee, et cetera, et cetera. Of het is dat er een duidelijk een probleem plaatsgevonden heeft en dat je wil voorkomen dat je dat probleem, of je wilt als hetzelfde probleem of een vergelijkbaar probleem nog een keertje plaatsvind dat je het sneller weet. Waarom ik die twee opties noem is dat je begint in beide gevallen op een klein beetje een andere manier. Op het moment dat je een probleem gehad hebt en je wil dat type probleem in de toekomst verhelpen. Heel opgelost te krijgen en kan je niet heel erg uitgebreid gaan nadenken over wat is in het breedst van het begrip het beste idee. En waar je dan start is je kijkt naar je root codes analysis van wat is er nou precies gebeurd. Je gaat nadenken over wat zijn de signalen die waar ik mijzelf op had kunnen abonneren zonder dat ik iets aanpas zegmaar. Zorgability draait natuurlijk ook heel erg om het uitbreiden van je applicatie zodat ze de juiste informatie geven aan systemen zegmaar. Het is niet een kwestie van alleen ernaar kijken. Het is ook een kwestie van je applicatie ontwerpen op een manier dat ze observable zijn. Maar als je dat nog niet hebt dan is het een kwestie van eerst kijken van welke, maar wat was het probleem? Wat zijn de signalen waar ik op had kunnen reageren en dat inrichten op een bepaalde manier? Het liefst met tooling die je daadwerkelijk al hebt want het duurt lang anders om iets voor elkaar te krijgen in eerste instantie. Het tweede is heel veel game studio's die ik spreek die weten dat ze over een tijd in productie gaan dus die wil het gewoon goed oplossen. Waar je dan maar wil gaan kijken is dat je sowieso de juiste oplossing voor in huis haalt. Dat je niet alles helemaal zelf moet uitvinden en zelf moet inbouwen in je applicaties. Een combinatie van je applicaties slim in signalen laten geven en ook tooling hebben die die signalen op de juiste manier oppikt en weergeeft. Dus en mogelijk ook je applicaties uitbreiden. Want op het moment dat je daar aan het beginnen bent aan mijn kan je zou je de conclusie kunnen trekken van hey ik heb dit spel is nu in beta en ik zie tijdens mijn playtest dat ik bepaalde dingen niet kan zien. Dus daar wil ik nu de applicatie of de enige manier om dat te kunnen zien is de applicatie uitbreiden. Dat zijn de verschillende assen. Dus samenvattend kijken naar het verleden wat je wil weten als je een probleem gehad hebt. Kijk hoe je applicaties kan uitbreiden om de signalen die je wil weten van je applicatie die dus belangrijk zijn voor je business zeg maar. Dus kan mijn speler spelen op de manier dat die en welke signalen moet mijn spel geven dat ik dat weet. En derde de verzorgen dat je een endpoint hebt die die de load aan kan. Dus dat je iets hebt dat dat aggregeert dat het interpeteren van het signaal makkelijker maakt en niet omvalt op moment dat je game viral gaat of iets dergelijks. En vooral heel voorzichtig zijn met zelf bouwen. Ik weet niet Jeroen of jij dezelfde ervaring hebt. Ik heb veel conversaties met game studies die denken van het is toch niet zo ingewikkeld. Waarom moet ik daarvoor betalen? Kan ik toch zelf wel bouwen? Zie je dat ook Jeroen of niet? Ja dat heb ik gelukkig nog nooit gezien. Maar dat zou ik inderdaad sterk ontgraden. Kijk ik kom uit niet uit de game wereld maar voornamelijk uit web applicaties. Ja in het wereldje van de web applicaties heb je zoveel eigenlijk frameworks die als standaard observability technologie ondersteunen. Je moet echt zoeken bijvoorbeeld naar een web framework dat niet ondersteuning biedt voor Prometheus. Dus daar zelf tijd in investeren dat is gewoon zonde. Dan kan je net zo goed naar de koe gaan met dat geld en dan is het resultaat waarschijnlijk hetzelfde. Ja echt waar. Ja dat snap ik. Dat lijkt me een heel goede tijd en geld om hem te besteden. Ja want de vraag die ook vanuit Wouter kwam was waar start je dan met implementeren van zoiets en nou wat ik van jullie hoorde is niet zelf proberen te ontwikkelen. Maar ik denk wel dat we iets te maken hebben met observability by design. Dus die zal dan toch in je architectuur of hoe je het ook wilt noemen ontwerp van je applicatie het mee moeten nemen. Ja wat daarbij erg belangrijk is is dat je rekening houdt bij het schrijven van je applicatie dat bepaalde data die relevant is binnen je observability solution dat die door je applicatie gedeeld kan worden. Wat je ziet bij heel veel applicaties tegenwoordig is bijvoorbeeld als ze gewoon een metrics pagina hebben die gescathed kan worden. Dat is een hele simpele manier om te zorgen dat de applicatiedata in je observability step terecht kan komen. Het zal best kunnen dat je in de eerste instantie nog niet eens concreet weet wat je met die data wil gaan doen. Maar het feit dat het op een centrale manier wordt opgeslagen en dat je misschien pattern recognition daarop kan doen om bepaalde patronen in beeld te krijgen. En dat is al super waard. Ja en je zei net scraping. Wat zou je dan moeten scrapen? Welke tools zijn dat die je dan de meest gebruikte tool op het moment. Dat is Prometheus. Prometheus is een soort database die geconfigureerd kan worden om HTTP endpoints te schrijven om de minuut of wat je nodig hebt. En het is dan vrij gemakkelijk als jij metrics op een endpoint uit serveert om die te voeren aan Prometheus. En je kan dan daar naar kijken in dashboards of je kan zeggen van als er bepaalde waarden zijn die niet oké zijn dan wil ik een bericht krijgen. Oh ja, ja. Maar is dat dan observability of is dat dan monitoring? Ik ben even in de war. Ja dat is een hele goede vraag. Je availability monitoring die ga je waarschijnlijk niet op die manier doen. Want op het moment dat je applicatsteun niet is dan is waarschijnlijk dat scraping endpoints ook niet beschikbaar. Maar je kan op zo'n endpoint wel heel goed dingen laten zien. Maar oké hoeveel wincommandjes zijn er per minuut afgehandeld? Hoe snel zijn requests afgehandeld? Hoe lang is mijn applicatie bezig met het query van de database? En op die manier kan je een goed beeld krijgen van wat de gebruikerservaring is op de andere kant. Ja oké, cool. Ja dus, oh sorry Vincent, ga je gaan. Ja ik zou er wat aan toe willen voegen vanuit de gamehoek. Dus wat Backtrace recentelijk heeft, of nou het is al weer tijd geleden, heeft toegevoegd is error-free metrics. Wat een heel belangrijke manier is om een gevoel te krijgen met hoe je spelersbasis, hoe het gaat. Dus wat wij doen is niet alleen de bijhouwen van de fouten die plaatsvinden. Dat is in het begin wat Backtrace doet. Exception is of het crash is of je hebt een hang of iets dergelijks dat dat opgestuurd wordt. Maar wat we toegevoegd hebben ook is op het moment dat een sessie gestart wordt, of de applicatie gestart wordt in het geheel zeg maar, dat die data ook beschikbaar is. Dus dan kan je in context zien van misschien gaat mijn error rate wat hoog. Maar hoeveel mensen hebben daar daadwerkelijk last van? Hoeveel verschillende spelers zijn dat? Dus dat is ook een voorbeeld van het type data dat je daar naar binnen kan trekken. Dat dan iets zegt over je einddoel. En je einddoel is, ik wil dat zoveel mogelijk spelers lekker gewoon kunnen spelen zonder gestoord te worden zeg maar. En dat vertelt je dan inderdaad of je dat aan het bereiken bent. Bijvoorbeeld 95 procent van de spelers zijn foutvrij. En wat er dan binnen die 5 procent gaat, tot op zekere hoogte weet je al, daar kan je ook nog wel weer op gaan inzoomen enzo. Maar het signaal dat dan daardoor wordt weergegeven is veel belangrijker dan alleen weten hoeveel fouten je hebt. En dat gaat eigenlijk ook een beetje in dat verschil tussen observability en monitoring. Het ene is error monitoring, dan weet je hoeveel fouten je hebt. Door observability dat die mindset toe te voegen. Error free metrics is een goed voorbeeld van iets dat je toe wilt voegen aan je applicatie. Zodat je observability krijgt. Zodat je kan beantwoorden, hey is mijn spelersgroep, zijn ze blij of niet. En dat kan je niet als je alleen naar fout informatie kijkt. Ja, weet je even in het korte samenvat ik van wat ik nu even in op heb genomen. Dat je sowieso moet je observability by design gaan toepassen. Met je developers samen goed nadenken welke data wil ik gaan observeren en hoe zorg ik ervoor dat die observable is. Nou, ik hoorde net een tool die je goed kan gebruiken dat is Prometheus. Dus ja, die zullen we ook wel even in show notes plaatsen. Zijn er daarnaast nog tools die jullie echt in de gereedschapskist standaard aanwezig hebben als jullie met observability topics aan de gang gaan? Nou, wat zelf erg krachtig is, ik noemde net Prometheus. Prometheus is een tool die scapeert en die slaat het op. Om het vervolgens inzichtelijk te maken zie je eigenlijk dat Prometheus altijd hand in hand gaat met grafane. Ja precies, die hoorde ik ook veel. Grafana is een hele krachtige dashboarding tool die native ondersteuning heeft voor Prometheus en je kan eigenlijk op de manier waarop je een database queryt, kun je ook Prometheus queryen vanuit je dashboard en op die manier inzichten krijgen binnen de data die Prometheus verzameld heeft. Prometheus en Grafana die zijn open source, die kun je zo gratis downloaden. Maar ik kan me ook voorstellen dat er scenario's zijn waarin je het liefst voor een tool gaat die je niet zelf hoeft te beheren. In dat geval zijn er eigenlijk twee tools die ik persoonlijk heel graag gebruik. Aan de ene kant Datadoc en aan de andere kant New Relist. Dat zijn eigenlijk SAAS diensten om min of meer datzelfde doel te bereiken. Dat is heel saai want ik zou dezelfde twee genoemd hebben. Dat zijn toevallig ook de twee met de mooiste teams. Ik had natuurlijk gehoopt dat jullie elkaar zouden uitlachen, maar dat is dus niet gelukt. Ik hoor ook weleens over LogsIO. Hoor ik ook weleens wat geluiden? Hebben jullie daar ervaring mee? Ja, LogsIO is bijzonder krachtig. Je kan het eigenlijk zien als een SAAS oplossing die het op een bepaalde manier wel je zou de observability solution kunnen noemen, maar het is voornamelijk gericht op logging. Dus door zoekbaar maken van je logs en daar weer bepaalde analyses op. Ja, want ik hoor ook steeds meer over StackState de laatste tijd. Misschien kunnen jullie daar ook iets over vertellen want ik heb wel een beetje begrepen dat die ook allerlei causes en relaties proberen te leggen over wat er gebeurt in je product landscape. Ja, StackState is toevallig iets dat we ook gebruiken binnen de NS. Waar StackState bijzonder sterk in is inderdaad, zoals je zegt, relaties leggen tussen verschillende stukken van je landschap. Dat kan heel nuttig zijn wanneer je bijvoorbeeld als bij de NS heel veel afdelingen hebt die vele verschillende applicaties maken die met elkaar moeten interacteren en dat je dan eigenlijk een keten binnen je applicatie inzichtelijk wil maken. Maar het kan ook nuttig zijn wanneer je een microservice architectuur hebt en je dus data vanuit verschillende stukken van dat microservice landschap samen moet gaan brengen om de totaal ervaring voor je plant in beeld te brengen. Ja, ja, ja. Ja, precies, want ik heb ook wel even gekeken naar de website van StackState en dat viel me inderdaad op en ik moest gelijk dan een linkje leggen aan serverability, maar die klopt dan wel in die zin. Dus dat is echt wel een goeie... Zeker, ja, zeker, zeker. Nou goed en Vincent, hoe doet Backtrace dat? Doet hij dat ook op zo'n zelfde manier of kan je daar iets over vertellen? Ik vind het grappig om naar Jeroen te luisteren want het is duidelijk inderdaad Johnny dat jij veel meer bezig bent direct met Prometheus, Grafana, Locks.io en dat soort dingen terwijl dat voor ons zijn het meer endpoints. Dus veel van onze klanten die importeren metrics of gegevens die ze willen, uit Backtrace en pompen dat Prometheus in of Datadog of New Relic. Dus dat zijn hele gebruikelijke integraties die gedaan worden. Dus je kan Backtrace eigenlijk veel meer zien als een, ik weet niet of de term correct is in de observability lingo, maar meer een expertsysteem in de vorm van het verzamelen van crash informatie, met name crash informatie, is een heel gespecialiseerd werkje zeg maar. Want als je apps eruit klappen dan je kan niet nog je normale code meer uitvoeren en vaak de dumps die je dan ook krijgt die zijn bijna onleesbaar zeg maar. Die moet je dan, die books. Ben je dagen mee bezig om dat te begrijpen? En de focus van Backtrace is dan om dat hele proces te automatiseren. Dus op het moment dat je Android of je iOS app eruit klapt en dat die error dan of de crash daadwerkelijk automatisch opgeslagen wordt en opgestuurd wordt naar Backtrace. En dat in Backtrace dan ook die debug symbols aanwezig zijn en die op Fiscation en wat je dan ook gebruikt om je app te beschermen. Dat wij gelijk kunnen zien, oké binnen een paar milliseconden, oké dit is dan de call stack waar het uiteindelijk om draaide. En dan kunnen wij op dat moment zeggen dat deduplicatie waar ik vorige keer over of waar ik het eerder over had. Dus de bucket waarin je kan zien van alle fouten die met gebeurd zijn met dezelfde root cause. Heb je eigenlijk gewoon puur het telletje gaat dan een omhoog en dat klinkt heel simpel. Want het is super complex inderdaad om dat voor mekaar te krijgen vanuit een app die crashed of je PlayStation die crashed al helemaal zeg maar die crash informatie automatisch krijgen naar heel snel data van binnen te krijgen. Op dat gebied is Backtrace op zichzelf creëert het observability. We hebben dashboards en et cetera dat je in Backtrace kan kijken om een indicatie te geven hoe het met je spelers gaat. Maar als we gaan hebben over triple A studio's zeg maar, echt grote grote spelers. Zeven van de tien triple A studio's gebruiken Backtrace. Dus de spellet die jij gaaf vindt waarschijnlijk zit onze software erin gebakken. Maar die grote game studio's die trekken eigenlijk gewoon een metriek uit Backtrace. Al die informatie over het complex werk om puur een telletje eentje naar boven te krijgen zeg maar. En die laten dat dan zien in combinatie met andere gegevenen. Bijvoorbeeld hoeveel geld er uitgegeven wordt in de App Store. Dat je al voor spelers die skins kunnen kopen of dat soort dingen. Die voegen dat samen met andere KPIs of metrics die heel belangrijk zijn voor de monetisation van je game zeg maar. Dus op dat gebied is Backtrace eigenlijk net wat anders. Het zorgt ervoor voor kleine studio's meer dat je observability daar direct hebt. Maar zodra je groter wordt gebruik je het inderdaad meer als een expert systeem die data genereert over foutmeldingen, crashes en dat soort dingen. Die importeer je dan weer in een groter overzicht. Dus een klein beetje anders. We zijn een beetje meer downstream op dat gebied in vergelijking met dat. Ik denk dat dat ook komt omdat bij jullie de crashes natuurlijk volledig client-side gebeuren. Dat is het grote verschil met de omgeving waar ik vandaan kom. De omgeving waar ik gezeten heb, daar heb je een centrale plek waar de applicatie draait. En dan kun je veel meer van dat soort verwerking aan de server gaan doen. En servers zijn vaak ook wat stabieler dan clients. Met name als je het over spellen hebt zeg maar. Je weet van spellen dat... Veel minder verschillende configuraties natuurlijk. Heel veel interessante discussies of conversaties die ik heb die gaat juist inderdaad om... Er zijn net weer hele rits aan rapporten vrijgegeven zeg maar. Zijn bedrijven die dat doen die laten zien wat er in 2021 in de mobiele markt gebeurd is. En wat je ziet is dat het overgrote hoeveelheid geld verdiend wordt met de spellen. Volgens mij is het 60% van de revenue. Al was het misschien voor 2021 anders. Maar het belangrijkste is dat de grootste hoeveelheid van de spellen waar veel geld aan verdient wordt, daarom aankopen in het spel, maar ook via advertenties, zijn van die casual games zeg maar. Hele simpele spellen die je moeder waarschijnlijk speelt op een Android tablet die in de keuken laan ligt, die nog in de tweede wereldoorlog gebruikt is zeg maar. En dan is dat op zich heel grappig dat zo'n apparaat als je voor een bank werkt of zo zegt een bank nou ja, is prima dat jij een 32-bit Android device in de lab zit, maar ga maar niet proberen daar op de internet te bankieren. Gebruik de website maar. En voor game studios is het juist wel belangrijk om op die hele oude devices te kunnen draaien, tenminste is een business case voor. Dus op het moment dat je genoeg mensen hebt die zo'n oude ding hebben liggen en daar veel spellen op spelen, simpele spellen, dan kan je dan nog steeds inderdaad heel veel geld mee verdienen. En daardoor wordt het ook extra belangrijk om ook de informatie te kunnen verzamelen van die super oude apparaten. Dat is heel vaak in de server-site-wereld minder van toepassingen. Grappig is dat backtrace van origine uit de server-site-wereld komt. Zo deden bedrijven gestart was het eigenlijk, de eerste backtrace was command-line interface voor Linux, om op het moment dat iets core dumpte, dat je dan heel snel die core dump goed kan debuggen, zeg maar. We hebben veel ervaring met dat soort bedrijven ook en heel erg gestandardiseerde hardware. Backtrace draait ook op Comcast, de set-top boxes hier in Amerika. Ik weet niet of wie dat equivalent in Nederland noemt, maar dat ding dat je van je kabelmaatschappij hebt staan, waar je je tv signaal door binnen krijgt. Dus ja, daar zijn wat verschillen, zeg maar, in hoe je dat soort gegevens nog probeert te krijgen. En bepaalde dingen werken dan ook natuurlijk. Op een gegeven moment wordt het te oud en dan gaat het gewoon een stuk. Ja, dat snap ik. Ja, dat is trouwens ook een vraag van Wouter, want het gaat inderdaad om databehoefte rondom observability. En nu hebben we vanuit, noem het maar even de gaming-industrie en we hebben het net eventjes over de tv-industrie gehad, maar natuurlijk ook in de context van NS. Wat zijn nou echt cruciale gegevens die je zou moeten gaan observeren, of hoe je het ook wilt noemen. Als je gaat starten met observability in de applicatie lifecycle, hebben jullie gemene delen daarin of of is het echt heel specifiek op het domein waar je applicaties in gaat bouwen? Ik denk dat het heel domeinspecifiek is. Er zijn keypunten. Eigenlijk het eerste dat in het hoofd te binnen schoot was error rate en dingen als bijvoorbeeld de risk-omstein aan de hand van je traces. Maar ik kan me ook voorstellen dat er omgevingen zijn waarin een bepaalde maat van betrouwbaarheid belangrijker is dan snelheid. Dus eigenlijk ja, het is heel moeilijk te zeggen. Het belangrijkste is om gewoon het gesprek aan te gaan met stakeholders en samen tot een set aan metrieken te komen die werkt voor jullie en die het geluk van je klant mee kunnen maken. Ja precies. Servability voor pacemakers is heel anders dan de observability voor joules op je iPhone zeg maar. Ja precies, joules op je iPhone ja. Alhoewel zou het een relatie kunnen zijn als je slecht, sorry flauwe grap. Maar inderdaad het is inderdaad weer zo'n independent situatie. Maar wel fijn dat je, Ja Jeroen, dat je toch even de twee belangrijkste misschien even noemt. Die error rate en wat was die andere? Sorry. Response time. Ja ja ja. Ik zou er nog eentje aan toe voegen. Heartbeats denk ik. Ja dat is een beetje even te maken met response time ook. Omdat de heartbeats een simpele manier is om een indicatie te krijgen van dat iets, het is belangrijke informatie om te hebben als je daar geautomatiseerde stroom van data bij hebt. En uiteindelijk waar ik het over had, die crash free gegevens. Dat zijn uiteindelijk, je kan je kan het ook als heartbeats zien zeg maar. Als een speler een spel aan het spelen is. Het is instelbaar natuurlijk, maar elke half uur vocht er een heartbeat zeg maar. Het heeft hartslag van een super olifant ofzo, niet veel per seconde zeg maar. Dat is ook een belangrijke. En het is een soort van een makkelijke zeg maar. Heartbeats zijn niet moeilijk zeg maar. Het is heel erg, als je eerst een keertje heartbeat misloopt. Weet je al, er zit een van de kink in de kabel, het komt niet binnen. Nee niks aan het handje. Dus dat is ook eentje die makkelijk te bereiken is zeg maar. Ja, nee inderdaad. Ik kan me ook wel voorstellen als je die, noem het maar even die data opslag en stromen, dat je die op een gegeven moment natuurlijk in je applicatielandschap gaat of in je architectuur gaat organiseren. Hoe gaat het dan verder in z'n werk? Kunnen jullie daar iets over vertellen? Hoe je dan dat aanpakt? Hoe leg je die plannen zeg maar klaar om dat te gaan doen? Hebben jullie daar een concreet voorbeeld van? Ik heb op zich wel een concreet voorbeeld. Ik denk dat dat ook weer heel domeinspecifiek is. Denk ik. Vind je dat ook Jeroen, domeinspecifiek of niet? Ik heb daar misschien een twijfel over, maar ik ben heel benieuwd naar je antwoord. Dan ga ik je daarna afvragen. Ja, eindelijk. Even kijken. Wat mij opvalt is dat, en dat is gerelateerd aan dingen die ik daadwerkelijk zie gebeuren in de organisatie waarvoor ik werk en ook de klanten waar ik mee bezig ben, is dat je nog steeds wel een draaiboek nodig hebt. Als je bijvoorbeeld ziet, gebruik welke voorbeeld je wil, maar dat Fortnite-spelers geen skins meer aan het kopen zijn en dat is waar je het voornaamste geld mee verdient, dan moet je ook nog steeds dan wel weten wat je daarmee doet. Het inrichten van draaiboeken, hoe ga je met de verschillende situaties om? Dat is heel belangrijk, want je hebt net heel veel werk gestoken in het onderkennen van welke situaties zijn belangrijk voor onze business. En dan een goed proces te hebben om wat te doen met het feit dat zo een van die metrieken op zijn gat valt, is enorm belangrijk. Even iedere ochtend op je dashboard kijken, dat werkt niet. Dat werkt voor je Jenkins CI-Jaws, werkt dat op zich prima, ook niet geweldig, maar het is dat het helemaal ingebakken moet zitten in de manier dat je werkt. Het is ingericht op zo'n manier dat als er echt iets aan de hand is dat het gepusht wordt, dat je dus inderdaad alerting hebt staan, dat je weet dat je in zo'n situatie waar je mee om kan gaan, dat je iemand oncall hebt staan, dat die persoon weet wat zijn plichten en rechten zijn. Wat natuurlijk een beetje domeinspecifiek is. Je kan niet generiek zeggen wat er gebeurt in zo'n situatie, dat heeft heel erg met je applicatielandschap te maken. Dat zijn de gedachten die in mij opkomen. Jeroen? Kan ik me goed invinden. Ja, nee, kan ik me goed invinden. Ik probeerde echt eventjes een kleine wel te maken, maar ik ben het weer met je eens. Ik wil nog wel iets toevoegen. Ik zal ook kijken hoe je observability data op een zinvolle manier kan gebruiken in relatie tot je deployments. Kijk, wat je vaak ziet is dat, en nu dat steeds meer bedrijven microservices gaan implementeren en je eigenlijk ook steeds meer druk hebt op teams om snel te presteren, dat er steeds vaker ge-deployed gaat worden. En ik denk dat het ook heel goed is om aan de ene kant te kunnen zien hoe presteert de ene versie versus de andere versie. Dus wat ik eigenlijk altijd graag zie is als teams in de grafieken met bijvoorbeeld een error rate ook een marker hebben van oké, dit is het moment dat we nieuwe deployment hebben gedaan. Zodat je in één keer kan zien van de versie van vandaag die doet het niet goed in vergelijking met de versie van gisteren. En wat ik helemaal mooi vind is als je observability data dan ook nog een plek probeert te geven in hbtests of misschien canary deployments. Dus dat je eerst een kleine groep gebruikers blootstelt aan een nieuwe versie van je tool en sorry van je product en op het moment dat de error rate niet significant hoger is dat je langzaam steeds meer gebruikers daaraan gaat toevoeren. Ja dat is de ultieme droom situatie. Ik zie het niet vaak gebeuren helaas, maar dat is als ik een pen en een papier krijg om een implementatie van een juiste observability strategie te bedenken dan zou dit zijn hoe ik En bij wie zou je denk ik, ja dat is even een vraag die bij mij bovenkwam. Ik kan me ook voorstellen dat als jij als developer in zo'n team die heeft dat gebouwd en je moet ook nog daarnaast nog de features gaan opbouwen en data opslag gaan organiseren en dat soort dingen. Ja en dan ga je gauw weer door naar je volgende story van je backlog en dan blijf je meest interessante personen om dit te blijven volgen zeg maar want ja observability zegt al in de naam dat je het op een gegeven moment moet gaan observer. Is daar een rol voor ik als developer zeg maar? Ik denk eigenlijk dat dat een verantwoordelijkheid zou moeten zijn van het hele team en je zou bijvoorbeeld ook kunnen opnemen in je definition of done, definition of ready dat features die je zichtbaarheid verkleinen niet live mogen gaan. Dus dat je eigenlijk vastlegt in je team afspraak dat observability gewoon een belangrijke prioriteit. En ja dan kan je ook met product owners of met business mensen aan de slag gaan en zeggen van we gaan nu ontwikkelen ten koste van onze kwaliteit. Dus misschien dat we eventjes iets rustiger aan moeten doen met nieuwe features. Ja dat lijkt me wel een lastige discussie want je moet het toch maar goed het leuke wel weer van observability is is dat je die besluiten neemt op basis van data want anders doe je alles op onderbuikgevoel. Ja en een vraag ook die ik hier zie. Heb je er ook ervaring mee dat je observability als het ware ook als alerts zou kunnen inbouwen? Kijk met monitoring en ja dat daar is het een beetje standaard. Dan kan je volgens mij ook wel, nu moet ik even alerts zo instellen, maar hebben observability tools daar ook ideeën bij? Ik denk het wel. Alerts is een van de dingen die belangrijk is in backtrace implementaties zeg maar. Waar we ook veel flexibiliteit moeten toelaten. Dus dat je dingen kan instellen als ik hey ik wil alleen een message op Slack krijgen of een smsje of whatever. Als ik een outtrap die meer dan duizend keer plaatsvindt en meer dan 150 unieke gebruikers beïnvloed die meer dan 10% van de totale sessies representeert. Dat soort dingen. Dingen die echt overdreven, complex worden. Maar je ziet dat die flexibiliteit wel nodig is voor de individuele teams. Oftewel het wordt heel erg domeinspecifiek en afhankelijk van hoe jij je geld verdient en wat belangrijk is hoe je dingen wil oplossen. Dus voor alles dat via backtrace gedaan wordt is dat iets dat redelijk essentieel is alerting. Al voelt het tegelijkertijd een beetje old school zeg maar. Alerting is hetgene wat we al sinds 1970 doen als het gaat om het. Dus het is echt een soort van niet hip en cool. Ik hoop dat Jeroen het echt vet met me oneens gaat zijn en mijn opa noemt. Dat sowieso. Nou ja, ik ben het gedeeltelijk met je eens. Kijk, wat ik heel erg mooi vind is dat je nu best wel wat machine learning ook nog kan loslaten op je observability data en aan de hand daarvan slimmere alerting kan maken. Maar ja, ook dat heeft een grens. Ik werkte een paar jaar geleden voor een organisatie. Wij leefden een online dienst en dat werd eigenlijk door de bepaalde tijden gebruikt. En we hadden onze observability stack zo ingericht dat als er in een keer een drop in het aantal sessies kwam, dan kreeg iemand een cijntje. Want dan wisten we van oké, of de website is super lelijk geworden en mensen willen het niet meer gebruiken. Of er is een systeem kapot gegaan waardoor mensen geen toegang meer hebben tot ons systeem. Alleen toen was het een volgens mij kerst of in ieder geval een bepaalde feestdag die viel door de week. En niemand gebruikte onze tool. En toen zijn er dus mensen voor niks wakker gebeld. Dus op zich, ik denk dat alerting zal altijd blijven. We moeten er wel iets slimmers mee doen, maar de oplossing die is nog niet in zicht. Ik denk dat we wel afstappen van het type alert van eh, mijn harde schijf is vol. Ja, precies. Ja, klopt. Ik kan een beetje context geven. Ook een rot om de volgende vraag die Wouter stelde. Die vind ik wel interessant. Die stelt de vraag, preventiemogelijkheden. Oké, cool. Ja, geen idee. Maar als ik hem dan zou mogen invullen, ik werk op dit moment bij Agolt en ja, daar hebben we ook de topic observability staan. En dan proberen we ook na te denken over de visie van wat we ermee willen bereiken en dat soort dingen meer. En ook precies wat ook denk ik net hebben besproken van hoe kunnen we het willen ermee bereiken. En een van de dingen die ik hoor constant is zelfhieling. Ja, dus dat zijn een van onze speerpunten die we graag binnen Agolt willen gaan verbeteren. Dus inderdaad, even de clichédingen zijn dus niet meer alert van dat je harde schijf leeg is, maar dat die inderdaad automatisch een gebruikersdatum gaat wegplempen. Oh, ja, zoiets. Ja, precies. Ja, opschoon of weet ik veel wat. Ja, het is een grapje dat ik maak. Maar tegelijkertijd is dat heel erg actueel is voor ons op het moment. Wat er bij Crash Reporting meekomt is dat soms die rapporten echt supergroot zijn, met name van Playstation komen ofzo. En dat in bepaalde gevallen wij inderdaad zien dat er terabytes per uur bij klanten bijkomen. En ik had het er net over draaiboeken en observability en weten wat je moet doen. Het is een goed grote harde schijven in, zeg maar. En dat gaat natuurlijk allemaal via AWS tegenwoordig. Of letterlijk inderdaad zet je wat je bij ons kan aanzetten is sampling. Wat betekent dat wij wel de crash gaan analyseren. En als we dan zeggen van is een crash die we al vaker gezien hebben, dan pleuren we ze allemaal weg en houden er één per half uur of het kan je instellen, natuurlijk. Maar dat zijn wel van die voorbeelden daarvan, van de beslissingen die je dan moet maken. Gaat dat niet heel erg ten koste van de nauwkeurigheid van de verzamelde data als je dat doet? Het valt mee. Dat komt omdat het weggooien plaats vindt nadat het object het rapport verwerkt is. En op het moment dat wij een object verwerken, dan houden we de statistieken ervan bij. Maar gooi je het grote object weg, dus we weten bijvoorbeeld nog wat de call stack was, wat de process age was van niets. Noem nog tien andere dingen die belangrijk zijn en dat de fout plaatsgevonden heeft en wanneer en dat soort dingen. Maar alle details, dus de core dump, de onderliggende core dump, dat wordt opgeschoond. Dus je hebt alle statistieken nog wel, maar niet de detail informatie. De detail informatie heb je er vaak maar één van nodig. Dus als er een fout plaatsvindt die meerdere gebruikers hebben, je hebt maar één core dump eigenlijk nodig. Dat is een beetje wat te achterzetten. Ja precies. Dit heeft dan ook weer te maken met dat domein specifiek. Ik kan me voorstellen dat ze dat bij de NS niet zo snel zullen doen. Dat ze waarschijnlijk achteraf ook nog wel veel willen leren. Ja, dat is weer veel server-side en ik denk dat wij heel veel gekke corner cases hebben omdat dat IT-landschap gewoon zo groot is. Dus ja, wij zullen denk ik, als wij een tool als Backtrace zouden implementeren, dan zouden wij geneigd zijn om best wel veel op te slaan, denk ik. Maar als een organisatie als NS dat zou doen, dan zouden ze waarschijnlijk ook een on-prem variant daarvan aanschaffen. Want dan beslist je natuurlijk zelf gewoon over je storage en dat soort dingen. Dat is vaak de onderliggende reden deze discussies. Het zijn dan niet de grootste studio's en kleine studio's die staan op een gedeelde omgeving, zeg maar. Voor de grootste studio's hebben we een eigen omgeving en als de schijf bijna vol is, dan prikken we er een nieuw in en dan gaat de rekening naar de studio. Dat boeit ons relatief weinig, zeg maar. Ja, storage kost ook niets meer tegenwoordig. Dan zullen ze niet wakker van liggen als ze die factuur hebben. Nee, inderdaad. Met name omdat we daar onze marge niet opmaken, zeg maar. Dat is gewoon doorschuiven wat AWS ons rekent naar de klant, zeg maar. Maar ja, het kan heel snel gaan op het moment dat je het te maken hebt met dat het letterlijk een terabyte per uur aangroeit, zeg maar. Dat zijn van wel van die momenten dat je een strategie wil hebben. Ja. Ja, want kijk, we hebben het nu eventjes over een beetje de triviale dingen met de geheugen en de harde schijfruimte en dat soort dingen. Maar ik zit ook even te denken, Jeroen zei het net ook al, dat AB-test. Kijk, ja daar, dan wil je wel, misschien wel dat het systeem die je dan ontwikkeld hebt, dat die automatisch dan een besluit neemt. Ja, van dat inderdaad men, volgens mij zei Jeroen het, van als een website echt onwijs lelijk gevonden wordt en we zien dat op een of andere manier. Ik weet even niet hoe je dat kan bepalen, maar goed, stel je voor dat we iets hebben bedacht dat dat kan bepalen. Ja, dat hij dan ook uit zichzelf gewoon een besluit durft te nemen. Ja, dat zijn wel interessante dingen joh, hé. Ja, dat komt echt op. Ja, dat is LaunchDarkly en dat soort software, dus Canary Release software. Oh, dat bedoel je, ja. Ja, ja en dan kan je zeggen dat je misschien als je dan zo'n nieuwe versie even live zet in een selecte groep gebruikers, dat je dan je sampling wel weer gewoon maximaal zet. Ja, want die data die is super waardevoert. Ja, klopt. Ja, dat is een heel goed punt inderdaad. Op dat soort momenten heb je die resolutie juist wel nodig. En dat meer dynamisch laten zijn is iets, die discussie, die vindt wel vaker plaats, zeg maar, om op het AB-dinges, zeg maar, in te pluggen. Het is inderdaad iets wat voor mobiele apps is het met name heel erg belangrijk. Dus de game klanten die we hebben die naar Playstation en dat soort dingen daar inspelen, naar Deploy of Selfs, Steam en PC platforms enzo. Daar zie je net wat minder versies tegelijkertijd. Maar juist omdat er op mobiel veel van die casual games zijn, waar je mensen gewoon eigenlijk niet veel lastig vallen met, hey, je moet updaten. Kijk, als je wel wijs fan van een spel bent en je speelt dat uren per dag, ja, dan vind ik het prima om daar tijd en effort in te steken om het te upgraden. Je ziet dat gamers over het algemeen veel vergevender zijn op dat gebied. Maar voor casual games heb je dat eigenlijk juist niet. Dus dan heel belangrijk onderdeel van wat wij daar laten zien en wat een selling point is, zeg maar, is dat we kunnen zien hoeveel van je gebruikers op welke versie zit, zeg maar, user adoption. En dat dan inderdaad ook laten zien in een time series. Dus het is een beetje poor man's Prometheus. Je kan het veel mooier doen natuurlijk in een tool die daar specifiek voor gemaakt is. Maar je ziet het als gewoon kleine dashboordjes die je het allerbelangrijkste laten zien. Dat is een soort van de trend over user adoptions en je error rate, zeg maar. Nou jongens, we zijn al bijna anderhalf uur bezig met dit onderwerp. Je bent nog niet moe? Je kan gewoon doorgaan. Oké, dat vind ik wel een goede opmerking. Wat missen we nog? Wat zou je nog willen vertellen aan de luisteraars van, joh vergeet dit vooral niet als jullie uitgeluisterd zijn? Ja, als ik de luisteraars een tip mag geven, probeer die zichtbaarheid over je hele stack te creëren. Dus niet alleen wat er op de server gebeurt. Hoe snel je transacties daar gaan. Maar kijk ook bijvoorbeeld naar zaken die in de browser gebeuren. Dus als je een hele zware ja-gaanscript hebt die op bepaalde soorten browsers gewoon langzaam gaat, dan wil je dat weten want je wil daar gerichte optimalisaties op kunnen doen. Ik denk dat het zelfde ook aan de hand kan zijn op een bepaalde mobiele platform. Daar heeft Vincent misschien nog wel een goede idee over. Zichtbaarheid van je folder stack, dat is het belangrijkste. Want uiteindelijk je klant zijn geluk wordt bepaald door de zwarte schakel. Dus dat zou ik de luisteraar weer meegeven. Goede tip, die gaat in de boeken. Jij Vincent? Ik heb het idee dat ik al kan aansluiten op dat verhaal, het monitor van je hele stack en niet alleen die je website ook in de gaten houdt, dat komt inderdaad veel meer dichter in de richting waar Blivereak voor werkt natuurlijk heel erg mee bezig is. En ik zou daar aan toe willen voegen dat we ook vaak zien dat als je een spel hebt, als je denkt aan gamen dan denk je over het algemeen aan clientside dingen. Je hebt iets heel zwaars draaien op je laptop of op je gaming pc die vooral heel veel grafisch werk doet. Ik denk niet zo heel erg na over het server-side component. Maar vaak heb je een multiplayer server of iets dergelijks en toen ik begon in deze industrie te werken, vond ik het heel interessant om te achter te komen dat voor dat soort dingen, gameservers en dat soort dingen, dat Amazon daar ook gewoon standaard diensten voor heeft zeg maar. Wil je een chat-service? Wil je een multiplayer-service? Ah ja gewoon next next finish heb je er eentje. Standaard plug-in in je Unity game engine, kan je het gebruiken. Maar die dingen, daar geldt voor dat ze natuurlijk over het algemeen stabieler zijn dan spelers. Spelers zijn instabiel om dit natuurlijk gedeeltelijk zijn te spelen, dus als het eruit klapt. Het is niet pacemaker software of iets dergelijks ook omdat dat grafisch heel veel dingen doet. Maar ervaring is ook dat voor bepaalde game engines en Unreal is een goed voorbeeld daarvan. Unreal Engine is versie vijf van gereleased, super gaave voortgangen die ze daar geboekt hebben. Wow ja ik heb het gezien in de YouTube filmpjes. Ja het is super super mooi Het is ook nog een hele tunnel waar je in zou kunnen gaan. De verschillende manieren dat game engines werken. Ja andere onderwerp, andere aflevering. Maar een van de dingen daar is dat je daar ook mee moet pakken wat je gameservers doen. Dus ondanks dat je in een of ander standaard product van Amazon binnen sleept of je eigen ding. Of dus daarom begon ik te praten over Unreal. Unreal komt zeg maar met een client side component en ook een server side component. Dat is eigenlijk een soort van een klein beetje raar. Maar je draait dezelfde game engine ook server side. Wat betekent dat dat ding boven gemiddeld crasht. Vergelijking met andere software. Het is uiteindelijk een game engine is heel betrouwbaar. Maar in vergelijking met enterprise software toch wat minder zeg maar. Dus daar dan ook mee pakken dat je de server side die dingen ook captured. En dat kan nou ook wat ingewikkelder zijn omdat dat soms in een container draait. En hoe kom je dan bij je core dump? Hoe krijg je die informatie? Hoe kan je die opsturen en zo. Dat is ook iets dat ingewikkeld is en belangrijk is om aan bij stil te staan dat je die data ook ergens moet moeten oppikken. Een aantal dingen zijn ook simpeler daaraan. Hetzelfde geldt voor bijvoorbeeld de JavaScript applicaties en apps. Dus dat heel veel eigenaars daarvan die proberen het te beveiligen. Dus dat je het niet gewoon kan reverse engineeren en precies ziet hoe het spel werkt of hoe de website precies werkt. Door te minifyen of zelfs te upskaten en dat soort dingen. Dat is ook iets dat complexiteit toevoegt aan de client side zeg maar. Als je iets van een telefoon krijgt of nog eens een dikke complexiteit toevoegen die je vaak aan de server kant niet had. Ik ben even vergeten waarom ik erover begonnen was maar goed. Nou ja ik kan me wel voorstellen dat dat natuurlijk iets doet met de observability toch? Ja dat is wel als het in de feit is. Ja ja. Ja ja. Ja dat opfisketen gewoon nooit doen. Ja nee dat zijn inderdaad dingen die automatisch ingelezen worden en dan backtrace decodeert dat dan weer voor je. En dan kan je het gewoon weer lekker makkelijk doorpompen naar Prometheus. Dan heb je het allemaal plaintext zeg maar. Ja nou goed man. Ik denk dat we er nu al een beetje genoeg over hebben gekletst. Ik heb in ieder geval heel veel van jullie geleerd dus ja dank je wel daarvoor. Ik stel voor dat we doorgaan naar het volgende. Ja doen we maar even het luchtige gedeelte van onze CodeKlets podcast. Dus ik zou jullie twee ook even zeker aanraden om lekker even chill te gaan zitten en vooral te gaan genieten. Want we gaan twee leuke ja noem het maar even super onderwerpjes doen. Eentje die heb ik even in de verrassing gezet want normaal doen we altijd eventjes kort bespreken wat we gaan waar we het over gaan hebben Jeroen en Vincent. Maar ik heb niet verteld dat we vandaag ja dat is een beetje een lange tijd geleden weer maar we gaan weer eens de developer dilemmas doen. Kennen jullie dat toevallig? Nooit verteld. Oké maar goed ja iets wat ik zelf persoonlijk vind ik echt wel leuk om even met jullie jullie te challenger. Ik ga jullie gewoon met twee ja stellingen ga ik jullie mee confronteren en jullie moeten er echt eentje kiezen en it depends ja weet je dat wil ik gewoon niet horen. We willen gewoon je mening weten. Dus ja dus vandaar ik net zei van zorg ervoor dat je de relax bij zit en denk even goed na dat je antwoord natuurlijk en ja wellicht hebben we nou wel echt een ja gevecht tussen jullie ik weet het niet. Ik lok het elke keer uit maar het lukt me dus we gaan we gaan er gewoon drie doen en ja ik ben benieuwd wat jullie antwoorden zijn en deze developer dilemmas die kun je halen van de developer dilemmas.com. Dat is echt een free card game zeg maar en van AppSignal is het overigens. Dus die gaan we nu even doen. AppSignal is trouwens een hele mooie observability tool. We hebben er weer vertellen. Wat heb je er wel eens gebruikt? Ja, een van mijn klanten gebruikt het. Het is een Ruby tool en het doet eigenlijk een beetje dat application performance monitoring. Dus kijken van de applicatie hoe snel wordt die uitgeserveerd, waar wordt de tijd aan verspeeld. Ook denk ik een beetje wel in het straatje van Vincents werkgever ook. Error analytics. Om stack traces te analyseren en dan komt het met suggesties voor verbeteringen. Ik weet niet hoe zinvol die suggesties zijn maar ja brengt het in ieder geval in beeld. Wat cool joh. Net of ik het echt zo gepland had maar dat was het echt niet hoor Vincent. Het is inderdaad een app van AppSignal dus cool man. Leuk dat je het even deelt. Nou goed dan gaan we beginnen jongens. Hou je vast. De eerste die reageert die mag dan uitleggen waarom en de tweede mag daarna reageren. Hier komt ie. Higher salary or more interesting work? Ja ik woon nou in Amerika he. Higher salary dan toch maar. Daarom ben je daarheen gegaan. Capitalisme man. Ja ik weet het wel. Ja dat is er leuk misschien om te stellen. Ik kan me nog herinneren in de tijd dat bij volgens mij werkte we nog verder bij Xebia. Toen kwam ik naar New York. Dat was ook voor een van de sales ding. Heb je me flink begeleid daar ja en toen had ik al het gevoel van zo die Vincent die is flink vooruit gegaan toen ik jou daar ontmoette. Dus nou ik begrijp je antwoord. Ja ik kan er ook meer aan uitleggen. Het is iets dat vroeger of tenminste toen ik nog echt technicus was. Was het interessante werk echt heel belangrijk zeg maar. Wil je niet weet ik veel zelf als de JSP kloppen zeg maar. Omdat dat dan de primaire manier is dat je je dag doorbrengt en dat soort dingen. Wat ik nou zie in het werk dat ik doe is meer impactvol. Daardoor is het interessant maar het is ook tegelijkertijd stressvoller. Dus ik daarom natuurlijk die kaarten zijn zo gemaakt dat je er verschillende manieren over na kan na kan denken. Ja tuurlijk. Dus dat zit er ook een klein beetje achter. Ja ik begrijp het joh. En jij Jeroen? Ja ik zit erover na te denken. Ik vind het een aantal jaren geleden zou ik gezegd hebben hoger salaris. Op de een of andere manier merkte ik toen bij elke zoveel honderd euro die erbij kwam merkte ik dat men dat meer kon doen. Ik kon groter gaan wonen. Ik kon een ziekere auto hebben. Ik kon vaker op vakantie. Maar na een dan voel je het niet meer op de een of andere manier. Ja tuurlijk als je mij nu 500 euro per maand toeschuift Kishen. Ik denk dat ik heel blij zou zijn. Ik bedank je er zeker voor. Maar het is niet dat het echt een quality of life in de voetloos brengt. Dat ik nu wel op een best comfortabel niveau zit. En dan vind ik het belangrijker om met die 40 uur die ik heb om daar dan iets mee te doen dat me gelukkig maakt en ook nog een beetje waarde toevoegt voor de wereld. Dus ik zou dan toch wel voor interessant werken. Ja snap ik. Ik had dat toevallig nog. Dat was met mijn vrouw trouwens. Die had een keer ook ergens gesociteerd en die manager daar die had een heel betoog over dat er ergens een magisch nummer is in Nederland. En dan interesseert het niet meer wat je dan... Weet je al of het nou meer of minder gaat worden, dat interesseert dan niet meer. Precies en na een tijdje dan kom je ook op een inkomen dat de enige die er echt nog beter van wordt is de belasting. Dus stel je zit al in die 54 procent schijf. Dan heb je wel echt heel veel extra geld nodig om te zorgen dat je daar echt iets van merkt. Na een tijdje daar heb je ook al genoeg. Ja ik heb een auto, ik heb een huis. Tweede huis is misschien leuk voor in een ver land of zo. Maar tweede auto, dat zou een beetje gek zijn. Ja precies. Wat moet je dan nog met je geld? Nee heldenman. Ja ik vind het ook belangrijk. Zolang je maar gewoon de dingen kan doen waar je je het meest om geeft, dat is het belangrijkste volgens mij. Ik denk ook dat, kijk als je deze vragen buiten de IT zou stellen dan zou het antwoord misschien anders zijn. We zitten gelukkig in een industrie die al ergens betaald is. Ja dat is ook zo. Dus dan zullen er veel mensen gewoon more interesting work gaan kiezen. Ja absoluut. Precies. Oké. Nou goed ik stel voor dat we er nog even eentje doen. Ja leuk. Ja even kijken. Oh ik zit natuurlijk eventjes naar de resultaten te kijken. Ik heb nu even more interesting work gewoon omdat we dat samen zo concluderen. 65 procent inderdaad die kiest daarvoor. Oké. Ja deze hebben we al eens gehad dus die ga ik skippen. Oh deze vind ik heel tof. Stroopwafels or stroopwafels. Ik denk dat aan Vincent hoef ik hem niet te vragen want ja ik ben gewoon een Nederlander dus. Stroopwafels. Ja precies. Plus dat je ze hier ook als je met United vliegt krijg je ook stroopwafels als snack. De eerste is AdBlocker. De tweede is Chronological Twitter. Oh dat snap ik al. Ah ja welke features zou je het liefst willen hebben van Twitter. Nou dus je moet er echt twee kiezen dus de AdBlocker of de Chronological Twitter. Nou dan zou ik voor de chronologische tijd neigengaan. Oké dus die ads die overleef je wel. Ja ik heb de laatste tijd ads daar kan ik wel mee leven en die zijn in het geval van Twitter voor mij nog best wel relevant soms. Maar vooral bij nieuwsberichten in een wereld die zo snel gaat als de onze is het wel echt heel raar dat je soms gewoon discussies ziet over nieuwsberichten van eer gister. Ik vind dat zo leeg. Ik snap totaal niet waarom ze dat nou gedaan hebben. En jij Vincent? Oef. Ik denk dat ik de chronologische Twitter feed wel dat de fijnste is. Ja want zij hier roen ook al net. Ja en weet je ik gun Jack en Elon die advertentieeinkomst ook wel gewoon. Zo is dat. Ja precies. Hey even kijken. Ja nou even de resultaat even met jullie delen 74 procent heeft gekozen voor ad blocker. Dus men vindt toch blijkbaar de advertentie is toch wel irritant. Ja die had ik niet. Ja ja ik ook niet. Ik zou ook inderdaad die ad blockers die kan ik nog wel meleven. Of sorry de ads even kijken. Nou laatste dilemma deze ken ik ook al dus ga ik ook even skipen. Als ik er nou nog eentje ken ja oké deze die heb ik nog nooit die ken ik. Oh dit zegt mij ook helemaal niks. Maar goed ik ga het gewoon even voorlezen hopelijk jullie wel wat Tim Cook for a day. Of Linus Torvalds voor a day. Ja dat is een goede. Ik weet niet zo heel veel van Tim Cook persoonlijk. Ik weet dat Linus een ontzettende even kijken. Moeilijke persoonlijkheid heeft zeg maar. Oké. Maar ik vind hem wel interessanter. Dus ik zou toch Linus Torvalds voor a day kiezen. Ik denk dat hij me heel vaak beledigt en een leuke gesprek met hem kan hebben. Oké natuurlijk en nu heb ik er natuurlijk een beeld van hem. Maar het kan zijn dat ik nu echt een digibeet ben. Maar wie is Linus? Dat is de ontwikkelaar van Linus. Oh wow oké dus de Linux ontwikkelaar. Ah nou valt het kwartje. En Git ook. Ja Git inderdaad. Oké ja die is niet zo. Maar ook een leuke voor de speakers note. Hoe noem je dat? De talk die Linus gaf toen hij Git introduceerde is een briljante om te zien. Waar hij iedereen tot de veters afbrandt zeg maar. Echt waar joh? Oh shit. Ja hij is niet subtiel. Hij is slimmer naar beter. Oké oké. Dus jij zou dus voor Linus gaan en niet voor de tip. Ja ik vraag me nou net af. Is het nou zijn dat je een dag met ze doorbrengt of dat je ze een dag bent? Nee nee nee. Nou het vaag is dat het staat er niet echt zo letterlijk. Het staat er gewoon letterlijk gewoon Tim Cook voor RD. Dus of je dan hem bent of? Ik denk dat je ze moet zijn. Oké. Oké. Nou wie zou je dan zijn? Ja als ik mocht kiezen. Kijk ja ik wist eigenlijk al vrij snel. Ik zou Linus niet willen zijn want die gast heeft met veel te veel mensen ruzie. Dus dat is gewoon echt waarschijnlijk de meest ongezellige dag uit mijn leven. En als je Tim Cook mag zijn voor een dag dan is er nog best wel wat te bereiken. Ik zou dan echt eventjes wat knopen door gaan hakken. Om te zorgen dat we eindelijk USB-C op de iCloud pakken. Woehoe. Ja dat is me echt een doorn in het oog. Gewoon daarom alleen al ik weet je ik doe Tim wel voor een dag en dan. Alright, alright. Als ik dat één dag doe dan heb ik waarschijnlijk ook genoeg verdiend voor de rest van mijn leven. Dat is ook nog een voortje. Ja precies. Heb je je leven beter gemaakt. Ja dat is super leuk man. Nou ja goed ik hoop dat jullie het een beetje leuk hebben gevonden. Dat waren de drie dilemmas die ik daarvan doe. Ja heel leuk. Oké top, top. Nou goed dan gaan we naar het laatste onderdeel van onze podcast. Dat zijn de tips en tricks en van ons nog wat bash. Of een stuk van bash wil ik dat zeggen. Ja je mag ook bashjes noemen als je wilt. Dat maakt helemaal niet uit. Maar ja ik ben wel benieuwd naar wat jullie onze luisteraar zouden willen hebben jullie daar een beetje over nagedacht? Nee. Winst, ik zit aan mijn voorbereidingsnotities te kijken. Geef niet hoor, geef niet. Je hebt iets gemist, dus dan jij Jeroen? Ja ik zat net even na te denken. We hadden het net over observability. En op een bepaald level zou je kunnen zeggen oké ik heb een applicatie en een bepaalde infrastructuur die zorgt dat die applicatie naar de klant kan komen. Ik had het er net over probeer je heden sterk in beeld te brengen. Maar je zit natuurlijk tegenwoordig met steeds meer kwetsbaarheden. We hadden vorige week weer dat ding in Spring Framework. Een tijdje terug stond het hele wereld in de gek vanwege Log4j inderdaad. Ik ben benieuwd en dat kunnen mensen wel even in de comments zetten. Hebben jullie ideeën over hoe je op een soort van preventieve manier misbruik van dat soort vulnerabilities zou kunnen monitoren. Bijvoorbeeld te kijken hoe je netwerkverbinding in de zicht draagt. Zodat je eigenlijk op het moment dat een vulnerability naar buiten komt al kunt zien als stel dat het een 0D is bijvoorbeeld dat je dan kan zien van oh ja dit is eigenlijk al vijf keer geprobeerd op onze server. Ja dat lijkt me best interessant. Ik heb er geen paskwaar idee op. Terwijl we net aan het praten waren dacht ik van het zou wel tof zijn als daar iets voor is. Oké, ik heb toevallig een Kubernetes start-up gewerkt. Israëlisch is het Kubernetes start-up twee jaar geleden. Ik heb er wel een aantal ideeën over maar ik ben inderdaad benieuwd wat er in de community komt. Er zijn tools inderdaad specifiek gericht op het detecteren van attack factors en dat soort dingen. Het is echt, daar kan je inderdaad ook heel super diep in gaan. Ja want ik kan me ook herinneren inderdaad dat jij toch wel in de security vooral Kubernetes heel erg actief bent. Ja, meer was dan ben ik. En nu nog niet, dus je hebt niet nu al een tipje dat je denkt van hey. Nou ik realiseer me nou inderdaad opeens waar de tips van onze luisteraars, je had dat inderdaad in je email, ik heb er wel een aantal en dat zijn gewoon dingen die helemaal geen ene klap te maken hebben met observabiliteit. Te maken hebben met met games. Ik wil een plug doen voor Gorilla Games. Dat is een Nederlandse game studio die de Horizon Series gemaakt heeft en een van de delen redelijk recent uitgebracht heeft. En het is goed om je producten uit je eigen land te steunen zeg maar. Gronings Gas en Horizon Series van Gorilla Games zeg maar. Dat is een tip om te checken. Ja goede Nederlandse games. Ja en zijn er ook bepaalde boeken die jullie onlangs hebben gelezen? Misschien moet ik dat gewoon even stellen. Wat is de laatste boek dat je gelezen hebt? Ik ben recentelijk juist weer begonnen met fiction lezen. De hele tijd eigenlijk niet gedaan. En recentelijk eigenlijk was op een conferentie stond ik met iemand te praten die me iets aanraden. Ik lees veel science fiction. Het is relaxend om dat te lezen en het doet leuke dingen met je brein enzo. Er zijn twee dingen die ik zou noemen. De Bobbyverse Series van Danacy Taylor. Dat gaat over iemand die zijn brein ingevroren wordt en wakker wordt als een soort van dat zijn consciousness ingeladen is in een in een computer zeg maar. En hij gebruikt wordt om de intelligentie te zijn in een van Neumann probe. En een van Neumann probe is een ruimtevaartuig dat alles aan boord heeft om zichzelf te repliceren. Dus die kan een kopie van zichzelf maken en die kopie van zichzelf wat anders kan laten doen en dan door. En hier zitten dan 3D printers aan boord enzo. Dus super interessante serie als dat soort dingen je een beetje aanspreken. En een ander is Old Man's War van Scalzi en dat gaat over de mensheid verder in de toekomst. Waar de mensheid gepensioneerde recruit om in het leger te gaan. Dus die gepensioneerde een nieuw lichaam om dan vervolgens met heel veel ervaring, 75 jaar ervaring, levenservaring oorlogen te voeren in plaats van daar 20 jaar broekmannetjes in te sturen. En allebei interessante creatieve manier om naar de toekomst te kijken. Dus ik heb Old Man's War heb ik nog niet uit. Ben ik een deel drie of iets dergelijks, maar twee boekerseries die ik in ieder geval goed kan aanraden en vast goed aansluiten met de doelgroep van CodeKlets. Wauw, heel goed man, dankjewel. Ik denk zeker dat die aanslaat. En weet je, het eerste boek, Bobby's Series, was het nou? Bobby's First. Sorry, Bobby's First. Is daar in ieder geval een serie van gemaakt op Amazon. Het klinkt namelijk een beetje bekend, want we hebben namelijk ooit een keer een aflevering gehad, dat ging over mobile development. De gast daar, die had het ook over, een serie die, dat ging ook over dat iemand in verloren werd en dan opnieuw geinjecteerd in het leven met de gedachten. Of is dat iets anders? Het is een serie in de vorm van, het zijn zes boeken volgens mij of iets dergelijks, maar ik weet niet of, het klinkt alsof jij het over hebt, alsof het een... Ja, precies. Maar goed, niet dat ik weet. Maar goed, moeten we even opzoeken. Dat concept van Neumann Probe doet me ook een beetje denken aan de boord van Star Trek, die ook schepen hebben die zichzelf kunnen genereren en herstellen als er schade is. Ja, inderdaad. Dat klinkt ook nog niet gelegd. Ja, cool. En jij Jeroen, heb je nog een tof boek gelezen onlangs? Ja, het is een beetje een cliché aan het worden. Ik heb gisteren de Zeven Vinkjes uitgelezen. De wat? De Zeven Vinkjes. Dat is een boek. Het is eigenlijk een kritiek op de maatschappij, zoals we die in Nederland hebben geschreven, door Joris Luijenwijk. En dat gaat erover dat in het Nederlands, zoals dat er nu is, wordt eigenlijk 95 procent van de beslissingen genomen door personen die aan zeven kenmerken voldoen. En dat, ik weet, even alle zeven zo gauw niet uit mijn hoofd, maar dat is dat je hoog opgeleid bent, dat je hetero bent, dat je man bent, dat je blank bent. Ook dat je ouders hoog opgeleid zijn. En ja, het legt eigenlijk uit hoe schadelijk dat is, omdat mensen die heel erg op elkaar lijken, en dat hebben die mensen die aan die zeven eisen voldoen, die houden elkaar wat kwaliteit van de dingen die ze doen. Ja, het hand boven het hoofd. Hij pleit dus eigenlijk voor meer diversiteit. Ja, ik zit me wel, al sinds ik het boek uit heb, af te vragen hoe legit is het, want de schrijver van het boek voldoet zelf aan al die zeven vinkjes. Oh ja, nu heb ik hem. Ik weet het al. Ik heb ooit een keer ook weer zo'n filmpje gezien waar Sylvana Simons en hij samen zaten, geloof ik. Volgens mij hebben ze een gigantische ruzie gehad. Precies, ja. En ook op LinkedIn op een gegeven moment beland. Het werd op een gegeven moment een grote Facebook drama, weet ik nog wel, op LinkedIn toen. Naar aanleiding van die fitties ben ik het boek ook gaan rezen. Ja, snap ik. Ik was ook wel nieuwsgierig. Ik was ook gelijk nieuwsgierig, precies. Oké, oké. Goeie tip man. Ja, want het rinkelde wel even een belletje bij mij, maar ik kom even die plaatsen, dus fijn dat je hem even gedeeld hebt en ik zal hem zeker opnemen in de show note. Ja, super man. Nou, hartstikke fijn jongens. Ik zie dat we bijna de twee uur hebben bereikt, dus ja, ik wil je sowieso heel erg bedanken voor deze opname over observability. Dus bedankt Vincent en Jeroen voor deze aflevering. Ja, ik heb persoonlijk echt best wel veel van jullie geleerd, vooral met observability rondom een vraag die ik persoonlijk ook ja, eigenlijk niet zo snel zou stellen, maar gewoon omdat ik, ja wat dat betreft ook kudos aan Wouter Dijks dat hij die vraag heeft opgesteld. Maar het verschil weet je wel van monitoring, tracing en metrics, dat was echt voor mij even een, ik denk echt sterk knoggen. Ik ga hem straks de aflevering afluisteren en dan ga ik het ook gelijk documenteren, zodat ik het voor altijd in mijn hoofd heb gezet. Dus dank je wel daarvoor. Graag gedaan. Ja natuurlijk. Even kijken, nou mochten jullie, ja de luisteraars thuis mochten jullie CodeKlets leuk vinden. Vertel het vooral door aan je vrienden en collega's. Mocht je met ons ook willen kletsen, kom dan vooral naar onze Slack, want we hebben een Slack workspace gemaakt. Op codeklets.nl kun je de link vinden. Ja Jeroen en Vincent, ja je bent ook meer dan welkom. Er zullen misschien ook wel vragen richting jullie kant op komen. Nou hoe leuk is het als je ze persoonlijk kan beantwoorden. En misschien wel een discussie over die vraag van Jeroen, van ideeën om preventieve manieren te doen. Nou ja goed, je kan ons inderdaad makkelijk vinden op codeklets.nl. Je kunt ons ook vinden op Twitter, at codeklets. En op LinkedIn hebben we ook een company page, dus daar ben je ook meer dan welkom om ons te volgen. Ja, dus dat resulteert mij alleen maar nogmaals om jullie twee nog een keer te bedanken. En alle luisteraars natuurlijk bedankt voor het luisteren deze aflevering en tot de volgende keer. Dankjewel allemaal, doeg. Jij ook bedankt voor het hosten Kishen. Jo, graag gedaan. Hoi hoi.