S02·016Observability met Vincent Lussenburg en Jeroen Zeegers
Vincent en Jeroen vertellen ons waarom Observability zo belangrijk is in Software Development
Vincent en Jeroen vertellen ons waarom Observability zo belangrijk is in Software Development
- ▸Wat observability inhoudt versus monitoring
- ▸Hoe je observability by design in architectuur integreert
- ▸Welke metrics domeinspecifiek belangrijk zijn
- ▸Hoe je Prometheus en Grafana voor observability gebruikt
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
