Observability met Vincent Lussenburg en Jeroen Zeegers

Transcript

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