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é.
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.