WEBVTT

1
00:00:00.000 --> 00:00:03.700
Als je gaat starten met observability in de applicatie lifecycle,

2
00:00:04.480 --> 00:00:11.020
hebben jullie gemene delen daarin of is het echt heel specifiek op het domein waar je applicaties in gaat bouwen?

3
00:00:11.640 --> 00:00:15.460
Ik denk dat het heel domeinspecifiek is.

4
00:00:15.740 --> 00:00:17.040
Er zijn keekpunten.

5
00:00:17.180 --> 00:00:23.460
Eigenlijk het eerste dat in mijn hoofd te binnen schoot was error rate en dingen als bijvoorbeeld de response time

6
00:00:23.460 --> 00:00:25.460
aan de hand van je traces.

7
00:00:25.920 --> 00:00:29.500
Maar ik kan me ook voorstellen dat er omgevingen zijn waarin

8
00:00:29.500 --> 00:00:34.040
een bepaalde mate van betrouwbaarheid belangrijker is dan snelheid.

9
00:00:35.100 --> 00:00:36.300
Het is heel moeilijk te zeggen.

10
00:00:36.400 --> 00:00:43.340
Het belangrijkste is om gewoon het gesprek aan te gaan met je stakeholders en samen tot een set aan metrieken te komen.

11
00:00:44.520 --> 00:00:49.140
Die werkt voor jullie en die het geluk van je klant mee kunnen maken.

12
00:00:49.300 --> 00:00:50.840
Ja, precies.

13
00:00:51.200 --> 00:00:58.560
Observability voor pacemakers is heel anders dan observability voor jewels op je iPhone, zeg maar.

14
00:00:58.560 --> 00:01:02.160
Ja precies, het jewels op je iPhone, ja.

15
00:01:02.160 --> 00:01:06.400
Alhoewel zou dat een relatie kunnen zijn als je slecht...

16
00:01:13.450 --> 00:01:17.370
Nou, welkom allemaal weer bij een nieuwe aflevering van CodeKlets.

17
00:01:18.910 --> 00:01:21.530
Ja, vandaag ben ik in mijn eentje.

18
00:01:22.090 --> 00:01:24.590
Ja, dat is best wel jammer in die zin.

19
00:01:24.830 --> 00:01:29.390
We hadden echt wel zin om samen met Saber een leuke aflevering weer op te nemen.

20
00:01:29.390 --> 00:01:35.770
Maar helaas, ja, hij gaf me net zo net door dat hij, ja, hij werd wakker met gesloten ogen.

21
00:01:36.010 --> 00:01:39.450
En dan ga je je natuurlijk heel erg druk maken nu en dan denk je van jeetje, wat is er aan de hand?

22
00:01:40.350 --> 00:01:44.810
Maar ja, het is een beetje vaag, maar ja, hij heeft dus ieder geval wat last van zijn ogen,

23
00:01:44.890 --> 00:01:48.610
waardoor hij dus, ja, wat minder lekker, noem het maar even, in zijn vel zit.

24
00:01:49.250 --> 00:01:52.030
Dus heeft hij toch besloten om niet aanwezig te zijn.

25
00:01:53.130 --> 00:01:55.130
En uiteraard laten we wel weten hoe het met hem is,

26
00:01:55.150 --> 00:01:58.250
maar ik heb wel begrepen van hem dat het niet super ernstig is of zo

27
00:01:58.250 --> 00:02:00.870
en dat het wel oké komt, wordt.

28
00:02:01.550 --> 00:02:05.310
In deze aflevering van CodeKlets gaan we het hebben over observability.

29
00:02:06.250 --> 00:02:10.970
Ja, dat is een onderwerp waar onze gasten, want daar hebben we er twee van,

30
00:02:11.450 --> 00:02:13.630
veel mee te maken hebben in hun werkveld.

31
00:02:14.590 --> 00:02:19.610
En ja, ik ben zelf ook persoonlijk heel erg nieuwsgierig wat observability nou precies inhoudt

32
00:02:20.090 --> 00:02:25.630
en wat je er al mee kan en vooral hoe je, ja, software development lifecycle

33
00:02:25.630 --> 00:02:27.690
misschien wel mee kan gaan verbeteren.

34
00:02:28.970 --> 00:02:33.150
En ja, ik ben wel blij om deze twee gasten hier aan boord te hebben.

35
00:02:33.790 --> 00:02:36.310
Een van onze gasten vandaag is Vincent Lussenburg.

36
00:02:36.950 --> 00:02:40.590
Die werkt bij Backtrace IO, dat is een bedrijf van Solslabs.

37
00:02:41.170 --> 00:02:44.790
En hij is helemaal live uit San Francisco vandaag, de US.

38
00:02:45.910 --> 00:02:51.070
Eigenlijk Denver vandaag, maar dat is net wat dichterbij.

39
00:02:51.510 --> 00:02:53.710
Het is net een acht uur tijdsverschil in plaats van negen.

40
00:02:53.850 --> 00:02:56.130
Dus dat schildert voor jullie.

41
00:02:56.130 --> 00:03:03.750
Ja, want we doen meestal onze opnames in de avond inderdaad rond een uurtje of acht.

42
00:03:04.690 --> 00:03:08.690
Nou ja, heel fijn Vincent dat je er bent, van zo ver afstand.

43
00:03:09.470 --> 00:03:10.410
Het staat voor niks.

44
00:03:10.830 --> 00:03:11.490
Ja, precies.

45
00:03:12.970 --> 00:03:14.170
Ja, de introductie.

46
00:03:14.450 --> 00:03:16.810
Ja, ik ken Vincent uit mijn tijd bij Xebia.

47
00:03:17.470 --> 00:03:20.770
We hebben zelfs samengewerkt, Vincent, bij de ING bank.

48
00:03:21.770 --> 00:03:27.110
Ja, echt lekker aan het hacken geweest met de ING beleggen app, volgens mij.

49
00:03:27.770 --> 00:03:28.370
Ja, zeker.

50
00:03:29.810 --> 00:03:36.630
Ja, en nu al die jaren verder werk je nu als technical product manager bij Backtrace.

51
00:03:37.650 --> 00:03:40.110
En ja, misschien kan je nog even kort vertellen wat je doet.

52
00:03:40.510 --> 00:03:41.590
Ik ben wel nieuwsgierig.

53
00:03:41.830 --> 00:03:42.750
Ik ben ook wel nieuwsgierig.

54
00:03:42.790 --> 00:03:44.670
Wat doe ik eigenlijk zo min mogelijk?

55
00:03:45.370 --> 00:03:49.030
Nee, het is best wel veranderd voor mijn afgelopen periode.

56
00:03:49.030 --> 00:03:52.190
Wat ik deed hiervoor voor Backtrace is, ik was een sales engineer.

57
00:03:52.370 --> 00:03:58.350
Dus dat betekent demos doen van het platform, de proof of concepts begeleiden.

58
00:03:58.930 --> 00:04:00.210
Hartstikke leuke functie, vind ik.

59
00:04:00.870 --> 00:04:04.690
Maar technical product manager is meer gefocust op de groei van het product.

60
00:04:04.830 --> 00:04:09.070
Waar het product, of de producten naar toe zouden moeten gaan.

61
00:04:09.130 --> 00:04:12.610
Onderzoek doen naar waar gebruikers op zitten te wachten.

62
00:04:12.810 --> 00:04:18.610
Wat nou echt het verschil maakt tussen tien procent extra gebruikers tot het verdubbelen

63
00:04:18.610 --> 00:04:19.190
ervan.

64
00:04:19.850 --> 00:04:20.590
Dus onderzoek doen.

65
00:04:20.750 --> 00:04:22.530
Daar heb ik veel over aan het leren.

66
00:04:23.990 --> 00:04:27.570
En als onderdeel daarvan, Backtrace is recentelijk overgenomen door Source Labs.

67
00:04:28.230 --> 00:04:31.850
Dat is een acquisitie geweest, half jaar geleden of iets dergelijks.

68
00:04:32.630 --> 00:04:37.950
Dus we proberen het ook allemaal in elkaar te klikken, dat alle producten die in

69
00:04:37.950 --> 00:04:41.650
de Source Labs portefeuille zitten, met elkaar te maken hebben.

70
00:04:42.590 --> 00:04:45.950
Dus dat is een korte samenvat, ik ga vast nog wel vertellen over wat de producten

71
00:04:45.950 --> 00:04:50.810
precies zijn in context van observability, maar ik houd even kort nu.

72
00:04:51.590 --> 00:04:52.570
Oké, wat cool man.

73
00:04:53.130 --> 00:04:58.350
Ja, dat is wel een interessante overname dat Source Labs jullie hebben overgenomen.

74
00:04:58.850 --> 00:05:02.330
Voor de luisteraars die Source Labs niet zo kennen, zou je misschien iets over kunnen

75
00:05:02.330 --> 00:05:02.790
vertellen?

76
00:05:03.490 --> 00:05:04.510
Ja, absoluut.

77
00:05:05.090 --> 00:05:10.490
Source Labs is een, het bedrijf is groot geworden in de tijd en Kishen, ik weet

78
00:05:10.490 --> 00:05:17.770
dat jij en ik nog wel met Selenium gewerkt hebben in tijden van het ING projecten.

79
00:05:17.930 --> 00:05:23.950
Dus Selenium is een open source framework om automatisch met browsers te communiceren,

80
00:05:24.110 --> 00:05:27.370
dus net te doen alsof je gebruiker bent, zo kan je automatisch testen doen.

81
00:05:27.910 --> 00:05:33.390
En wat Source Labs mee is begonnen, is iets aan te bieden dat jij een browser

82
00:05:33.390 --> 00:05:34.350
als een service kan krijgen.

83
00:05:34.350 --> 00:05:43.930
Dus als jij wil safari op die versie van Mac of een Android Google browser, op die specifieke

84
00:05:43.930 --> 00:05:49.570
versie hebben zij grote farms van en dan kan je gewoon een sessie krijgen en automatische

85
00:05:49.570 --> 00:05:52.490
tests uitvoeren of handmatig testen.

86
00:05:52.690 --> 00:05:56.670
Wat ze daarna zijn gaan doen, omdat de markt is nu natuurlijk heel erg gestandardiseerd

87
00:05:56.670 --> 00:05:57.410
op Chrome.

88
00:05:57.950 --> 00:06:03.670
Als het op Chrome werkt, dan soms werkt er wel eens iets niet op safari of Brave

89
00:06:03.670 --> 00:06:09.910
of iets dergelijks, maar heel veel gebruikt dezelfde engine, dus die markt is kleiner

90
00:06:09.910 --> 00:06:10.890
en kleiner aan het worden.

91
00:06:11.370 --> 00:06:15.770
Dus waar het voornaamste werk nu op het moment in zit, is hun Virtual Device Cloud en Real

92
00:06:15.770 --> 00:06:19.530
Device Cloud, waar je dus je apps kan testen.

93
00:06:19.670 --> 00:06:24.750
Dus op het moment dat jij een ING bank of Apple bank of whatever bent, je wil zeker

94
00:06:24.750 --> 00:06:30.310
weten dat jouw app goed werkt op oude Android versies of een specifieke iOS versie,

95
00:06:30.310 --> 00:06:34.770
dat de thumbprint het nog doet in plaats van de Face ID, et cetera, et cetera.

96
00:06:35.090 --> 00:06:41.950
Dan kan je heel makkelijk zo'n device claimen zoals Device Cloud, zeg maar, en dan krijg

97
00:06:41.950 --> 00:06:47.230
je dan een apparaat dat wordt voor je geprovisiond, daar kan je een aantal minuten op testen

98
00:06:47.230 --> 00:06:50.750
en dan kan je de sessen weer teruggeven en dan kan je ook heel goed automatiseren.

99
00:06:54.170 --> 00:06:58.150
Er zitten meer tools, heel veel zit in het begin van de software delivery lifecycle.

100
00:06:58.680 --> 00:07:02.510
Ze hebben de acquisitie van Backtrace gedaan, want Backtrace nog niet zo heel veel over

101
00:07:02.510 --> 00:07:09.270
verteld, maar voornamelijk de meeste value brengt in productie. En for sauce is dat iets waar

102
00:07:09.270 --> 00:07:14.340
zij nog niet zo sterk in waren, ze zaten veel meer tijdens development en QA. En proberen

103
00:07:16.250 --> 00:07:23.750
daarmee een goede feedback signaal te geven van productie terug development in. En dat is

104
00:07:23.750 --> 00:07:27.210
de reden dat die acquisitie plaats heeft gevonden.

105
00:07:28.330 --> 00:07:33.350
Wauw, ja. Nou, bedankt voor je uitleg. Ja, nee, hartstikke mooi, man. Ja, en ik begrijp

106
00:07:33.350 --> 00:07:37.350
het ook waarom ze dan geïnteresseerd zijn in Backtrace, natuurlijk. Maar goed, ik weet

107
00:07:37.350 --> 00:07:41.590
net even iets meer, maar dan gaan we straks iets meer over vertellen. Nou, hartstikke

108
00:07:41.590 --> 00:07:47.570
goed. Dankjewel, Vincent, voor je introductie. Maar we hebben ook nog een andere gast om

109
00:07:47.570 --> 00:07:53.250
over observability wat inhoudelijker te gaan praten. We hebben dit keer Jeroen Zegers

110
00:07:54.230 --> 00:07:59.990
uitgenodigd. Die werkt nu op dit moment voor de Nederlandse spoorwegen. En ja, ik ken

111
00:07:59.990 --> 00:08:05.730
hem ook. Ik heb daar ook bijna een jaartje ongeveer gewerkt en wij hebben niet zozeer

112
00:08:05.730 --> 00:08:10.170
samengewerkt, maar hij werkt in een andere team genaamd Site Reliability Engineering

113
00:08:10.570 --> 00:08:15.630
en hij is nu ook een Site Reliability Engineer daar. En ja, misschien vind je het ook wel

114
00:08:15.630 --> 00:08:17.190
leuk om even jezelf voor te stellen, Jeroen?

115
00:08:18.870 --> 00:08:27.290
Zeker, ja. Mijn naam is Jeroen Zegers. Ik woon helaas niet in San Francisco, maar gewoon

116
00:08:27.290 --> 00:08:35.610
in Rotterdam. En ja, een van de dingen die ik super interessant vind, is teams helpen

117
00:08:35.610 --> 00:08:47.170
om betere en betrouwbare applicaties te maken. Ik doe dat vooral door ze te coachen op het

118
00:08:47.170 --> 00:08:54.510
slimme CI-CD trucjes, maar heel belangrijk, daarbij is ook teams laten zien hoe het

119
00:08:54.510 --> 00:09:02.090
echt met hun applicatie gaat en wat de ervaring is die gebruikers daadwerkelijk ondervinden

120
00:09:02.090 --> 00:09:06.390
bij het gebruik van die applicatie. Momenteel doe ik dat binnen de NS en dat maakt het

121
00:09:06.390 --> 00:09:11.610
extra spannend, omdat eigenlijk is iedereen op een bepaalde manier wel een paar keer per

122
00:09:11.610 --> 00:09:19.910
jaar en soms zelfs elke dag klant van de NS. Daardoor hebben de applicaties waar ik

123
00:09:19.910 --> 00:09:26.230
mijn druk over mag maken een heel groot publiek. Ja, precies. Dus des te meer misschien is,

124
00:09:26.230 --> 00:09:29.810
om toch een beetje een bruggetje te maken na zo'n opname, des te meer is observability

125
00:09:29.810 --> 00:09:39.910
misschien wel een noodzaak? Hoe ziet NS dat? Nou ja, dat is zeker waar. Je hebt

126
00:09:41.570 --> 00:09:47.150
een organisatie als de NS die is eigenlijk 24 uur per dag bezig. Je wilt het eigenlijk direct

127
00:09:47.150 --> 00:09:52.470
zien als er iets niet goed gaat met een van je applicaties. Als die applicaties niet

128
00:09:52.470 --> 00:09:59.770
werken kan het betekenen dat treinen niet kunnen rijden of dat kan betekenen dat personeel niet

129
00:09:59.770 --> 00:10:06.150
weet waar ze naartoe moeten gaan. Als je goed inzicht kan hebben in wat er onder de

130
00:10:06.150 --> 00:10:12.210
applicatie gebeurt, dan kan je dat soort dingen voorzien. Dat is iets waar ik me elke dag voor

131
00:10:12.210 --> 00:10:19.290
inzet. He, hartstikke mooi. Wat dat betreft echt twee perfecte kandidaten of gasten uitgenodigd

132
00:10:19.290 --> 00:10:27.350
over observability. Dus alvast aan mijn dank aan jullie. En over dank gesproken, ik wil ook

133
00:10:27.350 --> 00:10:35.310
even vandaag een speciale shoutout doen naar Wouter Dijks. Dat is een van onze CodeKlets.nl

134
00:10:35.310 --> 00:10:43.270
fans. En we spreken qua regelmatig ook op onze CodeKlets Slack workspace. Ja, en die heeft voor

135
00:10:43.270 --> 00:10:49.370
ons echt even de tijd genomen om alle vragen op te stellen voor deze aflevering. Dus ja,

136
00:10:49.610 --> 00:10:54.990
nogmaals heel erg bedankt Wouter voor je input. Ja, zonder jouw effort was deze aflevering

137
00:10:54.990 --> 00:11:00.150
een beetje leeg misschien. Dus ja, in ieder geval heel erg bedankt. En ja,

138
00:11:00.150 --> 00:11:05.490
je zal het horen, we zullen je vragen gaan stellen. Even kijken. Ja, we gaan nu even door

139
00:11:05.490 --> 00:11:13.390
naar het volgende onderdeel van onze podcast. Gewoon even wat meer jullie leren kennen. Ja,

140
00:11:13.390 --> 00:11:17.950
wij vragen altijd onze gasten om iets te vertellen over ja, wanneer het programmeren,

141
00:11:18.070 --> 00:11:25.150
zeg maar het coderen begon in je leven. Ja, dus ja, misschien Vincent zou jij daar

142
00:11:25.150 --> 00:11:29.430
misschien mee willen beginnen. Zou je eens kunnen vertellen wanneer het begon en hoe en wat en

143
00:11:29.430 --> 00:11:35.370
misschien wel waarom? Ja, Commodore 64. Dus dat is nou ja,

144
00:11:36.350 --> 00:11:44.150
jaar en een jaar geleden, ik zal denk ik negen of tien geweest zijn. En ik begon origineel met

145
00:11:44.150 --> 00:11:50.230
basic programma's over typen, want zo ging dat vroeger. Had je een boek en dan typte je

146
00:11:50.230 --> 00:11:54.490
gewoon letterlijk over wat er in het boek stond. En dan deed het programma wat. Ik weet

147
00:11:54.490 --> 00:12:01.890
dat ik een programma ingetypt had die in een of ander Beatles nummer 8-bit naspeelde,

148
00:12:02.070 --> 00:12:08.330
zeg maar. Toen ik ermee klaar was, realiseerde ik me dat ik het verkeerde hoofdstuk ingetypt

149
00:12:08.330 --> 00:12:12.610
had en dat nummer van de Beatles, dat kende ik helemaal niet. Dus dan moet ik de andere 64

150
00:12:12.610 --> 00:12:19.790
pagina's intypen. Dat is langzaam steeds erger geworden in de vorm van ik ben toen,

151
00:12:20.730 --> 00:12:28.930
ik ben een Star Trek nerd, dus ik heb mijn eigen Star Trek simulator text based adventure in mekaar

152
00:12:28.930 --> 00:12:36.510
getypt. Een aantal van de herinneringen die ik heb is dat ik me kan herinneren dat basic in die

153
00:12:36.510 --> 00:12:41.110
tijd moest je altijd een regelnummer ervoor zetten, zeg maar. Dan kon je go to's schrijven,

154
00:12:41.550 --> 00:12:46.960
10 go to 30, zeg maar. En ik kan me herinneren dat je je programma een instructie

155
00:12:46.960 --> 00:12:51.240
kon geven als je te weinig regelnummers had, want op een gegeven moment als je te veel go

156
00:12:51.240 --> 00:12:56.340
to's gemaakt had en je hebt 11, 12, 13, 14, 15 en weet je wel, dan kan je het programma zelf

157
00:12:56.340 --> 00:13:01.080
nieuwe nummers laten toekennen met een soort van 10 ertussen zodat je weer wat ruimte hebt.

158
00:13:01.760 --> 00:13:07.860
Ik kan me herinneren dat dat uren duurde voor zo'n simpele operatie als nummertjes

159
00:13:07.860 --> 00:13:13.600
toewijzen aan een aan een regelnummer. En weet je nog ongeveer wanneer dat was?

160
00:13:16.360 --> 00:13:23.020
1990 moet het geweest zijn, denk ik. Daarom trend. Ik heb nog vergens toen ik verhuisde naar Amerika

161
00:13:23.020 --> 00:13:29.380
ergens een printout gevonden met zo'n matrixprinter van die dingetjes aan de zijkant. Ik heb

162
00:13:29.380 --> 00:13:34.840
gedeelte ervan uitgeprint. Supermooi. Ik denk zelfs dat ik nog een floppy disk heb waar

163
00:13:34.840 --> 00:13:38.680
het op staat die niemand meer kan lezen. Ik kan me nog een keer een filmpje herinneren

164
00:13:38.680 --> 00:13:45.280
van iemand die een YouTube filmpje had gemaakt met zo'n printer die de geluid nog eventjes

165
00:13:45.280 --> 00:13:51.580
wilde laten horen. Ik kreeg gelijk kippenvel. Ik kan me zelfs herinneren. Iemand die het

166
00:13:51.580 --> 00:13:58.360
Star Wars Imperial Marche nagespeeld had met zo'n printhead. Oh, wacht even. Deze

167
00:13:58.360 --> 00:14:05.600
gaat in de show notes, man. Ik ga het even opschuiven. YouTube film Star Trek. Hoe heette

168
00:14:05.600 --> 00:14:12.180
die printer ook weer? Imperial Marche van Star Wars in dit geval. En dan welke printers

169
00:14:12.180 --> 00:14:17.880
ook weer? Hoe heette die ding ook weer? Matrix printers. Die gaan we even opzoeken.

170
00:14:18.060 --> 00:14:25.580
Ik denk dat mensen wel geïnteresseerd zullen zijn. Wanneer ben jij daarna eigenlijk

171
00:14:25.580 --> 00:14:33.540
echt, weet je wel, Basic was je eerste taal. Heb je daarna nog een andere taal waarvan je

172
00:14:34.160 --> 00:14:39.920
die te programeerde? Ik heb aan een of andere taal geprogrammeerd die, weet je nog, voordat

173
00:14:39.920 --> 00:14:48.300
er smartphones waren, waren er, die apparaten heette Cyan, P-S-I-O-N, van die soort van

174
00:14:48.300 --> 00:14:53.520
super, ja, maar wel dat je een soort van open kon klappen, dat je een toetsenbordje

175
00:14:53.520 --> 00:15:00.540
had en zo. En daar kon je ook op programmeren en mijn ouders waren altijd super tech forward,

176
00:15:00.540 --> 00:15:05.260
zeg maar. Dus ik had op een gegeven moment de oude Cyan 3A ofzo van mijn vader of moeder,

177
00:15:05.300 --> 00:15:11.800
ik weet het niet meer precies. En daar kon je ook op in programmeren, iets van visual nog wat.

178
00:15:12.160 --> 00:15:16.280
Ik kan me niet meer exact herinneren, dus dat heb ik ook nog wel meegedaan. Daarna

179
00:15:16.280 --> 00:15:25.240
eigenlijk niet echt heel erg gediversificeerd tot ik begon met werken. En ik ben origineel

180
00:15:25.240 --> 00:15:33.280
opgeleid in Copel. Je gelooft het niet. Ik ging gelijk naar de middelbare school werken,

181
00:15:33.480 --> 00:15:40.060
zeg maar, een leer-werktraject. Dat je vier dagen kon werken, twee dagen naar school kon gaan. En

182
00:15:40.060 --> 00:15:46.880
een of andere heldere geest had het idee, laten we een 17-jarig mannetje, 18-jarig,

183
00:15:47.120 --> 00:15:51.720
laten we die Copel gaan leren. Ik heb het nooit wel meegedaan professioneel,

184
00:15:51.720 --> 00:15:58.900
dat ik ben daarna Java gaan leren en dat heb ik het vernoemdste van mijn carrière gedaan. En heel

185
00:15:58.900 --> 00:16:03.100
lang gedaan tot ik verhuisde naar Amerika en toen ben ik voor een ander bedrijf gaan werken.

186
00:16:03.400 --> 00:16:09.900
En sindsdien heb ik heel veel meer talen dingen moeten doen. Ik zal niet de hele twee uur

187
00:16:09.900 --> 00:16:18.280
vol kletsen. Ik kan het wel. Onze show heet natuurlijk CodeKlets, dus wat dat betreft komen

188
00:16:18.280 --> 00:16:24.640
we er vast wel op terug. Nou oké, dank je wel. Jeroen, hoe is het bij jou begonnen?

189
00:16:26.320 --> 00:16:33.460
Ja, eigenlijk best wel een beetje hetzelfde als bij Vincent. Ik vind het heel grappig. Ik ben

190
00:16:33.460 --> 00:16:43.840
ook in Basic begonnen. Dat was op een MSX computer van Panasonic en ik kan me nog goed

191
00:16:43.840 --> 00:16:49.040
herinneren zat ik inderdaad midden in de woonkamer bij mijn ouders. Want dat ding zat op de

192
00:16:49.040 --> 00:16:57.560
televisie aangesloten, dus dat ik hele boeken oogde. Soms dan begon ik gewoon te typen. Ik

193
00:16:57.560 --> 00:17:03.940
wist niet eens wat het programma deed. Ik denk dat ik acht jaar was. En toen had ik een

194
00:17:04.640 --> 00:17:12.260
boekhoudprogramma op mijn computer. Dan zat ik gewoon tegen mijn ouders van ja vertel maar

195
00:17:12.260 --> 00:17:22.040
wat jullie hebben uitgesproken deze maand. Super grappig was dat. En nou ja hele boeken

196
00:17:22.860 --> 00:17:31.140
weggetiep. Ik had ook heel veel applicaties kan je het niet echt noemen, maar gewoon een

197
00:17:31.140 --> 00:17:40.360
soort van scripts waren dat natuurlijk. Op cassettes. Dat heeft echt mijn ogen wat

198
00:17:41.040 --> 00:17:47.740
technologie betreft wel heel erg geopend. Toen ik mijn eerste DOS computer kreeg,

199
00:17:48.460 --> 00:17:58.060
ben ik ook nog verder gegaan in QBasic. Dat was een soort van basic interpreter voor DOS. Voor

200
00:17:58.060 --> 00:18:06.520
de mensen die nog niet afscheid konden nemen van die oude technologie. En toen later met

201
00:18:06.520 --> 00:18:19.760
Delphi aan de slag gegaan. Heel grappig heb ik ook een Star Trek applicatie gemaakt. Mijn eerste

202
00:18:19.760 --> 00:18:36.500
project was een quiz over de Star Trek The Next Generation. En dat was super tof. Heel

203
00:18:36.500 --> 00:18:43.840
nog met verschillende talen in de aanraking gekomen, maar eigenlijk sinds mijn grote mensenbaan

204
00:18:44.340 --> 00:18:56.180
voornamelijk in Java. En alle scripten automatiseren voornamelijk in Python en Bash.

205
00:18:58.960 --> 00:19:05.020
Ja, leuk om te horen. Je hoort het wel meer in alle afrevingen. Het begint altijd wel

206
00:19:05.020 --> 00:19:12.640
een beetje te knutselen met basic inderdaad. Ik hoorde ook de vorige aflevering ook met iets

207
00:19:12.640 --> 00:19:17.960
met gaming. Dat je echt een spel gaat bouwen en zo. Maar wel tof dat jullie beide dan ook

208
00:19:17.960 --> 00:19:27.300
iets met Star Trek hebben gedaan. Het is grappig, want de eerste programmerstappen die ik zette

209
00:19:27.300 --> 00:19:33.960
waren inderdaad om cheatcodes in te voeren in spelletjes. Dan moest je in een van

210
00:19:34.480 --> 00:19:39.240
pokecommando in typen om iets in een geheugenregister te gooien voordat je het spel startte.

211
00:19:41.480 --> 00:19:46.620
Daar begon het eigenlijk een soort van mee. Oké, dus je was toen al een beetje een hackertje.

212
00:19:47.300 --> 00:19:55.200
Ja, zo iets. Lekker kokken. Goed zo man. Ja, precies. Van al die glitches gebruik maken en

213
00:19:55.200 --> 00:20:02.580
zo. Ja, ik hoorde het ook al. Tof man. Nou, hartstikke leuk. Dat hebben jullie zo een

214
00:20:03.100 --> 00:20:06.380
goed verhaal. Ik stel voor dat we nu ook even doorgaan naar het onderwerp van deze

215
00:20:06.380 --> 00:20:14.440
podcast. Ja, observability. Nou goed, misschien vinden jullie misschien wel leuk om het even,

216
00:20:14.520 --> 00:20:20.460
ja, qua definitie misschien even neer te zetten, wat dat voor jullie betekent. Dus ja,

217
00:20:20.800 --> 00:20:32.560
misschien wel leuk om even met Vincent even te beginnen. Wat betekent observability? Zou

218
00:20:32.560 --> 00:20:40.000
ik het over observability hebben? Is het vaak ook aardig om het te vergelijken met iets

219
00:20:40.000 --> 00:20:44.900
dat de observability niet is. En het is makkelijk om te vergelijken met monitoring, want heel

220
00:20:44.900 --> 00:20:52.040
veel mensen denken daar op dezelfde manieren naar. Waar monitoring en logging en dat soort

221
00:20:52.040 --> 00:20:58.480
dingen je heel erg laten zien dat er rauwe stromen met informatie. En dan moet je dat

222
00:20:58.480 --> 00:21:03.400
interpreteren. Dus observability is er veel meer op gefocust. Eigenlijk is het niet helemaal

223
00:21:03.400 --> 00:21:09.940
vergelijkbaar, want het is een ander beestje. Het is meer mindset van ervoor zorgen. Dat door

224
00:21:09.940 --> 00:21:15.640
een combinatie van hoe je applicaties bouwt, maar ook hoe je applicaties, nou ja, niet

225
00:21:15.640 --> 00:21:21.060
monitort dus zeg maar. Maar dat observability eigenlijk ook neerkomt, dat het systeem je

226
00:21:21.060 --> 00:21:27.440
vertelt waarom het niet werkt. Niet dat het niet werkt of wat er niet werkt. Dus in

227
00:21:27.440 --> 00:21:34.960
plaats van dat je heel erg moet gaan zoeken. Dat de useful insights, hoe vertaal ik dat,

228
00:21:35.440 --> 00:21:42.340
de nuttige inzichten naar boven komen bubbelen zeg maar. En hoe ik het voor backtrace heel

229
00:21:42.340 --> 00:21:49.580
vaak, één van de zinnen die ik heel veel gebruik bij backtrace is signal to noise ratio. Dus wat

230
00:21:49.580 --> 00:21:55.400
wij voor game studios willen doen is ervoor zorgen dat als hun spellen problemen hebben,

231
00:21:55.900 --> 00:22:01.500
dat zij een goede signal to noise ratio hebben. En dan zie ik noise als monitoring. Je krijgt

232
00:22:01.500 --> 00:22:06.380
informatie binnen maar er zit geen betekenis aan vast. En signal is hetgene waar je naar op

233
00:22:06.380 --> 00:22:11.300
zoek bent. En in het geval van observability is hetgene wat je wilt weten, is waarom het niet

234
00:22:11.300 --> 00:22:20.640
werkt. Ik zit nu even te beseffen. Ja, backtrace dat is natuurlijk wel een bedrijf

235
00:22:20.640 --> 00:22:27.320
wat natuurlijk overgenomen is door source labs. Maar je hebt het nou net over games. Kun je

236
00:22:27.320 --> 00:22:31.780
misschien iets meer vertellen over backtrace voordat er misschien mensen denken ook thuis van

237
00:22:31.780 --> 00:22:36.140
ja, waar heeft hij het nou over? Ja, nee, dat is op zich wel goed idee inderdaad. Ik

238
00:22:36.140 --> 00:22:41.680
zal proberen semi kort te houden. Dat lastig voor mij. Backtrace waar het voornamelijk op

239
00:22:41.680 --> 00:22:47.700
gericht is, is het is niet alleen de games market, maar een groot gedeelte voor games is

240
00:22:48.860 --> 00:22:56.680
basically het error and exception monitoring voor de gaming vertical. Ik merk dat ik deze

241
00:22:56.680 --> 00:23:04.180
pitch over het algemeen in het Engels doe. Dus waar het op neer komt, is op het moment dat

242
00:23:04.180 --> 00:23:09.940
jij in game studio bent en jij maakt je spel, dan gaat dat vaak naar duizenden verschillende

243
00:23:09.940 --> 00:23:14.400
spelers en die kunnen op Playstation, op Switch zitten. Heel veel spellen tegenwoordig zijn

244
00:23:14.400 --> 00:23:20.040
op mobiele platforms en tablets en dat soort dingen. Dus een beetje succesvolle game studio

245
00:23:20.040 --> 00:23:25.520
heeft al snel naar duizenden mensen die dat spel aan het spelen zijn. Op het moment dat

246
00:23:25.520 --> 00:23:31.620
er dan iets fout gaat of iets gebeurt, met name massaal, zorgen wij ervoor dat al

247
00:23:31.620 --> 00:23:35.720
de informatie over de fouten die plaatsvinden, of dat nou een soort van soft fouten zijn,

248
00:23:35.960 --> 00:23:42.180
functionele fouten of harde crashes, dat we die allemaal verzamelen in één overzicht. Dus

249
00:23:42.180 --> 00:23:46.560
je hebt Playstation crashes naast je Switch crashes, naast je iOS, naast je Android,

250
00:23:46.640 --> 00:23:53.380
allemaal in één overzicht. Met de juiste context ook. En waar dan ook een onderdeel van is waar

251
00:23:53.380 --> 00:23:58.520
we heel erg veel op focussen, is het deduplication. Op het moment dat je tienduizenden fouten

252
00:23:58.520 --> 00:24:04.480
krijgt van duizenden verschillende apparaten, met name in een wereld waar je dus te maken

253
00:24:04.480 --> 00:24:09.620
hebt met gamers die allemaal op hun eigen apparaten zitten te spelen, daar kan je natuurlijk

254
00:24:09.620 --> 00:24:14.780
niet handmatig doorheen filteren, zeg maar. Dat is veel te veel werk. Dus we hebben een

255
00:24:14.780 --> 00:24:19.520
deduplication algorithm dat zegt oké, je hebt misschien 100.000 fouten binnengekregen,

256
00:24:20.780 --> 00:24:27.860
maar het zijn eigenlijk 150 verschillende buckets. En jouw meest veel voorkomende fout is,

257
00:24:27.860 --> 00:24:38.720
is deze. En zoveel procent van je spelers die worden daardoor beïnvloed. En dat is in

258
00:24:38.720 --> 00:24:45.420
nikt eraan is dat het heel erg lastig is om crashes bijvoorbeeld van Playstation en Nintendo

259
00:24:45.420 --> 00:24:53.900
en zo te krijgen. Dus uiteindelijk advocatenwerk om ervoor te zorgen dat wij bij de stores kunnen

260
00:24:53.900 --> 00:24:59.900
komen waar Sony en zo hun crashes opslaat. En dat is grappig genoeg ook alles wat ik erover

261
00:24:59.900 --> 00:25:08.060
mag. Oké, en goed dat je het even zo noemt. Maar eigenlijk beschrijf je dat toch ook een

262
00:25:08.060 --> 00:25:14.440
beetje waar observability dan over gaat, toch? Want je zei net van het is natuurlijk niet een

263
00:25:14.440 --> 00:25:19.480
een monitoring tool of iets dergelijks, maar het is echt daadwerkelijk de causes. Probeer

264
00:25:19.480 --> 00:25:24.500
het, ja hoe noem je dat? Ja, dat die in ieder geval de reden daarachter misschien iets

265
00:25:24.500 --> 00:25:29.800
over kan roepen. Ja, daar komt het inderdaad heel erg heerlijk op neer. Een combinatie van

266
00:25:31.420 --> 00:25:36.760
zowel op het soort van een individuele foutniveau, maar ook op trendniveau zeg maar. Want die

267
00:25:36.760 --> 00:25:43.620
beide inzichten die zijn natuurlijk heel erg heel erg belangrijk, want vanuit een

268
00:25:43.620 --> 00:25:51.420
observability perspectief wil je dat het systeem je heel erg helpt te prioriteren of eigenlijk al

269
00:25:51.420 --> 00:25:57.530
voor jou prioriteert. Ja, zodat je niet al die individuele prikkels hoeft te interpreteren en

270
00:25:58.320 --> 00:26:05.760
proberen wij zoveel mogelijk out of the box te doen. En je kan daar natuurlijk je eigen

271
00:26:05.760 --> 00:26:14.480
souchen ook nog over gieten, alerting instellen en dat soort dingen. Ja, wat het grote verschil

272
00:26:14.480 --> 00:26:21.620
ook is in vergelijking met monitoring, is dat monitoring dat is heel erg gericht op het

273
00:26:21.620 --> 00:26:35.740
meten van beschikbaarheid van applicatie. Is die er ja of nee? Dat is eigenlijk als je kijkt naar

274
00:26:35.740 --> 00:26:42.540
als je een goede observability inrichting hebt, dan kun je heel goed zien kan een klant of een

275
00:26:42.540 --> 00:26:50.780
gebruiker doen wat hij moet doen zonder dat er rare dingen gebeuren. En die metrieken die zijn

276
00:26:51.980 --> 00:26:59.880
in een eigenlijk een wereld waarin bedrijven eigenlijk alleen nog maar online interface met

277
00:26:59.880 --> 00:27:09.900
een klant. Dat is echt cruciaal. Ja, zeker. Maar voor wie denk je dat observability nou echt

278
00:27:09.900 --> 00:27:16.140
geschikt is? Wel een redelijk open vraag, maar goed misschien wel interessant genoeg om even te

279
00:27:16.140 --> 00:27:25.600
kijken van waar is de doelgroep? Ik denk dat het eigenlijk iedereen is die een applicatie of

280
00:27:25.600 --> 00:27:32.320
wat een ook digitaal aanbiedt en die zeker wil zijn dat zijn gebruikers daar tevreden over zijn.

281
00:27:35.760 --> 00:27:44.560
Uiteindelijk is het de betrouwbaarheid in de brede zin van een webshop of een spel of

282
00:27:44.560 --> 00:27:52.220
wat dan ook die gaat bepalen of een klant daar daadwerkelijk zijn aankopen gaat doen. Of

283
00:27:52.220 --> 00:27:59.980
die misschien nog een tweede deel van het spel gaat kopen. Dus ja, ik zou eigenlijk willen

284
00:27:59.980 --> 00:28:06.180
zeggen iedereen moet hier, iedereen die luistert in ieder geval, moet zich op een bepaalde

285
00:28:06.180 --> 00:28:11.580
manier gaan afdragen hoe kan ik observability een plek geven binnen mijn stack. Ja,

286
00:28:11.620 --> 00:28:16.000
want dat is eigenlijk wat je zegt, het is gewoon niet weg te denken. Dus het is niet iets

287
00:28:16.070 --> 00:28:31.240
wat je kan negeren. Op het moment dat jij echt een bepaalde kwaliteitsslat wil neerleggen en

288
00:28:31.240 --> 00:28:39.360
ook meten in hoe ver je die kwaliteitsslat haalt, dan is observability een heel erg

289
00:28:39.360 --> 00:28:48.020
belangrijk aandachtspunt. Zeker. Vincent, waarom vind jij het belangrijk? Ik vind het

290
00:28:48.020 --> 00:28:54.920
belangrijk omdat er alleen maar meer digitaal spul in de wereld komt en data interpreteren

291
00:28:54.920 --> 00:29:09.120
is moeilijk en duur en saai. En het nadenken over hoe je applicaties of hetgene wat je aan het

292
00:29:09.120 --> 00:29:16.660
drukken, hoe het met het ding gaat. Dus niet alleen of het stuk is of niet, wat Jeroen net al zei,

293
00:29:17.120 --> 00:29:25.660
maar wat de helft ervan is of inderdaad de doelen van de business behaald kunnen worden,

294
00:29:26.000 --> 00:29:34.960
oftewel de spelers kunnen spelen, of de mensen hun aankoop kunnen doen. Is essentieel

295
00:29:38.220 --> 00:29:46.860
de techniek overeind te houden en de business oftegene die uiteindelijk betalen voor IT op de

296
00:29:46.860 --> 00:29:53.140
best mogelijke manier kunnen bedienen. Ik denk ook dat observability, uiteindelijk is het een

297
00:29:53.140 --> 00:29:58.640
concept natuurlijk. Concept, model, whatever. En het heeft eigenlijk altijd bestaan. Je kan niet

298
00:29:58.640 --> 00:30:04.420
geen observability hebben, je kan slecht observable zijn, zeg maar, of niet ontworpen voor

299
00:30:04.420 --> 00:30:10.200
observability. Het is natuurlijk iets dat je altijd tot opzegere hoogte aanwezig is en dat het

300
00:30:10.200 --> 00:30:15.720
alleen een soort van een nieuwe term is om op die manier over na te denken. Omdat het niet alleen

301
00:30:15.720 --> 00:30:23.500
gaat om, monitoring is heel erg gefocust op, je monitort iets, zeg maar, je gaat van buiten,

302
00:30:23.600 --> 00:30:29.580
je gaat kijken hoe het het doet, terwijl observability van verschillende kanten afkomt. Dus het is meer

303
00:30:29.580 --> 00:30:38.320
mindset van hoe kan je observable zijn. Dus het is niet alleen, ik heb dat ding over daar en dat

304
00:30:38.320 --> 00:30:43.740
wil ik observeren of monitoren, zeg maar, het is meer dat het ding zelf ook nadenkt van hey,

305
00:30:43.820 --> 00:30:49.780
hoe kan ik de juiste signalen geven, zodat men weet wat er onder de motorkap plaatsvindt. En

306
00:30:50.620 --> 00:30:56.980
dat is gewoon essentieel om goede stappen te zetten en de business te vriend te houden,

307
00:30:56.980 --> 00:31:00.560
zeg maar, die uiteindelijk betaalt voor je mooie software.

308
00:31:02.440 --> 00:31:08.460
Nou ja, dan kom je ook in een situatie terecht waarbij je bijvoorbeeld kan gaan nadenken van ja,

309
00:31:08.500 --> 00:31:14.500
wat zijn metrics die ik kan exposeren om te zien in hoeverre mijn business doelen nog

310
00:31:14.500 --> 00:31:19.940
worden behaald. Dus ja, en dat is iets dat bij monitoring ben je daar totaal niet mee bezig.

311
00:31:20.960 --> 00:31:27.220
Kijk je alleen ja, werkt het. Maar bij observability kijk je echt naar bepaalde

312
00:31:29.120 --> 00:31:36.040
kwaliteitsdoelen. En ja, ik denk dat dat wel een natuurlijk het woord is nieuw,

313
00:31:36.140 --> 00:31:42.400
maar dat is wel iets dat daar nu pas over gesproken wordt. Het is eigenlijk heel raar.

314
00:31:42.400 --> 00:31:50.160
Ja, ja, ja, me eens. Ja, ja, wat ik vraag die me ook ineens te binnenschieten. Jullie

315
00:31:50.160 --> 00:31:57.560
gebruiken net de termen. Tracing werd net genoemd. Iets wat ik ook vaak hoor is metrics.

316
00:31:59.060 --> 00:32:03.940
Zouden jullie, want dat hoor ik ook vaak gewoon in de wereld van van van al die

317
00:32:03.940 --> 00:32:08.780
verschillende leveranciers rondom observability. Zou je het verschil kunnen uitleggen voor ons

318
00:32:08.780 --> 00:32:15.020
van wat het verschil is tussen. Ja, tracing of misschien moeten we wel beginnen bij monitoring,

319
00:32:15.160 --> 00:32:23.360
tracing en metrics. Dus de verschillen van die drie. Ja, dat is goed. Ik kan die wel even

320
00:32:23.360 --> 00:32:31.380
oppakken. Monitoring, dat is eigenlijk van buitenaf kijken, is een applicatie beschikbaar.

321
00:32:31.520 --> 00:32:40.320
Dat kan je doen door de API calls te faken richting een bepaald endpoint en te kijken

322
00:32:40.320 --> 00:32:46.740
of dat endpoint dan bijvoorbeeld te verwachten. En als je ook nog druk moet maken over de

323
00:32:46.740 --> 00:32:51.240
infrastructuur waar je applicatie op wijdt, dan kan je bijvoorbeeld kijken. Oké, lopen mijn

324
00:32:51.240 --> 00:32:56.940
harde schijven niet vol, maar dat soort dingen. Dat wordt steeds minder relevant in een

325
00:32:56.940 --> 00:33:02.300
tijdsberg waarbij alles in de cloud gaat en steeds meer dingen worden gedaan door

326
00:33:02.300 --> 00:33:11.680
diensten. Maar monitoring is voornamelijk, ja, checking of availability. Oké, goeie. Tracing

327
00:33:11.680 --> 00:33:22.520
is iets bijzonder krachtig en daar kijk je eigenlijk naar de requests die je applicatie

328
00:33:22.520 --> 00:33:28.900
ontvangt. En dan kun je bijvoorbeeld zien, stel dat er een bepaalde API wordt aangeroepen,

329
00:33:30.600 --> 00:33:39.040
hoeveel tijd is de applicatie kwijt met bijvoorbeeld het querien van de database. Of bijvoorbeeld

330
00:33:39.040 --> 00:33:43.920
het doen van een berekening of het ophalen van data uit een externe bron. En daarmee kun je

331
00:33:43.920 --> 00:33:52.900
heel goed zien als je dat juist inricht van oké, ik heb het naam nieuwe deployment van

332
00:33:52.900 --> 00:33:58.080
mijn applicatie, dat die 20 procent langzamer is geworden. En dan kun je zien, oké,

333
00:33:58.080 --> 00:34:05.400
dat mijn query's niet goed zijn. Dat is iets dat je vaak ziet. En metrics, dat zijn eigenlijk

334
00:34:08.520 --> 00:34:16.320
cijfermatige, een soort van KPIs eigenlijk, die voor jou interessant zijn. Dat kan bijvoorbeeld

335
00:34:17.220 --> 00:34:24.820
zijn het aantal winkelmantjes dat is betaald per uur of het aantal registratie-e-mails

336
00:34:24.820 --> 00:34:31.060
dat is verzonden per minuut. En als je daar in een keer een drop in hebt op een tijdstip waarvan

337
00:34:31.060 --> 00:34:36.360
je eigenlijk verwacht dat dat heel erg hoog zou moeten zijn, dan weet je van oké, er gaat

338
00:34:36.360 --> 00:34:41.040
misschien iets mis bij de creditcard provider of er gaat misschien iets mis bij mijn

339
00:34:41.040 --> 00:34:45.300
email provider. En dan kan je aan de hand daarvan aan de slag gaan aan de hand dus van

340
00:34:45.300 --> 00:34:55.840
real user data, van oké, ik moet iets gaan fiksen. En wat mooi is aan metrics is in veel gevallen

341
00:34:55.840 --> 00:35:05.380
kan die creditcard provider of die email provider gewoon nog steeds available zijn. Dus in je

342
00:35:05.380 --> 00:35:11.640
monitoring staan ze misschien allebei op groen, maar bijvoorbeeld door een configuratiefout of een

343
00:35:11.640 --> 00:35:20.240
deployment, dan heb je toch niet het resultaat. En dan kan je met metrics heel mooie problemen aan

344
00:35:20.240 --> 00:35:26.760
de kaart brengen. Ja, ik vind deze vraag ook wel goed van Wouter die die stelt. Hoe

345
00:35:26.760 --> 00:35:32.140
verschilt het dan, want we zijn net begonnen met monitoring of tenminste jij bent begonnen met

346
00:35:32.140 --> 00:35:38.400
monitoring uit te leggen, ten opzichte van tracing om die vergelijking te maken. Hoe

347
00:35:38.400 --> 00:35:46.340
verschilt dat ten opzichte van elkaar? Ja, het grote verschil zit er maar in dat monitoring is vaak

348
00:35:46.340 --> 00:35:54.360
aan de hand van synthetische data en tracing dat is gebaseerd op data van echte gebruikers. Dus

349
00:35:54.360 --> 00:36:00.880
dat zou de wijze van spreek je mijn moeder kunnen zijn die aan het wachten is op een scherm

350
00:36:00.880 --> 00:36:05.820
om haar belasting aangifte te kunnen doen. En zou je een voorbeeld kunnen geven van synthetische

351
00:36:05.820 --> 00:36:17.940
data? Ja, monitoring dat is vaak synthetisch en dan is het een gesimuleerde request die vanuit

352
00:36:17.940 --> 00:36:23.800
een datacentrum wordt gedaan en dat request dat is waarschijnlijk elke keer hetzelfde en

353
00:36:25.600 --> 00:36:32.920
als dat request niet werkt dan denk je van oké mijn applicatie is offline en ik moet iets gaan

354
00:36:32.920 --> 00:36:44.740
doen. Tracing dat is gebaseerd op dingen die echte gebruikers meemaken en dat is dus het grote

355
00:36:44.740 --> 00:36:52.060
verschil tussen synthetisch en daadwerkelijk real user metrics zoals je dat bij tracing hebt.

356
00:36:53.460 --> 00:36:57.520
Ja, monitoring kan ook heel belangrijk zijn bijvoorbeeld van verschillende datacenters dus

357
00:36:57.520 --> 00:37:02.620
dan ik het enige wat ik doe is aan de Albert Heijn API vragen hoe duur de kaas is

358
00:37:02.620 --> 00:37:09.480
dat doe ik dan vanuit Shanghai en Amsterdam en Berlijn en dat soort dingen super synthetisch

359
00:37:09.480 --> 00:37:14.380
maar het geeft je dan inderdaad aan van hey van waar is mijn applicatie bereikbaar

360
00:37:14.380 --> 00:37:18.220
het zegt voor de rest helemaal niets over wat er aan de hand is als je vanuit Shanghai niet

361
00:37:18.220 --> 00:37:27.160
kan vragen wat de kaas kost bij Albert Heijn. Ja precies ik heb het nog wel eens over gehad

362
00:37:27.160 --> 00:37:35.480
met iemand die ja bij de NS ook toevallig we werkte toen aan die digitale borden van

363
00:37:35.480 --> 00:37:41.920
NS dus al die analoge borden werden allemaal vervangen en ik weet nog wel dat we dan op

364
00:37:41.920 --> 00:37:47.320
een gegeven moment met een heartbeat ja wat is het een heartbeat ging ja noem het maar even meten

365
00:37:47.980 --> 00:37:56.080
dus dat is volgens mij wat jullie dan bedoelen met synthetisch dus dat je dus gewoon even een

366
00:37:56.080 --> 00:38:04.900
Ik ben nog levend. En dan niet zozeer van hey, dat werkelijk kijken of dat werkelijk het bord

367
00:38:04.900 --> 00:38:13.520
de juiste informatie geeft. Dus dat is misschien dan net even wat anders. Je hebt ja, dus observability,

368
00:38:13.820 --> 00:38:21.880
oplossingen en noem het maar even de traditionele tools om te monitoren. Kunnen jullie daar

369
00:38:21.880 --> 00:38:27.060
iets meer over vertellen? Ja, dat is eigenlijk meer een beetje in de richting van waar moet ik

370
00:38:27.060 --> 00:38:32.480
mee beginnen? Als ik echt observability wil gaan doen. Wat raden jullie aan?

371
00:38:34.940 --> 00:38:41.160
Even kijken. Het is een vraag die tijdens de sales trajecten waar ik doorheen ga natuurlijk

372
00:38:41.160 --> 00:38:45.780
eigenlijk vaak langskomt voor Game Studios. Dus ik kan het relateren heel erg aan

373
00:38:47.180 --> 00:38:55.260
praktijkervaring. Vaak is, dat is een trigger om te beginnen met monitoren. Soms zijn Game

374
00:38:55.260 --> 00:39:00.260
Studios die weten dat ze over een half jaar live gaan. Dus die denken van nou ja, dit is iets

375
00:39:00.260 --> 00:39:04.700
dat belangrijk is, want het staat in lijstjes en mensen hebben er ervaring mee, et cetera,

376
00:39:04.820 --> 00:39:11.340
et cetera. Of het is dat er een duidelijk een probleem plaatsgevonden heeft en dat je

377
00:39:11.340 --> 00:39:17.160
wil voorkomen dat je dat probleem, of je wilt als hetzelfde probleem of een vergelijkbaar

378
00:39:17.160 --> 00:39:24.040
probleem nog een keertje plaatsvind dat je het sneller weet. Waarom ik die twee opties noem

379
00:39:24.040 --> 00:39:29.580
is dat je begint in beide gevallen op een klein beetje een andere manier. Op het moment dat je

380
00:39:29.580 --> 00:39:41.320
een probleem gehad hebt en je wil dat type probleem in de toekomst verhelpen. Heel

381
00:39:41.320 --> 00:39:46.820
opgelost te krijgen en kan je niet heel erg uitgebreid gaan nadenken over wat is in het

382
00:39:46.820 --> 00:39:54.480
breedst van het begrip het beste idee. En waar je dan start is je kijkt naar je root codes analysis

383
00:39:54.480 --> 00:40:01.700
van wat is er nou precies gebeurd. Je gaat nadenken over wat zijn de signalen die waar

384
00:40:01.700 --> 00:40:07.140
ik mijzelf op had kunnen abonneren zonder dat ik iets aanpas zegmaar.

385
00:40:08.040 --> 00:40:11.860
Zorgability draait natuurlijk ook heel erg om het uitbreiden van je applicatie zodat ze de

386
00:40:11.860 --> 00:40:16.840
juiste informatie geven aan systemen zegmaar. Het is niet een kwestie van alleen ernaar kijken.

387
00:40:17.300 --> 00:40:22.780
Het is ook een kwestie van je applicatie ontwerpen op een manier dat ze observable zijn. Maar als je

388
00:40:22.780 --> 00:40:27.860
dat nog niet hebt dan is het een kwestie van eerst kijken van welke, maar wat was het probleem?

389
00:40:28.720 --> 00:40:35.460
Wat zijn de signalen waar ik op had kunnen reageren en dat inrichten op een bepaalde

390
00:40:36.180 --> 00:40:42.440
manier? Het liefst met tooling die je daadwerkelijk al hebt want het duurt lang anders om iets voor

391
00:40:42.440 --> 00:40:48.120
elkaar te krijgen in eerste instantie. Het tweede is heel veel game studio's die ik spreek die

392
00:40:48.120 --> 00:40:53.420
weten dat ze over een tijd in productie gaan dus die wil het gewoon goed oplossen. Waar je

393
00:40:53.420 --> 00:41:00.260
dan maar wil gaan kijken is dat je sowieso de juiste oplossing voor in huis haalt. Dat

394
00:41:00.260 --> 00:41:06.200
je niet alles helemaal zelf moet uitvinden en zelf moet inbouwen in je applicaties. Een combinatie

395
00:41:06.200 --> 00:41:11.920
van je applicaties slim in signalen laten geven en ook tooling hebben die die signalen op de

396
00:41:11.920 --> 00:41:18.960
juiste manier oppikt en weergeeft. Dus en mogelijk ook je applicaties uitbreiden. Want

397
00:41:18.960 --> 00:41:22.840
op het moment dat je daar aan het beginnen bent aan mijn kan je zou je de conclusie kunnen

398
00:41:22.840 --> 00:41:28.820
trekken van hey ik heb dit spel is nu in beta en ik zie tijdens mijn playtest dat ik

399
00:41:28.820 --> 00:41:33.880
bepaalde dingen niet kan zien. Dus daar wil ik nu de applicatie of de enige manier om dat

400
00:41:33.880 --> 00:41:41.900
te kunnen zien is de applicatie uitbreiden. Dat zijn de verschillende assen. Dus samenvattend

401
00:41:41.900 --> 00:41:47.180
kijken naar het verleden wat je wil weten als je een probleem gehad hebt. Kijk hoe je

402
00:41:47.180 --> 00:41:51.840
applicaties kan uitbreiden om de signalen die je wil weten van je applicatie die dus

403
00:41:51.840 --> 00:41:58.400
belangrijk zijn voor je business zeg maar. Dus kan mijn speler spelen op de manier dat die

404
00:41:58.400 --> 00:42:04.160
en welke signalen moet mijn spel geven dat ik dat weet. En derde de verzorgen dat je een

405
00:42:04.160 --> 00:42:09.500
endpoint hebt die die de load aan kan. Dus dat je iets hebt dat dat aggregeert dat het

406
00:42:09.500 --> 00:42:15.400
interpeteren van het signaal makkelijker maakt en niet omvalt op moment dat je game viral gaat

407
00:42:15.400 --> 00:42:22.560
of iets dergelijks. En vooral heel voorzichtig zijn met zelf bouwen. Ik weet niet Jeroen of

408
00:42:22.560 --> 00:42:27.960
jij dezelfde ervaring hebt. Ik heb veel conversaties met game studies die denken van

409
00:42:27.960 --> 00:42:31.720
het is toch niet zo ingewikkeld. Waarom moet ik daarvoor betalen? Kan ik toch zelf wel bouwen?

410
00:42:32.740 --> 00:42:39.960
Zie je dat ook Jeroen of niet? Ja dat heb ik gelukkig nog nooit gezien. Maar dat zou ik

411
00:42:39.960 --> 00:42:45.920
inderdaad sterk ontgraden. Kijk ik kom uit niet uit de game wereld maar voornamelijk

412
00:42:45.920 --> 00:42:52.800
uit web applicaties. Ja in het wereldje van de web applicaties heb je zoveel

413
00:42:53.980 --> 00:43:03.800
eigenlijk frameworks die als standaard observability technologie ondersteunen. Je moet echt zoeken

414
00:43:03.800 --> 00:43:11.900
bijvoorbeeld naar een web framework dat niet ondersteuning biedt voor Prometheus. Dus

415
00:43:11.900 --> 00:43:17.800
daar zelf tijd in investeren dat is gewoon zonde. Dan kan je net zo goed naar de koe

416
00:43:17.800 --> 00:43:22.480
gaan met dat geld en dan is het resultaat waarschijnlijk hetzelfde. Ja echt waar.

417
00:43:23.480 --> 00:43:30.680
Ja dat snap ik. Dat lijkt me een heel goede tijd en geld om hem te besteden.

418
00:43:33.180 --> 00:43:40.460
Ja want de vraag die ook vanuit Wouter kwam was waar start je dan met implementeren van

419
00:43:40.460 --> 00:43:48.860
zoiets en nou wat ik van jullie hoorde is niet zelf proberen te ontwikkelen. Maar ik

420
00:43:48.860 --> 00:43:52.460
denk wel dat we iets te maken hebben met observability by design.

421
00:43:52.460 --> 00:43:58.900
Dus die zal dan toch in je architectuur of hoe je het ook wilt noemen ontwerp van je

422
00:43:58.900 --> 00:44:05.340
applicatie het mee moeten nemen. Ja wat daarbij erg belangrijk is is dat je

423
00:44:07.340 --> 00:44:13.780
rekening houdt bij het schrijven van je applicatie dat bepaalde data die relevant is

424
00:44:13.780 --> 00:44:19.700
binnen je observability solution dat die door je applicatie gedeeld kan worden. Wat je ziet bij

425
00:44:19.700 --> 00:44:25.620
heel veel applicaties tegenwoordig is bijvoorbeeld als ze gewoon een metrics pagina hebben die

426
00:44:25.620 --> 00:44:34.340
gescathed kan worden. Dat is een hele simpele manier om te zorgen dat de

427
00:44:34.340 --> 00:44:41.760
applicatiedata in je observability step terecht kan komen. Het zal best kunnen dat je in de

428
00:44:41.760 --> 00:44:46.580
eerste instantie nog niet eens concreet weet wat je met die data wil gaan doen. Maar het feit

429
00:44:46.580 --> 00:44:53.380
dat het op een centrale manier wordt opgeslagen en dat je misschien pattern recognition daarop

430
00:44:53.380 --> 00:44:58.500
kan doen om bepaalde patronen in beeld te krijgen. En dat is al super waard.

431
00:45:00.700 --> 00:45:10.660
Ja en je zei net scraping. Wat zou je dan moeten scrapen? Welke tools zijn dat die je dan

432
00:45:14.160 --> 00:45:24.340
de meest gebruikte tool op het moment. Dat is Prometheus. Prometheus is een soort

433
00:45:24.340 --> 00:45:33.040
database die geconfigureerd kan worden om HTTP endpoints te schrijven om de minuut of wat

434
00:45:33.040 --> 00:45:44.220
je nodig hebt. En het is dan vrij gemakkelijk als jij metrics op een endpoint uit serveert om die

435
00:45:44.220 --> 00:45:51.190
te voeren aan Prometheus. En je kan dan daar naar kijken in dashboards of je kan zeggen van

436
00:45:52.040 --> 00:45:57.560
als er bepaalde waarden zijn die niet oké zijn dan wil ik een bericht krijgen.

437
00:45:57.560 --> 00:46:03.760
Oh ja, ja. Maar is dat dan observability of is dat dan monitoring? Ik ben even in de war.

438
00:46:05.300 --> 00:46:12.760
Ja dat is een hele goede vraag. Je availability monitoring die ga je waarschijnlijk niet op die

439
00:46:12.760 --> 00:46:18.840
manier doen. Want op het moment dat je applicatsteun niet is dan is waarschijnlijk dat

440
00:46:20.000 --> 00:46:28.040
scraping endpoints ook niet beschikbaar. Maar je kan op zo'n endpoint wel heel goed

441
00:46:28.440 --> 00:46:35.960
dingen laten zien. Maar oké hoeveel wincommandjes zijn er per minuut afgehandeld? Hoe snel zijn

442
00:46:35.960 --> 00:46:48.820
requests afgehandeld? Hoe lang is mijn applicatie bezig met het query van de database? En op die

443
00:46:48.820 --> 00:46:54.720
manier kan je een goed beeld krijgen van wat de gebruikerservaring is op de andere kant.

444
00:46:55.140 --> 00:46:58.380
Ja oké, cool. Ja dus, oh sorry Vincent, ga je gaan.

445
00:46:58.380 --> 00:47:04.780
Ja ik zou er wat aan toe willen voegen vanuit de gamehoek. Dus wat Backtrace recentelijk

446
00:47:04.780 --> 00:47:09.620
heeft, of nou het is al weer tijd geleden, heeft toegevoegd is error-free metrics. Wat een

447
00:47:09.620 --> 00:47:16.860
heel belangrijke manier is om een gevoel te krijgen met hoe je spelersbasis, hoe het

448
00:47:16.860 --> 00:47:23.380
gaat. Dus wat wij doen is niet alleen de bijhouwen van de fouten die plaatsvinden. Dat is in het

449
00:47:23.380 --> 00:47:27.500
begin wat Backtrace doet. Exception is of het crash is of je hebt een hang of iets dergelijks

450
00:47:27.500 --> 00:47:31.420
dat dat opgestuurd wordt. Maar wat we toegevoegd hebben ook is op het moment dat een sessie

451
00:47:31.420 --> 00:47:38.720
gestart wordt, of de applicatie gestart wordt in het geheel zeg maar, dat die data ook

452
00:47:38.720 --> 00:47:45.120
beschikbaar is. Dus dan kan je in context zien van misschien gaat mijn error rate wat

453
00:47:45.120 --> 00:47:52.620
hoog. Maar hoeveel mensen hebben daar daadwerkelijk last van? Hoeveel verschillende spelers zijn dat?

454
00:47:53.800 --> 00:47:59.260
Dus dat is ook een voorbeeld van het type data dat je daar naar binnen kan trekken. Dat dan

455
00:47:59.260 --> 00:48:04.780
iets zegt over je einddoel. En je einddoel is, ik wil dat zoveel mogelijk spelers lekker gewoon

456
00:48:04.780 --> 00:48:10.640
kunnen spelen zonder gestoord te worden zeg maar. En dat vertelt je dan inderdaad of je dat

457
00:48:10.640 --> 00:48:17.780
aan het bereiken bent. Bijvoorbeeld 95 procent van de spelers zijn foutvrij. En wat er dan binnen die

458
00:48:17.780 --> 00:48:23.780
5 procent gaat, tot op zekere hoogte weet je al, daar kan je ook nog wel weer op gaan inzoomen enzo.

459
00:48:25.680 --> 00:48:31.720
Maar het signaal dat dan daardoor wordt weergegeven is veel belangrijker dan alleen weten hoeveel

460
00:48:31.720 --> 00:48:36.440
fouten je hebt. En dat gaat eigenlijk ook een beetje in dat verschil tussen observability en

461
00:48:36.440 --> 00:48:42.040
monitoring. Het ene is error monitoring, dan weet je hoeveel fouten je hebt. Door observability

462
00:48:42.500 --> 00:48:48.260
dat die mindset toe te voegen. Error free metrics is een goed voorbeeld van iets dat je

463
00:48:48.260 --> 00:48:53.540
toe wilt voegen aan je applicatie. Zodat je observability krijgt. Zodat je kan beantwoorden,

464
00:48:53.800 --> 00:48:58.300
hey is mijn spelersgroep, zijn ze blij of niet. En dat kan je niet als je alleen naar fout

465
00:48:59.380 --> 00:49:05.840
informatie kijkt. Ja, weet je even in het korte samenvat ik van wat ik nu even in

466
00:49:05.840 --> 00:49:12.420
op heb genomen. Dat je sowieso moet je observability by design gaan toepassen. Met je developers

467
00:49:12.420 --> 00:49:17.740
samen goed nadenken welke data wil ik gaan observeren en hoe zorg ik ervoor dat die

468
00:49:17.740 --> 00:49:24.620
observable is. Nou, ik hoorde net een tool die je goed kan gebruiken dat is Prometheus.

469
00:49:26.380 --> 00:49:30.680
Dus ja, die zullen we ook wel even in show notes plaatsen. Zijn er daarnaast nog

470
00:49:30.680 --> 00:49:37.420
tools die jullie echt in de gereedschapskist standaard aanwezig hebben als jullie met

471
00:49:37.420 --> 00:49:46.920
observability topics aan de gang gaan? Nou, wat zelf erg krachtig is, ik noemde net Prometheus.

472
00:49:48.160 --> 00:49:54.160
Prometheus is een tool die scapeert en die slaat het op. Om het vervolgens inzichtelijk

473
00:49:54.160 --> 00:50:00.100
te maken zie je eigenlijk dat Prometheus altijd hand in hand gaat met grafane. Ja precies,

474
00:50:00.100 --> 00:50:07.240
die hoorde ik ook veel. Grafana is een hele krachtige dashboarding tool die native ondersteuning

475
00:50:07.240 --> 00:50:15.480
heeft voor Prometheus en je kan eigenlijk op de manier waarop je een database queryt,

476
00:50:15.660 --> 00:50:22.940
kun je ook Prometheus queryen vanuit je dashboard en op die manier inzichten krijgen binnen de

477
00:50:24.180 --> 00:50:32.440
data die Prometheus verzameld heeft. Prometheus en Grafana die zijn open source, die kun je zo

478
00:50:32.440 --> 00:50:38.400
gratis downloaden. Maar ik kan me ook voorstellen dat er scenario's zijn waarin je het liefst voor

479
00:50:38.400 --> 00:50:45.880
een tool gaat die je niet zelf hoeft te beheren. In dat geval zijn er eigenlijk twee tools die ik

480
00:50:45.880 --> 00:50:52.400
persoonlijk heel graag gebruik. Aan de ene kant Datadoc en aan de andere kant New Relist. Dat zijn

481
00:50:52.400 --> 00:50:58.600
eigenlijk SAAS diensten om min of meer datzelfde doel te bereiken. Dat is heel saai want ik zou

482
00:50:58.600 --> 00:51:14.220
dezelfde twee genoemd hebben. Dat zijn toevallig ook de twee met de mooiste teams. Ik had

483
00:51:14.220 --> 00:51:19.460
natuurlijk gehoopt dat jullie elkaar zouden uitlachen, maar dat is dus niet gelukt.

484
00:51:23.040 --> 00:51:31.560
Ik hoor ook weleens over LogsIO. Hoor ik ook weleens wat geluiden? Hebben jullie daar ervaring mee?

485
00:51:34.120 --> 00:51:49.440
Ja, LogsIO is bijzonder krachtig. Je kan het eigenlijk zien als een SAAS oplossing die het

486
00:51:50.440 --> 00:51:57.340
op een bepaalde manier wel je zou de observability solution kunnen noemen, maar het is voornamelijk

487
00:51:57.340 --> 00:52:04.700
gericht op logging. Dus door zoekbaar maken van je logs en daar weer bepaalde analyses op.

488
00:52:05.500 --> 00:52:14.380
Ja, want ik hoor ook steeds meer over StackState de laatste tijd. Misschien kunnen jullie daar ook

489
00:52:14.380 --> 00:52:19.420
iets over vertellen want ik heb wel een beetje begrepen dat die ook allerlei causes en

490
00:52:20.540 --> 00:52:25.480
relaties proberen te leggen over wat er gebeurt in je product landscape.

491
00:52:28.120 --> 00:52:31.560
Ja, StackState is toevallig iets dat we ook gebruiken binnen de NS.

492
00:52:34.220 --> 00:52:40.060
Waar StackState bijzonder sterk in is inderdaad, zoals je zegt,

493
00:52:40.340 --> 00:52:45.520
relaties leggen tussen verschillende stukken van je landschap. Dat kan heel nuttig zijn

494
00:52:45.520 --> 00:52:52.920
wanneer je bijvoorbeeld als bij de NS heel veel afdelingen hebt die vele verschillende

495
00:52:53.840 --> 00:52:58.960
applicaties maken die met elkaar moeten interacteren en dat je dan eigenlijk een

496
00:53:00.140 --> 00:53:04.820
keten binnen je applicatie inzichtelijk wil maken. Maar het kan ook nuttig zijn

497
00:53:04.820 --> 00:53:13.500
wanneer je een microservice architectuur hebt en je dus data vanuit verschillende stukken

498
00:53:16.260 --> 00:53:23.040
van dat microservice landschap samen moet gaan brengen om de totaal ervaring voor je plant

499
00:53:23.040 --> 00:53:30.620
in beeld te brengen. Ja, ja, ja. Ja, precies, want ik heb ook wel even gekeken naar de

500
00:53:30.620 --> 00:53:37.020
website van StackState en dat viel me inderdaad op en ik moest gelijk dan een linkje leggen aan

501
00:53:37.020 --> 00:53:40.960
serverability, maar die klopt dan wel in die zin. Dus dat is echt wel een goeie...

502
00:53:40.960 --> 00:53:50.100
Zeker, ja, zeker, zeker. Nou goed en Vincent, hoe doet Backtrace dat? Doet hij dat ook op zo'n

503
00:53:50.100 --> 00:53:55.220
zelfde manier of kan je daar iets over vertellen? Ik vind het grappig om naar Jeroen

504
00:53:55.220 --> 00:54:00.100
te luisteren want het is duidelijk inderdaad Johnny dat jij veel meer bezig bent direct met

505
00:54:00.160 --> 00:54:04.320
Prometheus, Grafana, Locks.io en dat soort dingen terwijl dat voor ons zijn het meer

506
00:54:04.320 --> 00:54:10.040
endpoints. Dus veel van onze klanten die importeren metrics of gegevens die ze willen,

507
00:54:10.720 --> 00:54:18.010
uit Backtrace en pompen dat Prometheus in of Datadog of New Relic. Dus dat zijn hele

508
00:54:20.440 --> 00:54:25.460
gebruikelijke integraties die gedaan worden. Dus je kan Backtrace eigenlijk veel meer zien

509
00:54:25.460 --> 00:54:30.950
als een, ik weet niet of de term correct is in de observability lingo, maar meer een

510
00:54:30.950 --> 00:54:36.810
expertsysteem in de vorm van het verzamelen van crash informatie, met name crash informatie,

511
00:54:37.110 --> 00:54:45.110
is een heel gespecialiseerd werkje zeg maar. Want als je apps eruit klappen dan je kan niet

512
00:54:45.110 --> 00:54:50.570
nog je normale code meer uitvoeren en vaak de dumps die je dan ook krijgt die zijn bijna

513
00:54:50.570 --> 00:54:56.050
onleesbaar zeg maar. Die moet je dan, die books. Ben je dagen mee bezig om dat te begrijpen?

514
00:54:56.630 --> 00:55:00.910
En de focus van Backtrace is dan om dat hele proces te automatiseren. Dus op

515
00:55:00.910 --> 00:55:09.570
het moment dat je Android of je iOS app eruit klapt en dat die error dan of de crash daadwerkelijk

516
00:55:09.570 --> 00:55:14.010
automatisch opgeslagen wordt en opgestuurd wordt naar Backtrace. En dat in Backtrace

517
00:55:14.010 --> 00:55:19.050
dan ook die debug symbols aanwezig zijn en die op Fiscation en wat je dan ook gebruikt om

518
00:55:19.050 --> 00:55:25.850
je app te beschermen. Dat wij gelijk kunnen zien, oké binnen een paar milliseconden, oké

519
00:55:25.850 --> 00:55:31.550
dit is dan de call stack waar het uiteindelijk om draaide. En dan kunnen wij op dat moment

520
00:55:31.550 --> 00:55:36.890
zeggen dat deduplicatie waar ik vorige keer over of waar ik het eerder over had. Dus de

521
00:55:36.890 --> 00:55:42.950
bucket waarin je kan zien van alle fouten die met gebeurd zijn met dezelfde root cause. Heb

522
00:55:42.950 --> 00:55:48.410
je eigenlijk gewoon puur het telletje gaat dan een omhoog en dat klinkt heel simpel.

523
00:55:49.210 --> 00:55:57.710
Want het is super complex inderdaad om dat voor mekaar te krijgen vanuit een app die crashed of

524
00:55:57.710 --> 00:56:03.010
je PlayStation die crashed al helemaal zeg maar die crash informatie automatisch krijgen naar heel

525
00:56:03.010 --> 00:56:09.170
snel data van binnen te krijgen. Op dat gebied is Backtrace op zichzelf creëert het

526
00:56:09.170 --> 00:56:16.390
observability. We hebben dashboards en et cetera dat je in Backtrace kan kijken om een indicatie te

527
00:56:16.390 --> 00:56:21.630
geven hoe het met je spelers gaat. Maar als we gaan hebben over triple A studio's zeg maar,

528
00:56:22.930 --> 00:56:27.870
echt grote grote spelers. Zeven van de tien triple A studio's gebruiken Backtrace. Dus de

529
00:56:27.870 --> 00:56:33.810
spellet die jij gaaf vindt waarschijnlijk zit onze software erin gebakken. Maar die grote

530
00:56:33.810 --> 00:56:39.310
game studio's die trekken eigenlijk gewoon een metriek uit Backtrace. Al die informatie over

531
00:56:39.310 --> 00:56:45.790
het complex werk om puur een telletje eentje naar boven te krijgen zeg maar. En die laten

532
00:56:45.790 --> 00:56:51.170
dat dan zien in combinatie met andere gegevenen. Bijvoorbeeld hoeveel geld er uitgegeven wordt in

533
00:56:51.170 --> 00:56:56.230
de App Store. Dat je al voor spelers die skins kunnen kopen of dat soort dingen. Die voegen

534
00:56:56.230 --> 00:57:04.710
dat samen met andere KPIs of metrics die heel belangrijk zijn voor de monetisation van je

535
00:57:04.710 --> 00:57:10.290
game zeg maar. Dus op dat gebied is Backtrace eigenlijk net wat anders. Het zorgt ervoor voor

536
00:57:10.290 --> 00:57:15.770
kleine studio's meer dat je observability daar direct hebt. Maar zodra je groter wordt

537
00:57:15.770 --> 00:57:21.570
gebruik je het inderdaad meer als een expert systeem die data genereert over foutmeldingen,

538
00:57:21.630 --> 00:57:27.610
crashes en dat soort dingen. Die importeer je dan weer in een groter overzicht. Dus

539
00:57:27.610 --> 00:57:33.310
een klein beetje anders. We zijn een beetje meer downstream op dat gebied in vergelijking met

540
00:57:34.070 --> 00:57:41.720
dat. Ik denk dat dat ook komt omdat bij jullie de crashes natuurlijk volledig client-side

541
00:57:42.840 --> 00:57:52.500
gebeuren. Dat is het grote verschil met de omgeving waar ik vandaan kom. De omgeving waar ik

542
00:57:52.500 --> 00:57:57.980
gezeten heb, daar heb je een centrale plek waar de applicatie draait. En dan kun je veel meer van

543
00:57:57.980 --> 00:58:05.120
dat soort verwerking aan de server gaan doen. En servers zijn vaak ook wat stabieler dan

544
00:58:05.120 --> 00:58:08.420
clients. Met name als je het over spellen hebt zeg maar. Je weet van spellen dat...

545
00:58:09.920 --> 00:58:16.400
Veel minder verschillende configuraties natuurlijk. Heel veel interessante discussies of conversaties

546
00:58:16.400 --> 00:58:22.160
die ik heb die gaat juist inderdaad om... Er zijn net weer hele rits aan rapporten

547
00:58:22.160 --> 00:58:27.360
vrijgegeven zeg maar. Zijn bedrijven die dat doen die laten zien wat er in 2021 in de

548
00:58:27.360 --> 00:58:31.820
mobiele markt gebeurd is. En wat je ziet is dat het overgrote hoeveelheid geld verdiend

549
00:58:31.820 --> 00:58:38.920
wordt met de spellen. Volgens mij is het 60% van de revenue. Al was het misschien voor

550
00:58:38.920 --> 00:58:44.520
2021 anders. Maar het belangrijkste is dat de grootste hoeveelheid van de spellen waar

551
00:58:44.520 --> 00:58:50.620
veel geld aan verdient wordt, daarom aankopen in het spel, maar ook via advertenties,

552
00:58:51.040 --> 00:58:56.180
zijn van die casual games zeg maar. Hele simpele spellen die je moeder waarschijnlijk

553
00:58:56.180 --> 00:59:04.040
speelt op een Android tablet die in de keuken laan ligt, die nog in de tweede wereldoorlog

554
00:59:04.040 --> 00:59:11.900
gebruikt is zeg maar. En dan is dat op zich heel grappig dat zo'n apparaat als je voor een bank

555
00:59:11.900 --> 00:59:17.620
werkt of zo zegt een bank nou ja, is prima dat jij een 32-bit Android device in de lab

556
00:59:17.620 --> 00:59:21.700
zit, maar ga maar niet proberen daar op de internet te bankieren. Gebruik de website

557
00:59:21.700 --> 00:59:28.240
maar. En voor game studios is het juist wel belangrijk om op die hele oude devices te kunnen

558
00:59:28.240 --> 00:59:32.780
draaien, tenminste is een business case voor. Dus op het moment dat je genoeg mensen hebt die

559
00:59:32.780 --> 00:59:37.880
zo'n oude ding hebben liggen en daar veel spellen op spelen, simpele spellen, dan kan je dan

560
00:59:37.880 --> 00:59:41.780
nog steeds inderdaad heel veel geld mee verdienen. En daardoor wordt het ook extra

561
00:59:41.780 --> 00:59:49.000
belangrijk om ook de informatie te kunnen verzamelen van die super oude apparaten. Dat

562
00:59:49.000 --> 00:59:54.020
is heel vaak in de server-site-wereld minder van toepassingen. Grappig is dat backtrace van

563
00:59:54.020 --> 00:59:59.720
origine uit de server-site-wereld komt. Zo deden bedrijven gestart was het eigenlijk,

564
01:00:00.620 --> 01:00:05.400
de eerste backtrace was command-line interface voor Linux, om op het moment dat iets core

565
01:00:05.400 --> 01:00:10.220
dumpte, dat je dan heel snel die core dump goed kan debuggen, zeg maar. We hebben veel

566
01:00:10.220 --> 01:00:16.500
ervaring met dat soort bedrijven ook en heel erg gestandardiseerde hardware. Backtrace draait

567
01:00:16.500 --> 01:00:23.940
ook op Comcast, de set-top boxes hier in Amerika. Ik weet niet of wie dat equivalent in Nederland

568
01:00:23.940 --> 01:00:28.900
noemt, maar dat ding dat je van je kabelmaatschappij hebt staan, waar je je tv signaal door binnen

569
01:00:28.900 --> 01:00:43.820
krijgt. Dus ja, daar zijn wat verschillen, zeg maar, in hoe je dat soort gegevens nog

570
01:00:44.560 --> 01:00:49.200
probeert te krijgen. En bepaalde dingen werken dan ook natuurlijk. Op een gegeven moment wordt het

571
01:00:49.200 --> 01:00:54.220
te oud en dan gaat het gewoon een stuk. Ja, dat snap ik. Ja, dat is trouwens ook een

572
01:00:54.220 --> 01:01:01.380
vraag van Wouter, want het gaat inderdaad om databehoefte rondom observability. En nu hebben

573
01:01:01.380 --> 01:01:06.900
we vanuit, noem het maar even de gaming-industrie en we hebben het net eventjes over de tv-industrie

574
01:01:06.900 --> 01:01:13.740
gehad, maar natuurlijk ook in de context van NS. Wat zijn nou echt cruciale

575
01:01:13.740 --> 01:01:19.820
gegevens die je zou moeten gaan observeren, of hoe je het ook wilt noemen. Als je gaat

576
01:01:19.820 --> 01:01:25.500
starten met observability in de applicatie lifecycle, hebben jullie gemene delen daarin

577
01:01:25.500 --> 01:01:30.000
of of is het echt heel specifiek op het domein waar je applicaties in gaat bouwen?

578
01:01:34.050 --> 01:01:40.710
Ik denk dat het heel domeinspecifiek is. Er zijn keypunten. Eigenlijk het eerste dat in

579
01:01:40.710 --> 01:01:45.690
het hoofd te binnen schoot was error rate en dingen als bijvoorbeeld de risk-omstein

580
01:01:46.490 --> 01:01:54.210
aan de hand van je traces. Maar ik kan me ook voorstellen dat er omgevingen zijn waarin

581
01:01:55.790 --> 01:02:03.070
een bepaalde maat van betrouwbaarheid belangrijker is dan snelheid. Dus eigenlijk ja,

582
01:02:04.370 --> 01:02:07.910
het is heel moeilijk te zeggen. Het belangrijkste is om gewoon het gesprek aan te gaan met

583
01:02:07.910 --> 01:02:16.650
stakeholders en samen tot een set aan metrieken te komen die werkt voor jullie en die het geluk

584
01:02:16.650 --> 01:02:23.110
van je klant mee kunnen maken. Ja precies. Servability voor pacemakers is heel anders

585
01:02:23.110 --> 01:02:31.430
dan de observability voor joules op je iPhone zeg maar. Ja precies, joules op je iPhone ja.

586
01:02:31.430 --> 01:02:40.150
Alhoewel zou het een relatie kunnen zijn als je slecht, sorry flauwe grap. Maar inderdaad

587
01:02:40.150 --> 01:02:46.550
het is inderdaad weer zo'n independent situatie. Maar wel fijn dat je, Ja Jeroen,

588
01:02:46.630 --> 01:02:50.050
dat je toch even de twee belangrijkste misschien even noemt. Die error rate en

589
01:02:50.690 --> 01:02:58.930
wat was die andere? Sorry. Response time. Ja ja ja. Ik zou er nog eentje aan toe

590
01:02:58.930 --> 01:03:04.330
voegen. Heartbeats denk ik. Ja dat is een beetje even te maken met response time ook.

591
01:03:04.670 --> 01:03:10.310
Omdat de heartbeats een simpele manier is om een indicatie te krijgen van dat iets,

592
01:03:10.570 --> 01:03:17.790
het is belangrijke informatie om te hebben als je daar geautomatiseerde stroom van data bij

593
01:03:17.790 --> 01:03:23.850
hebt. En uiteindelijk waar ik het over had, die crash free gegevens. Dat zijn uiteindelijk,

594
01:03:24.110 --> 01:03:27.990
je kan je kan het ook als heartbeats zien zeg maar. Als een speler een spel aan het

595
01:03:27.990 --> 01:03:34.550
spelen is. Het is instelbaar natuurlijk, maar elke half uur vocht er een heartbeat zeg maar.

596
01:03:35.010 --> 01:03:42.230
Het heeft hartslag van een super olifant ofzo, niet veel per seconde zeg maar. Dat is ook

597
01:03:42.230 --> 01:03:45.550
een belangrijke. En het is een soort van een makkelijke zeg maar. Heartbeats zijn niet

598
01:03:45.550 --> 01:03:49.690
moeilijk zeg maar. Het is heel erg, als je eerst een keertje heartbeat misloopt. Weet

599
01:03:49.690 --> 01:03:53.850
je al, er zit een van de kink in de kabel, het komt niet binnen. Nee niks aan het handje.

600
01:03:53.850 --> 01:03:59.170
Dus dat is ook eentje die makkelijk te bereiken is zeg maar.

601
01:03:59.970 --> 01:04:09.410
Ja, nee inderdaad. Ik kan me ook wel voorstellen als je die, noem het maar even die data opslag

602
01:04:09.410 --> 01:04:15.770
en stromen, dat je die op een gegeven moment natuurlijk in je applicatielandschap gaat of

603
01:04:15.770 --> 01:04:23.470
in je architectuur gaat organiseren. Hoe gaat het dan verder in z'n werk? Kunnen jullie daar

604
01:04:23.470 --> 01:04:32.650
iets over vertellen? Hoe je dan dat aanpakt? Hoe leg je die plannen zeg maar klaar om dat

605
01:04:32.650 --> 01:04:35.570
te gaan doen? Hebben jullie daar een concreet voorbeeld van?

606
01:04:36.530 --> 01:04:40.690
Ik heb op zich wel een concreet voorbeeld. Ik denk dat dat ook weer heel domeinspecifiek

607
01:04:40.690 --> 01:04:45.810
is. Denk ik. Vind je dat ook Jeroen, domeinspecifiek of niet?

608
01:04:48.230 --> 01:04:53.550
Ik heb daar misschien een twijfel over, maar ik ben heel benieuwd naar je antwoord.

609
01:04:53.830 --> 01:04:54.790
Dan ga ik je daarna afvragen.

610
01:04:54.830 --> 01:04:55.810
Ja, eindelijk.

611
01:05:01.410 --> 01:05:09.290
Even kijken. Wat mij opvalt is dat, en dat is gerelateerd aan dingen die ik daadwerkelijk

612
01:05:09.290 --> 01:05:13.410
zie gebeuren in de organisatie waarvoor ik werk en ook de klanten waar ik mee bezig ben,

613
01:05:13.410 --> 01:05:20.390
is dat je nog steeds wel een draaiboek nodig hebt. Als je bijvoorbeeld ziet, gebruik welke

614
01:05:20.390 --> 01:05:27.170
voorbeeld je wil, maar dat Fortnite-spelers geen skins meer aan het kopen zijn en dat

615
01:05:27.170 --> 01:05:31.390
is waar je het voornaamste geld mee verdient, dan moet je ook nog steeds dan wel weten

616
01:05:31.390 --> 01:05:40.990
wat je daarmee doet. Het inrichten van draaiboeken, hoe ga je met de verschillende

617
01:05:40.990 --> 01:05:46.710
situaties om? Dat is heel belangrijk, want je hebt net heel veel werk gestoken in het

618
01:05:47.030 --> 01:05:54.790
onderkennen van welke situaties zijn belangrijk voor onze business. En dan een goed proces

619
01:05:54.790 --> 01:05:58.910
te hebben om wat te doen met het feit dat zo een van die metrieken op zijn gat valt,

620
01:05:59.810 --> 01:06:05.250
is enorm belangrijk. Even iedere ochtend op je dashboard kijken, dat werkt niet. Dat

621
01:06:05.250 --> 01:06:10.430
werkt voor je Jenkins CI-Jaws, werkt dat op zich prima, ook niet geweldig, maar het is

622
01:06:10.430 --> 01:06:17.070
dat het helemaal ingebakken moet zitten in de manier dat je werkt. Het is ingericht op zo'n

623
01:06:17.070 --> 01:06:21.030
manier dat als er echt iets aan de hand is dat het gepusht wordt, dat je dus inderdaad

624
01:06:21.030 --> 01:06:26.830
alerting hebt staan, dat je weet dat je in zo'n situatie waar je mee om kan gaan, dat je

625
01:06:26.830 --> 01:06:35.010
iemand oncall hebt staan, dat die persoon weet wat zijn plichten en rechten zijn. Wat natuurlijk

626
01:06:35.010 --> 01:06:42.270
een beetje domeinspecifiek is. Je kan niet generiek zeggen wat er gebeurt in zo'n situatie,

627
01:06:42.270 --> 01:06:48.650
dat heeft heel erg met je applicatielandschap te maken. Dat zijn de gedachten die in mij opkomen.

628
01:06:51.310 --> 01:06:57.530
Jeroen? Kan ik me goed invinden. Ja, nee, kan ik me goed invinden. Ik probeerde echt

629
01:06:57.530 --> 01:07:03.090
eventjes een kleine wel te maken, maar ik ben het weer met je eens. Ik wil nog wel

630
01:07:03.090 --> 01:07:10.390
iets toevoegen. Ik zal ook kijken hoe je observability data op een zinvolle manier

631
01:07:10.390 --> 01:07:20.530
kan gebruiken in relatie tot je deployments. Kijk, wat je vaak ziet is dat, en nu dat steeds

632
01:07:20.530 --> 01:07:29.770
meer bedrijven microservices gaan implementeren en je eigenlijk ook steeds meer druk hebt op

633
01:07:30.440 --> 01:07:36.850
teams om snel te presteren, dat er steeds vaker ge-deployed gaat worden. En ik denk dat het ook

634
01:07:36.850 --> 01:07:47.390
heel goed is om aan de ene kant te kunnen zien hoe presteert de ene versie versus de andere

635
01:07:47.390 --> 01:07:58.070
versie. Dus wat ik eigenlijk altijd graag zie is als teams in de grafieken met bijvoorbeeld

636
01:07:58.070 --> 01:08:04.950
een error rate ook een marker hebben van oké, dit is het moment dat we nieuwe deployment hebben

637
01:08:04.950 --> 01:08:11.950
gedaan. Zodat je in één keer kan zien van de versie van vandaag die doet het niet goed in

638
01:08:11.950 --> 01:08:20.410
vergelijking met de versie van gisteren. En wat ik helemaal mooi vind is als je observability

639
01:08:20.410 --> 01:08:27.950
data dan ook nog een plek probeert te geven in hbtests of misschien canary deployments. Dus

640
01:08:27.950 --> 01:08:38.810
dat je eerst een kleine groep gebruikers blootstelt aan een nieuwe versie van je tool en

641
01:08:39.350 --> 01:08:45.450
sorry van je product en op het moment dat de error rate niet significant hoger is dat je

642
01:08:45.450 --> 01:08:56.290
langzaam steeds meer gebruikers daaraan gaat toevoeren. Ja dat is de ultieme droom situatie. Ik zie

643
01:08:56.290 --> 01:09:06.810
het niet vaak gebeuren helaas, maar dat is als ik een pen en een papier krijg om een

644
01:09:06.810 --> 01:09:11.990
implementatie van een juiste observability strategie te bedenken dan zou dit zijn hoe ik

645
01:09:13.330 --> 01:09:18.350
En bij wie zou je denk ik, ja dat is even een vraag die bij mij bovenkwam. Ik kan me ook

646
01:09:18.350 --> 01:09:24.210
voorstellen dat als jij als developer in zo'n team die heeft dat gebouwd en je moet ook

647
01:09:24.210 --> 01:09:30.130
nog daarnaast nog de features gaan opbouwen en data opslag gaan organiseren en dat soort

648
01:09:30.130 --> 01:09:41.610
dingen. Ja en dan ga je gauw weer door naar je volgende story van je backlog en dan blijf je

649
01:09:41.610 --> 01:09:48.150
meest interessante personen om dit te blijven volgen zeg maar want ja observability zegt al in

650
01:09:48.150 --> 01:09:57.110
de naam dat je het op een gegeven moment moet gaan observer. Is daar een rol voor ik als

651
01:09:57.110 --> 01:10:03.430
developer zeg maar? Ik denk eigenlijk dat dat een verantwoordelijkheid zou moeten zijn van het

652
01:10:03.430 --> 01:10:10.150
hele team en je zou bijvoorbeeld ook kunnen opnemen in je definition of done,

653
01:10:10.150 --> 01:10:19.640
definition of ready dat features die je zichtbaarheid verkleinen niet live mogen gaan.

654
01:10:20.350 --> 01:10:28.230
Dus dat je eigenlijk vastlegt in je team afspraak dat observability gewoon een

655
01:10:28.230 --> 01:10:37.730
belangrijke prioriteit. En ja dan kan je ook met product owners of met business mensen

656
01:10:37.730 --> 01:10:45.330
aan de slag gaan en zeggen van we gaan nu ontwikkelen ten koste van onze kwaliteit. Dus

657
01:10:45.330 --> 01:10:53.310
misschien dat we eventjes iets rustiger aan moeten doen met nieuwe features. Ja dat lijkt me wel

658
01:10:53.310 --> 01:10:58.870
een lastige discussie want je moet het toch maar goed het leuke wel weer van observability is

659
01:10:58.870 --> 01:11:05.170
is dat je die besluiten neemt op basis van data want anders doe je alles op onderbuikgevoel.

660
01:11:07.950 --> 01:11:14.970
Ja en een vraag ook die ik hier zie. Heb je er ook ervaring mee dat je observability als

661
01:11:14.970 --> 01:11:21.930
het ware ook als alerts zou kunnen inbouwen? Kijk met monitoring en ja dat daar is het een

662
01:11:21.930 --> 01:11:26.350
beetje standaard. Dan kan je volgens mij ook wel, nu moet ik even alerts zo instellen,

663
01:11:27.030 --> 01:11:31.310
maar hebben observability tools daar ook ideeën bij?

664
01:11:32.150 --> 01:11:41.090
Ik denk het wel. Alerts is een van de dingen die belangrijk is in backtrace implementaties

665
01:11:41.090 --> 01:11:48.050
zeg maar. Waar we ook veel flexibiliteit moeten toelaten. Dus dat je dingen kan instellen als

666
01:11:48.050 --> 01:11:55.170
ik hey ik wil alleen een message op Slack krijgen of een smsje of whatever. Als ik een

667
01:11:55.170 --> 01:12:06.030
outtrap die meer dan duizend keer plaatsvindt en meer dan 150 unieke gebruikers beïnvloed die

668
01:12:07.090 --> 01:12:12.770
meer dan 10% van de totale sessies representeert. Dat soort dingen. Dingen die echt overdreven,

669
01:12:13.010 --> 01:12:22.250
complex worden. Maar je ziet dat die flexibiliteit wel nodig is voor de individuele teams.

670
01:12:22.250 --> 01:12:26.430
Oftewel het wordt heel erg domeinspecifiek en afhankelijk van hoe jij je geld verdient

671
01:12:26.430 --> 01:12:34.790
en wat belangrijk is hoe je dingen wil oplossen. Dus voor alles dat via backtrace

672
01:12:34.790 --> 01:12:42.490
gedaan wordt is dat iets dat redelijk essentieel is alerting. Al voelt het tegelijkertijd een

673
01:12:42.490 --> 01:12:48.030
beetje old school zeg maar. Alerting is hetgene wat we al sinds 1970 doen als het gaat om

674
01:12:51.670 --> 01:12:56.730
het. Dus het is echt een soort van niet hip en cool. Ik hoop dat Jeroen het echt vet

675
01:12:56.730 --> 01:13:05.950
met me oneens gaat zijn en mijn opa noemt. Dat sowieso. Nou ja, ik ben het gedeeltelijk

676
01:13:05.950 --> 01:13:12.630
met je eens. Kijk, wat ik heel erg mooi vind is dat je nu best wel wat machine

677
01:13:12.630 --> 01:13:20.150
learning ook nog kan loslaten op je observability data en aan de hand daarvan

678
01:13:20.930 --> 01:13:27.350
slimmere alerting kan maken. Maar ja, ook dat heeft een grens. Ik werkte een paar

679
01:13:27.350 --> 01:13:38.350
jaar geleden voor een organisatie. Wij leefden een online dienst en dat werd eigenlijk door de

680
01:13:39.410 --> 01:13:48.510
bepaalde tijden gebruikt. En we hadden onze observability stack zo ingericht dat als er

681
01:13:48.510 --> 01:13:56.410
in een keer een drop in het aantal sessies kwam, dan kreeg iemand een cijntje. Want dan

682
01:13:56.410 --> 01:14:01.450
wisten we van oké, of de website is super lelijk geworden en mensen willen het niet

683
01:14:01.450 --> 01:14:07.970
meer gebruiken. Of er is een systeem kapot gegaan waardoor mensen geen toegang meer

684
01:14:07.970 --> 01:14:13.590
hebben tot ons systeem. Alleen toen was het een volgens mij kerst of in ieder geval een

685
01:14:13.590 --> 01:14:22.530
bepaalde feestdag die viel door de week. En niemand gebruikte onze tool. En toen zijn

686
01:14:22.530 --> 01:14:32.590
er dus mensen voor niks wakker gebeld. Dus op zich, ik denk dat alerting zal altijd

687
01:14:33.110 --> 01:14:36.850
blijven. We moeten er wel iets slimmers mee doen, maar de oplossing die is nog

688
01:14:36.850 --> 01:14:44.990
niet in zicht. Ik denk dat we wel afstappen van het type alert van eh, mijn harde schijf is vol.

689
01:14:47.290 --> 01:14:54.250
Ja, precies. Ja, klopt. Ik kan een beetje context geven. Ook een rot om de volgende

690
01:14:54.250 --> 01:14:58.770
vraag die Wouter stelde. Die vind ik wel interessant. Die stelt de vraag,

691
01:15:01.830 --> 01:15:06.830
preventiemogelijkheden. Oké, cool. Ja, geen idee. Maar als ik hem dan zou mogen invullen,

692
01:15:13.070 --> 01:15:25.130
ik werk op dit moment bij Agolt en ja, daar hebben we ook de topic observability staan.

693
01:15:25.410 --> 01:15:29.690
En dan proberen we ook na te denken over de visie van wat we ermee willen bereiken en dat

694
01:15:29.690 --> 01:15:36.830
soort dingen meer. En ook precies wat ook denk ik net hebben besproken van hoe kunnen we het

695
01:15:36.830 --> 01:15:44.910
willen ermee bereiken. En een van de dingen die ik hoor constant is zelfhieling. Ja,

696
01:15:45.090 --> 01:15:50.350
dus dat zijn een van onze speerpunten die we graag binnen Agolt willen gaan verbeteren.

697
01:15:50.630 --> 01:15:56.550
Dus inderdaad, even de clichédingen zijn dus niet meer alert van dat je harde schijf leeg

698
01:15:56.550 --> 01:16:00.590
is, maar dat die inderdaad automatisch een gebruikersdatum gaat wegplempen.

699
01:16:00.930 --> 01:16:04.230
Oh, ja, zoiets. Ja, precies. Ja, opschoon of weet ik veel wat.

700
01:16:04.550 --> 01:16:06.750
Ja, het is een grapje dat ik maak. Maar tegelijkertijd is dat

701
01:16:06.750 --> 01:16:13.690
heel erg actueel is voor ons op het moment. Wat er bij Crash Reporting meekomt is dat soms

702
01:16:13.690 --> 01:16:19.030
die rapporten echt supergroot zijn, met name van Playstation komen ofzo. En dat in bepaalde

703
01:16:19.030 --> 01:16:26.810
gevallen wij inderdaad zien dat er terabytes per uur bij klanten bijkomen. En ik had het

704
01:16:26.810 --> 01:16:36.730
er net over draaiboeken en observability en weten wat je moet doen. Het is een goed

705
01:16:37.510 --> 01:16:43.170
grote harde schijven in, zeg maar. En dat gaat natuurlijk allemaal via AWS tegenwoordig. Of

706
01:16:43.170 --> 01:16:47.990
letterlijk inderdaad zet je wat je bij ons kan aanzetten is sampling. Wat betekent dat wij

707
01:16:47.990 --> 01:16:52.750
wel de crash gaan analyseren. En als we dan zeggen van is een crash die we al vaker gezien

708
01:16:52.750 --> 01:16:58.810
hebben, dan pleuren we ze allemaal weg en houden er één per half uur of het kan je instellen,

709
01:16:58.810 --> 01:17:02.870
natuurlijk. Maar dat zijn wel van die voorbeelden daarvan, van de beslissingen

710
01:17:02.870 --> 01:17:12.410
die je dan moet maken. Gaat dat niet heel erg ten koste van de nauwkeurigheid van de

711
01:17:13.510 --> 01:17:20.930
verzamelde data als je dat doet? Het valt mee. Dat komt omdat het weggooien plaats

712
01:17:20.930 --> 01:17:28.710
vindt nadat het object het rapport verwerkt is. En op het moment dat wij een object verwerken,

713
01:17:28.710 --> 01:17:34.830
dan houden we de statistieken ervan bij. Maar gooi je het grote object weg,

714
01:17:34.870 --> 01:17:41.530
dus we weten bijvoorbeeld nog wat de call stack was, wat de process age was van niets. Noem

715
01:17:41.530 --> 01:17:47.970
nog tien andere dingen die belangrijk zijn en dat de fout plaatsgevonden heeft en wanneer

716
01:17:47.970 --> 01:17:51.950
en dat soort dingen. Maar alle details, dus de core dump, de onderliggende core dump,

717
01:17:53.050 --> 01:17:57.410
dat wordt opgeschoond. Dus je hebt alle statistieken nog wel, maar niet de

718
01:17:57.410 --> 01:18:02.610
detail informatie. De detail informatie heb je er vaak maar één van nodig. Dus als er een

719
01:18:02.610 --> 01:18:07.230
fout plaatsvindt die meerdere gebruikers hebben, je hebt maar één core dump eigenlijk nodig.

720
01:18:08.630 --> 01:18:15.350
Dat is een beetje wat te achterzetten. Ja precies. Dit heeft dan ook weer te maken

721
01:18:15.350 --> 01:18:20.970
met dat domein specifiek. Ik kan me voorstellen dat ze dat bij de NS niet zo snel zullen

722
01:18:20.970 --> 01:18:32.410
doen. Dat ze waarschijnlijk achteraf ook nog wel veel willen leren. Ja, dat is weer veel

723
01:18:32.410 --> 01:18:41.850
server-side en ik denk dat wij heel veel gekke corner cases hebben omdat dat IT-landschap

724
01:18:41.850 --> 01:18:50.450
gewoon zo groot is. Dus ja, wij zullen denk ik, als wij een tool als Backtrace zouden

725
01:18:50.450 --> 01:18:56.130
implementeren, dan zouden wij geneigd zijn om best wel veel op te slaan, denk ik. Maar als een

726
01:18:56.130 --> 01:19:00.810
organisatie als NS dat zou doen, dan zouden ze waarschijnlijk ook een on-prem variant daarvan

727
01:19:03.030 --> 01:19:07.790
aanschaffen. Want dan beslist je natuurlijk zelf gewoon over je storage en dat soort dingen. Dat

728
01:19:07.790 --> 01:19:12.470
is vaak de onderliggende reden deze discussies. Het zijn dan niet de grootste studio's en

729
01:19:12.470 --> 01:19:17.510
kleine studio's die staan op een gedeelde omgeving, zeg maar. Voor de grootste studio's

730
01:19:17.510 --> 01:19:21.890
hebben we een eigen omgeving en als de schijf bijna vol is, dan prikken we er een

731
01:19:21.890 --> 01:19:27.510
nieuw in en dan gaat de rekening naar de studio. Dat boeit ons relatief weinig, zeg maar.

732
01:19:28.870 --> 01:19:33.710
Ja, storage kost ook niets meer tegenwoordig. Dan zullen ze niet wakker van liggen als ze die

733
01:19:33.710 --> 01:19:37.050
factuur hebben. Nee, inderdaad. Met name omdat we daar onze marge niet opmaken,

734
01:19:37.210 --> 01:19:43.370
zeg maar. Dat is gewoon doorschuiven wat AWS ons rekent naar de klant, zeg maar. Maar ja,

735
01:19:43.370 --> 01:19:48.350
het kan heel snel gaan op het moment dat je het te maken hebt met dat het letterlijk een

736
01:19:48.350 --> 01:19:54.070
terabyte per uur aangroeit, zeg maar. Dat zijn van wel van die momenten dat je een strategie

737
01:19:54.070 --> 01:19:58.770
wil hebben. Ja. Ja, want kijk, we hebben het nu eventjes over een beetje de triviale

738
01:19:58.770 --> 01:20:04.490
dingen met de geheugen en de harde schijfruimte en dat soort dingen. Maar ik zit ook even te

739
01:20:04.490 --> 01:20:11.790
denken, Jeroen zei het net ook al, dat AB-test. Kijk, ja daar, dan wil je wel,

740
01:20:11.790 --> 01:20:17.130
misschien wel dat het systeem die je dan ontwikkeld hebt, dat die automatisch dan een besluit neemt.

741
01:20:18.170 --> 01:20:23.810
Ja, van dat inderdaad men, volgens mij zei Jeroen het, van als een website echt onwijs

742
01:20:23.810 --> 01:20:28.210
lelijk gevonden wordt en we zien dat op een of andere manier. Ik weet even niet hoe je

743
01:20:28.210 --> 01:20:32.670
dat kan bepalen, maar goed, stel je voor dat we iets hebben bedacht dat dat kan bepalen. Ja,

744
01:20:32.670 --> 01:20:37.730
dat hij dan ook uit zichzelf gewoon een besluit durft te nemen. Ja, dat zijn wel

745
01:20:37.730 --> 01:20:43.690
interessante dingen joh, hé. Ja, dat komt echt op. Ja, dat is LaunchDarkly en dat soort software,

746
01:20:45.410 --> 01:20:53.370
dus Canary Release software. Oh, dat bedoel je, ja. Ja, ja en dan kan je zeggen dat je

747
01:20:53.370 --> 01:21:00.150
misschien als je dan zo'n nieuwe versie even live zet in een selecte groep gebruikers,

748
01:21:00.630 --> 01:21:07.650
dat je dan je sampling wel weer gewoon maximaal zet. Ja, want die data die is

749
01:21:07.650 --> 01:21:15.390
super waardevoert. Ja, klopt. Ja, dat is een heel goed punt inderdaad. Op dat soort momenten heb

750
01:21:15.390 --> 01:21:22.510
je die resolutie juist wel nodig. En dat meer dynamisch laten zijn is iets, die discussie,

751
01:21:22.810 --> 01:21:32.910
die vindt wel vaker plaats, zeg maar, om op het AB-dinges, zeg maar, in te pluggen. Het is

752
01:21:32.910 --> 01:21:39.390
inderdaad iets wat voor mobiele apps is het met name heel erg belangrijk. Dus de game klanten die

753
01:21:39.390 --> 01:21:44.810
we hebben die naar Playstation en dat soort dingen daar inspelen, naar Deploy of Selfs,

754
01:21:44.970 --> 01:21:54.270
Steam en PC platforms enzo. Daar zie je net wat minder versies tegelijkertijd. Maar juist

755
01:21:54.270 --> 01:21:58.550
omdat er op mobiel veel van die casual games zijn, waar je mensen gewoon eigenlijk niet

756
01:21:58.550 --> 01:22:04.250
veel lastig vallen met, hey, je moet updaten. Kijk, als je wel wijs fan van een spel bent en je

757
01:22:04.250 --> 01:22:09.890
speelt dat uren per dag, ja, dan vind ik het prima om daar tijd en effort in te steken om het

758
01:22:09.890 --> 01:22:14.810
te upgraden. Je ziet dat gamers over het algemeen veel vergevender zijn op dat gebied. Maar voor

759
01:22:14.810 --> 01:22:21.730
casual games heb je dat eigenlijk juist niet. Dus dan heel belangrijk onderdeel van wat wij

760
01:22:21.730 --> 01:22:28.750
daar laten zien en wat een selling point is, zeg maar, is dat we kunnen zien hoeveel van je

761
01:22:29.750 --> 01:22:36.870
gebruikers op welke versie zit, zeg maar, user adoption. En dat dan inderdaad ook laten

762
01:22:36.870 --> 01:22:41.270
zien in een time series. Dus het is een beetje poor man's Prometheus. Je kan het veel mooier

763
01:22:41.270 --> 01:22:46.170
doen natuurlijk in een tool die daar specifiek voor gemaakt is. Maar je ziet het als gewoon

764
01:22:46.170 --> 01:22:50.430
kleine dashboordjes die je het allerbelangrijkste laten zien. Dat is een soort van de trend over

765
01:22:51.290 --> 01:23:03.130
user adoptions en je error rate, zeg maar. Nou jongens, we zijn al bijna anderhalf uur bezig met

766
01:23:03.130 --> 01:23:14.050
dit onderwerp. Je bent nog niet moe? Je kan gewoon doorgaan. Oké, dat vind ik wel een goede

767
01:23:14.050 --> 01:23:19.330
opmerking. Wat missen we nog? Wat zou je nog willen vertellen aan de luisteraars van,

768
01:23:19.330 --> 01:23:29.670
joh vergeet dit vooral niet als jullie uitgeluisterd zijn? Ja, als ik de luisteraars een tip mag geven,

769
01:23:30.650 --> 01:23:39.790
probeer die zichtbaarheid over je hele stack te creëren. Dus niet alleen wat er op de

770
01:23:39.790 --> 01:23:48.670
server gebeurt. Hoe snel je transacties daar gaan. Maar kijk ook bijvoorbeeld naar zaken die in de

771
01:23:48.670 --> 01:23:56.850
browser gebeuren. Dus als je een hele zware ja-gaanscript hebt die op bepaalde soorten

772
01:23:56.850 --> 01:24:02.850
browsers gewoon langzaam gaat, dan wil je dat weten want je wil daar gerichte optimalisaties op

773
01:24:02.850 --> 01:24:07.390
kunnen doen. Ik denk dat het zelfde ook aan de hand kan zijn op een bepaalde mobiele

774
01:24:07.390 --> 01:24:17.490
platform. Daar heeft Vincent misschien nog wel een goede idee over. Zichtbaarheid van je folder stack,

775
01:24:18.690 --> 01:24:26.390
dat is het belangrijkste. Want uiteindelijk je klant zijn geluk wordt bepaald door de zwarte

776
01:24:26.390 --> 01:24:37.190
schakel. Dus dat zou ik de luisteraar weer meegeven. Goede tip, die gaat in de boeken.

777
01:24:37.830 --> 01:24:44.830
Jij Vincent? Ik heb het idee dat ik al kan aansluiten op dat verhaal, het monitor van je hele

778
01:24:44.830 --> 01:24:50.690
stack en niet alleen die je website ook in de gaten houdt, dat komt inderdaad veel meer dichter in

779
01:24:50.690 --> 01:24:59.110
de richting waar Blivereak voor werkt natuurlijk heel erg mee bezig is. En ik zou daar aan toe

780
01:24:59.110 --> 01:25:06.370
willen voegen dat we ook vaak zien dat als je een spel hebt, als je denkt aan gamen dan

781
01:25:06.370 --> 01:25:13.130
denk je over het algemeen aan clientside dingen. Je hebt iets heel zwaars draaien op je laptop of

782
01:25:13.130 --> 01:25:18.230
op je gaming pc die vooral heel veel grafisch werk doet. Ik denk niet zo heel erg na over het

783
01:25:18.230 --> 01:25:25.070
server-side component. Maar vaak heb je een multiplayer server of iets dergelijks en toen

784
01:25:25.070 --> 01:25:31.350
ik begon in deze industrie te werken, vond ik het heel interessant om te achter te komen dat

785
01:25:31.350 --> 01:25:36.190
voor dat soort dingen, gameservers en dat soort dingen, dat Amazon daar ook gewoon standaard

786
01:25:36.190 --> 01:25:41.190
diensten voor heeft zeg maar. Wil je een chat-service? Wil je een multiplayer-service? Ah ja gewoon

787
01:25:41.190 --> 01:25:46.190
next next finish heb je er eentje. Standaard plug-in in je Unity game engine, kan je het

788
01:25:46.190 --> 01:25:55.450
gebruiken. Maar die dingen, daar geldt voor dat ze natuurlijk over het algemeen stabieler zijn

789
01:25:55.450 --> 01:25:59.070
dan spelers. Spelers zijn instabiel om dit natuurlijk gedeeltelijk zijn te spelen, dus als

790
01:25:59.070 --> 01:26:06.450
het eruit klapt. Het is niet pacemaker software of iets dergelijks ook omdat dat grafisch heel

791
01:26:06.450 --> 01:26:14.890
veel dingen doet. Maar ervaring is ook dat voor bepaalde game engines en Unreal is een goed

792
01:26:14.890 --> 01:26:21.810
voorbeeld daarvan. Unreal Engine is versie vijf van gereleased, super gaave voortgangen die ze daar

793
01:26:21.810 --> 01:26:27.590
geboekt hebben. Wow ja ik heb het gezien in de YouTube filmpjes. Ja het is super super mooi

794
01:26:27.590 --> 01:26:32.990
Het is ook nog een hele tunnel waar je in zou kunnen gaan. De verschillende manieren dat

795
01:26:32.990 --> 01:26:42.870
game engines werken. Ja andere onderwerp, andere aflevering. Maar een van de dingen daar is dat

796
01:26:42.870 --> 01:26:47.530
je daar ook mee moet pakken wat je gameservers doen. Dus ondanks dat je in een of ander

797
01:26:47.530 --> 01:26:53.710
standaard product van Amazon binnen sleept of je eigen ding. Of dus daarom begon ik te

798
01:26:53.710 --> 01:26:59.150
praten over Unreal. Unreal komt zeg maar met een client side component en ook een server

799
01:26:59.150 --> 01:27:02.470
side component. Dat is eigenlijk een soort van een klein beetje raar. Maar je draait dezelfde game

800
01:27:02.470 --> 01:27:09.450
engine ook server side. Wat betekent dat dat ding boven gemiddeld crasht. Vergelijking

801
01:27:09.450 --> 01:27:13.950
met andere software. Het is uiteindelijk een game engine is heel betrouwbaar. Maar in

802
01:27:13.950 --> 01:27:18.650
vergelijking met enterprise software toch wat minder zeg maar. Dus daar dan ook mee

803
01:27:18.650 --> 01:27:23.690
pakken dat je de server side die dingen ook captured. En dat kan nou ook wat ingewikkelder

804
01:27:23.690 --> 01:27:29.890
zijn omdat dat soms in een container draait. En hoe kom je dan bij je core dump? Hoe krijg je die

805
01:27:29.890 --> 01:27:36.530
informatie? Hoe kan je die opsturen en zo. Dat is ook iets dat ingewikkeld is en belangrijk

806
01:27:36.530 --> 01:27:43.030
is om aan bij stil te staan dat je die data ook ergens moet moeten oppikken. Een aantal

807
01:27:43.030 --> 01:27:50.130
dingen zijn ook simpeler daaraan. Hetzelfde geldt voor bijvoorbeeld de JavaScript applicaties

808
01:27:51.670 --> 01:27:58.210
en apps. Dus dat heel veel eigenaars daarvan die proberen het te beveiligen. Dus dat je het

809
01:27:58.210 --> 01:28:05.290
niet gewoon kan reverse engineeren en precies ziet hoe het spel werkt of hoe de website precies

810
01:28:05.290 --> 01:28:10.490
werkt. Door te minifyen of zelfs te upskaten en dat soort dingen. Dat is ook iets dat

811
01:28:11.610 --> 01:28:18.830
complexiteit toevoegt aan de client side zeg maar. Als je iets van een telefoon krijgt of

812
01:28:18.830 --> 01:28:23.190
nog eens een dikke complexiteit toevoegen die je vaak aan de server kant niet had. Ik ben even

813
01:28:23.190 --> 01:28:27.990
vergeten waarom ik erover begonnen was maar goed. Nou ja ik kan me wel voorstellen dat dat

814
01:28:27.990 --> 01:28:33.690
natuurlijk iets doet met de observability toch? Ja dat is wel als het in de feit is. Ja ja.

815
01:28:34.470 --> 01:28:44.250
Ja ja. Ja dat opfisketen gewoon nooit doen. Ja nee dat zijn inderdaad dingen die automatisch

816
01:28:45.150 --> 01:28:51.690
ingelezen worden en dan backtrace decodeert dat dan weer voor je. En dan kan je het gewoon

817
01:28:51.690 --> 01:28:56.250
weer lekker makkelijk doorpompen naar Prometheus. Dan heb je het allemaal plaintext zeg maar.

818
01:28:57.030 --> 01:29:05.730
Ja nou goed man. Ik denk dat we er nu al een beetje genoeg over hebben gekletst. Ik heb

819
01:29:05.730 --> 01:29:11.490
in ieder geval heel veel van jullie geleerd dus ja dank je wel daarvoor. Ik stel voor dat we

820
01:29:11.490 --> 01:29:16.750
doorgaan naar het volgende. Ja doen we maar even het luchtige gedeelte van onze CodeKlets

821
01:29:16.750 --> 01:29:22.430
podcast. Dus ik zou jullie twee ook even zeker aanraden om lekker even chill te gaan zitten en

822
01:29:22.950 --> 01:29:28.150
vooral te gaan genieten. Want we gaan twee leuke ja noem het maar even super onderwerpjes

823
01:29:28.150 --> 01:29:33.190
doen. Eentje die heb ik even in de verrassing gezet want normaal doen we altijd eventjes

824
01:29:33.190 --> 01:29:38.550
kort bespreken wat we gaan waar we het over gaan hebben Jeroen en Vincent. Maar ik heb

825
01:29:38.550 --> 01:29:43.850
niet verteld dat we vandaag ja dat is een beetje een lange tijd geleden weer maar we gaan weer

826
01:29:43.850 --> 01:29:53.930
eens de developer dilemmas doen. Kennen jullie dat toevallig? Nooit verteld. Oké maar goed ja

827
01:29:53.930 --> 01:29:57.570
iets wat ik zelf persoonlijk vind ik echt wel leuk om even met jullie jullie te challenger. Ik

828
01:29:57.570 --> 01:30:04.710
ga jullie gewoon met twee ja stellingen ga ik jullie mee confronteren en jullie moeten er

829
01:30:04.710 --> 01:30:09.790
echt eentje kiezen en it depends ja weet je dat wil ik gewoon niet horen. We willen gewoon

830
01:30:09.790 --> 01:30:18.360
je mening weten. Dus ja dus vandaar ik net zei van zorg ervoor dat je de relax bij zit en

831
01:30:19.410 --> 01:30:26.370
denk even goed na dat je antwoord natuurlijk en ja wellicht hebben we nou wel echt een

832
01:30:26.370 --> 01:30:34.690
ja gevecht tussen jullie ik weet het niet. Ik lok het elke keer uit maar het lukt me

833
01:30:34.690 --> 01:30:40.570
dus we gaan we gaan er gewoon drie doen en ja ik ben benieuwd wat jullie antwoorden zijn en

834
01:30:40.570 --> 01:30:48.350
deze developer dilemmas die kun je halen van de developer dilemmas.com. Dat is echt een free

835
01:30:48.350 --> 01:30:54.050
card game zeg maar en van AppSignal is het overigens. Dus die gaan we nu even doen.

836
01:30:54.410 --> 01:31:02.290
AppSignal is trouwens een hele mooie observability tool. We hebben er weer

837
01:31:02.290 --> 01:31:10.370
vertellen. Wat heb je er wel eens gebruikt? Ja, een van mijn klanten gebruikt het. Het is een

838
01:31:10.370 --> 01:31:19.470
Ruby tool en het doet eigenlijk een beetje dat application performance monitoring. Dus

839
01:31:19.470 --> 01:31:27.670
kijken van de applicatie hoe snel wordt die uitgeserveerd, waar wordt de tijd aan verspeeld.

840
01:31:29.410 --> 01:31:37.330
Ook denk ik een beetje wel in het straatje van Vincents werkgever ook. Error analytics.

841
01:31:40.390 --> 01:31:48.990
Om stack traces te analyseren en dan komt het met suggesties voor verbeteringen. Ik weet niet

842
01:31:48.990 --> 01:31:56.190
hoe zinvol die suggesties zijn maar ja brengt het in ieder geval in beeld. Wat cool joh.

843
01:31:56.190 --> 01:32:03.450
Net of ik het echt zo gepland had maar dat was het echt niet hoor Vincent. Het is inderdaad

844
01:32:03.450 --> 01:32:10.190
een app van AppSignal dus cool man. Leuk dat je het even deelt. Nou goed dan gaan we beginnen

845
01:32:10.910 --> 01:32:17.650
jongens. Hou je vast. De eerste die reageert die mag dan uitleggen waarom en de tweede

846
01:32:17.650 --> 01:32:34.550
mag daarna reageren. Hier komt ie. Higher salary or more interesting work? Ja ik woon

847
01:32:34.550 --> 01:32:43.670
nou in Amerika he. Higher salary dan toch maar. Daarom ben je daarheen gegaan. Capitalisme man.

848
01:32:43.670 --> 01:32:48.410
Ja ik weet het wel. Ja dat is er leuk misschien om te stellen. Ik kan me nog herinneren in de

849
01:32:48.410 --> 01:32:55.910
tijd dat bij volgens mij werkte we nog verder bij Xebia. Toen kwam ik naar New York. Dat was ook

850
01:32:55.910 --> 01:33:03.410
voor een van de sales ding. Heb je me flink begeleid daar ja en toen had ik al het gevoel van zo die

851
01:33:03.410 --> 01:33:10.510
Vincent die is flink vooruit gegaan toen ik jou daar ontmoette. Dus nou ik begrijp je antwoord.

852
01:33:11.790 --> 01:33:21.230
Ja ik kan er ook meer aan uitleggen. Het is iets dat vroeger of tenminste toen ik nog

853
01:33:21.230 --> 01:33:25.570
echt technicus was. Was het interessante werk echt heel belangrijk zeg maar. Wil je niet

854
01:33:26.250 --> 01:33:33.710
weet ik veel zelf als de JSP kloppen zeg maar. Omdat dat dan de primaire manier is dat je je

855
01:33:33.710 --> 01:33:40.490
dag doorbrengt en dat soort dingen. Wat ik nou zie in het werk dat ik doe is meer

856
01:33:42.630 --> 01:33:47.970
impactvol. Daardoor is het interessant maar het is ook tegelijkertijd stressvoller. Dus

857
01:33:47.970 --> 01:33:53.470
ik daarom natuurlijk die kaarten zijn zo gemaakt dat je er verschillende manieren

858
01:33:53.470 --> 01:33:58.270
over na kan na kan denken. Ja tuurlijk. Dus dat zit er ook een klein beetje achter.

859
01:33:58.650 --> 01:34:06.570
Ja ik begrijp het joh. En jij Jeroen? Ja ik zit erover na te denken. Ik vind het een

860
01:34:08.810 --> 01:34:18.840
aantal jaren geleden zou ik gezegd hebben hoger salaris. Op de een of andere manier merkte ik toen

861
01:34:20.690 --> 01:34:27.370
bij elke zoveel honderd euro die erbij kwam merkte ik dat men dat meer kon doen. Ik kon

862
01:34:27.370 --> 01:34:36.550
groter gaan wonen. Ik kon een ziekere auto hebben. Ik kon vaker op vakantie. Maar na een

863
01:34:37.570 --> 01:34:45.970
dan voel je het niet meer op de een of andere manier. Ja tuurlijk als je mij nu 500 euro per

864
01:34:45.970 --> 01:34:53.990
maand toeschuift Kishen. Ik denk dat ik heel blij zou zijn. Ik bedank je er zeker voor. Maar

865
01:34:53.990 --> 01:35:02.450
het is niet dat het echt een quality of life in de voetloos brengt. Dat ik nu wel op een

866
01:35:02.450 --> 01:35:09.450
best comfortabel niveau zit. En dan vind ik het belangrijker om met die 40 uur die ik heb

867
01:35:10.270 --> 01:35:17.150
om daar dan iets mee te doen dat me gelukkig maakt en ook nog een beetje waarde toevoegt voor

868
01:35:17.150 --> 01:35:23.290
de wereld. Dus ik zou dan toch wel voor interessant werken. Ja snap ik. Ik had dat

869
01:35:23.290 --> 01:35:28.330
toevallig nog. Dat was met mijn vrouw trouwens. Die had een keer ook ergens gesociteerd en die

870
01:35:28.330 --> 01:35:34.890
manager daar die had een heel betoog over dat er ergens een magisch nummer is in Nederland. En

871
01:35:34.890 --> 01:35:38.990
dan interesseert het niet meer wat je dan... Weet je al of het nou meer of minder gaat worden,

872
01:35:39.490 --> 01:35:48.790
dat interesseert dan niet meer. Precies en na een tijdje dan kom je ook op een inkomen

873
01:35:48.790 --> 01:35:56.870
dat de enige die er echt nog beter van wordt is de belasting. Dus stel je

874
01:35:58.330 --> 01:36:07.670
zit al in die 54 procent schijf. Dan heb je wel echt heel veel extra geld nodig om te zorgen

875
01:36:07.670 --> 01:36:15.950
dat je daar echt iets van merkt. Na een tijdje daar heb je ook al genoeg. Ja ik heb een auto,

876
01:36:16.050 --> 01:36:20.170
ik heb een huis. Tweede huis is misschien leuk voor in een ver land of zo. Maar tweede

877
01:36:20.170 --> 01:36:28.810
auto, dat zou een beetje gek zijn. Ja precies. Wat moet je dan nog met je geld? Nee heldenman.

878
01:36:29.610 --> 01:36:37.090
Ja ik vind het ook belangrijk. Zolang je maar gewoon de dingen kan doen waar je je het meest

879
01:36:37.090 --> 01:36:45.330
om geeft, dat is het belangrijkste volgens mij. Ik denk ook dat, kijk als je deze

880
01:36:45.330 --> 01:36:50.050
vragen buiten de IT zou stellen dan zou het antwoord misschien anders zijn. We zitten

881
01:36:50.050 --> 01:36:55.790
gelukkig in een industrie die al ergens betaald is. Ja dat is ook zo. Dus dan zullen er veel

882
01:36:55.790 --> 01:37:03.050
mensen gewoon more interesting work gaan kiezen. Ja absoluut. Precies. Oké. Nou goed ik stel

883
01:37:03.050 --> 01:37:09.770
voor dat we er nog even eentje doen. Ja leuk. Ja even kijken. Oh ik zit natuurlijk eventjes

884
01:37:09.770 --> 01:37:14.510
naar de resultaten te kijken. Ik heb nu even more interesting work gewoon omdat we dat

885
01:37:14.510 --> 01:37:24.470
samen zo concluderen. 65 procent inderdaad die kiest daarvoor. Oké. Ja deze hebben we al eens

886
01:37:24.470 --> 01:37:35.230
gehad dus die ga ik skippen. Oh deze vind ik heel tof. Stroopwafels or stroopwafels.

887
01:37:40.170 --> 01:37:46.590
Ik denk dat aan Vincent hoef ik hem niet te vragen want ja ik ben gewoon een Nederlander dus. Stroopwafels.

888
01:37:47.270 --> 01:37:51.930
Ja precies. Plus dat je ze hier ook als je met United vliegt krijg je ook stroopwafels als snack.

889
01:37:54.970 --> 01:38:04.340
De eerste is AdBlocker. De tweede is Chronological Twitter. Oh dat snap ik al.

890
01:38:06.170 --> 01:38:11.270
Ah ja welke features zou je het liefst willen hebben van Twitter.

891
01:38:11.730 --> 01:38:15.830
Nou dus je moet er echt twee kiezen dus de AdBlocker of de Chronological Twitter.

892
01:38:17.470 --> 01:38:21.590
Nou dan zou ik voor de chronologische tijd neigengaan.

893
01:38:21.590 --> 01:38:23.950
Oké dus die ads die overleef je wel.

894
01:38:24.730 --> 01:38:32.190
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.

895
01:38:34.550 --> 01:38:47.090
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.

896
01:38:47.090 --> 01:38:48.870
Ik vind dat zo leeg.

897
01:38:49.430 --> 01:38:53.530
Ik snap totaal niet waarom ze dat nou gedaan hebben.

898
01:38:54.230 --> 01:38:55.710
En jij Vincent?

899
01:38:57.470 --> 01:38:58.070
Oef.

900
01:38:58.690 --> 01:39:04.810
Ik denk dat ik de chronologische Twitter feed wel dat de fijnste is.

901
01:39:05.270 --> 01:39:07.770
Ja want zij hier roen ook al net.

902
01:39:09.310 --> 01:39:14.810
Ja en weet je ik gun Jack en Elon die advertentieeinkomst ook wel gewoon.

903
01:39:14.910 --> 01:39:15.550
Zo is dat.

904
01:39:15.910 --> 01:39:16.810
Ja precies.

905
01:39:19.550 --> 01:39:21.070
Hey even kijken.

906
01:39:21.490 --> 01:39:29.450
Ja nou even de resultaat even met jullie delen 74 procent heeft gekozen voor ad blocker.

907
01:39:32.170 --> 01:39:36.830
Dus men vindt toch blijkbaar de advertentie is toch wel irritant.

908
01:39:38.870 --> 01:39:39.970
Ja die had ik niet.

909
01:39:40.330 --> 01:39:41.850
Ja ja ik ook niet.

910
01:39:42.610 --> 01:39:45.750
Ik zou ook inderdaad die ad blockers die kan ik nog wel meleven.

911
01:39:46.270 --> 01:39:49.490
Of sorry de ads even kijken.

912
01:39:49.710 --> 01:39:54.230
Nou laatste dilemma deze ken ik ook al dus ga ik ook even skipen.

913
01:39:56.370 --> 01:40:01.050
Als ik er nou nog eentje ken ja oké deze die heb ik nog nooit die ken ik.

914
01:40:01.130 --> 01:40:02.970
Oh dit zegt mij ook helemaal niks.

915
01:40:03.110 --> 01:40:10.090
Maar goed ik ga het gewoon even voorlezen hopelijk jullie wel wat Tim Cook for a day.

916
01:40:12.130 --> 01:40:14.910
Of Linus Torvalds voor a day.

917
01:40:17.250 --> 01:40:18.970
Ja dat is een goede.

918
01:40:20.210 --> 01:40:23.230
Ik weet niet zo heel veel van Tim Cook persoonlijk.

919
01:40:23.310 --> 01:40:27.610
Ik weet dat Linus een ontzettende even kijken.

920
01:40:29.130 --> 01:40:31.250
Moeilijke persoonlijkheid heeft zeg maar.

921
01:40:31.610 --> 01:40:32.210
Oké.

922
01:40:32.450 --> 01:40:33.830
Maar ik vind hem wel interessanter.

923
01:40:34.190 --> 01:40:39.370
Dus ik zou toch Linus Torvalds voor a day kiezen.

924
01:40:39.370 --> 01:40:44.330
Ik denk dat hij me heel vaak beledigt en een leuke gesprek met hem kan hebben.

925
01:40:45.070 --> 01:40:48.470
Oké natuurlijk en nu heb ik er natuurlijk een beeld van hem.

926
01:40:49.430 --> 01:40:51.490
Maar het kan zijn dat ik nu echt een digibeet ben.

927
01:40:51.610 --> 01:40:52.390
Maar wie is Linus?

928
01:40:54.230 --> 01:40:56.710
Dat is de ontwikkelaar van Linus.

929
01:40:57.210 --> 01:41:00.070
Oh wow oké dus de Linux ontwikkelaar.

930
01:41:00.370 --> 01:41:01.330
Ah nou valt het kwartje.

931
01:41:01.710 --> 01:41:02.650
En Git ook.

932
01:41:03.470 --> 01:41:04.210
Ja Git inderdaad.

933
01:41:04.750 --> 01:41:07.030
Oké ja die is niet zo.

934
01:41:07.030 --> 01:41:09.490
Maar ook een leuke voor de speakers note.

935
01:41:11.790 --> 01:41:12.610
Hoe noem je dat?

936
01:41:12.650 --> 01:41:18.530
De talk die Linus gaf toen hij Git introduceerde is een briljante om te zien.

937
01:41:18.790 --> 01:41:22.650
Waar hij iedereen tot de veters afbrandt zeg maar.

938
01:41:22.790 --> 01:41:23.890
Echt waar joh?

939
01:41:24.350 --> 01:41:24.670
Oh shit.

940
01:41:24.850 --> 01:41:26.450
Ja hij is niet subtiel.

941
01:41:27.070 --> 01:41:27.910
Hij is slimmer naar beter.

942
01:41:27.970 --> 01:41:28.590
Oké oké.

943
01:41:28.690 --> 01:41:31.350
Dus jij zou dus voor Linus gaan en niet voor de tip.

944
01:41:32.750 --> 01:41:35.330
Ja ik vraag me nou net af.

945
01:41:35.830 --> 01:41:40.830
Is het nou zijn dat je een dag met ze doorbrengt of dat je ze een dag bent?

946
01:41:40.970 --> 01:41:41.510
Nee nee nee.

947
01:41:42.110 --> 01:41:46.110
Nou het vaag is dat het staat er niet echt zo letterlijk.

948
01:41:46.130 --> 01:41:49.350
Het staat er gewoon letterlijk gewoon Tim Cook voor RD.

949
01:41:50.310 --> 01:41:51.970
Dus of je dan hem bent of?

950
01:41:52.330 --> 01:41:53.910
Ik denk dat je ze moet zijn.

951
01:41:54.570 --> 01:41:54.770
Oké.

952
01:41:56.030 --> 01:41:56.470
Oké.

953
01:41:56.590 --> 01:41:57.890
Nou wie zou je dan zijn?

954
01:42:00.370 --> 01:42:01.330
Ja als ik mocht kiezen.

955
01:42:01.530 --> 01:42:04.310
Kijk ja ik wist eigenlijk al vrij snel.

956
01:42:05.150 --> 01:42:10.630
Ik zou Linus niet willen zijn want die gast heeft met veel te veel mensen ruzie.

957
01:42:10.870 --> 01:42:14.430
Dus dat is gewoon echt waarschijnlijk de meest ongezellige dag uit mijn leven.

958
01:42:15.550 --> 01:42:20.520
En als je Tim Cook mag zijn voor een dag dan is er nog best wel wat te bereiken.

959
01:42:22.710 --> 01:42:25.520
Ik zou dan echt eventjes wat knopen door gaan hakken.

960
01:42:26.630 --> 01:42:30.910
Om te zorgen dat we eindelijk USB-C op de iCloud pakken.

961
01:42:31.390 --> 01:42:31.890
Woehoe.

962
01:42:33.650 --> 01:42:36.110
Ja dat is me echt een doorn in het oog.

963
01:42:36.310 --> 01:42:41.990
Gewoon daarom alleen al ik weet je ik doe Tim wel voor een dag en dan.

964
01:42:43.650 --> 01:42:44.550
Alright, alright.

965
01:42:44.970 --> 01:42:48.790
Als ik dat één dag doe dan heb ik waarschijnlijk ook genoeg verdiend voor de rest van mijn leven.

966
01:42:49.610 --> 01:42:50.610
Dat is ook nog een voortje.

967
01:42:50.670 --> 01:42:51.090
Ja precies.

968
01:42:51.150 --> 01:42:52.230
Heb je je leven beter gemaakt.

969
01:42:54.550 --> 01:42:56.110
Ja dat is super leuk man.

970
01:42:56.590 --> 01:42:59.190
Nou ja goed ik hoop dat jullie het een beetje leuk hebben gevonden.

971
01:42:59.190 --> 01:43:02.710
Dat waren de drie dilemmas die ik daarvan doe.

972
01:43:03.350 --> 01:43:03.730
Ja heel leuk.

973
01:43:04.230 --> 01:43:04.670
Oké top, top.

974
01:43:05.290 --> 01:43:09.930
Nou goed dan gaan we naar het laatste onderdeel van onze podcast.

975
01:43:10.810 --> 01:43:14.550
Dat zijn de tips en tricks en van ons nog wat bash.

976
01:43:15.410 --> 01:43:18.250
Of een stuk van bash wil ik dat zeggen.

977
01:43:18.950 --> 01:43:21.350
Ja je mag ook bashjes noemen als je wilt.

978
01:43:21.550 --> 01:43:22.330
Dat maakt helemaal niet uit.

979
01:43:23.810 --> 01:43:28.770
Maar ja ik ben wel benieuwd naar wat jullie onze luisteraar zouden willen

980
01:43:30.170 --> 01:43:31.810
hebben jullie daar een beetje over nagedacht?

981
01:43:35.740 --> 01:43:36.280
Nee.

982
01:43:37.620 --> 01:43:40.980
Winst, ik zit aan mijn voorbereidingsnotities te kijken.

983
01:43:41.120 --> 01:43:42.120
Geef niet hoor, geef niet.

984
01:43:42.540 --> 01:43:45.090
Je hebt iets gemist, dus dan jij Jeroen?

985
01:43:47.700 --> 01:43:52.680
Ja ik zat net even na te denken.

986
01:43:56.260 --> 01:43:58.100
We hadden het net over observability.

987
01:43:58.100 --> 01:44:05.800
En op een bepaald level zou je kunnen zeggen oké ik heb een applicatie en een bepaalde

988
01:44:05.800 --> 01:44:09.320
infrastructuur die zorgt dat die applicatie naar de klant kan komen.

989
01:44:11.860 --> 01:44:17.320
Ik had het er net over probeer je heden sterk in beeld te brengen.

990
01:44:19.260 --> 01:44:23.220
Maar je zit natuurlijk tegenwoordig met steeds meer kwetsbaarheden.

991
01:44:24.640 --> 01:44:29.540
We hadden vorige week weer dat ding in Spring Framework.

992
01:44:29.820 --> 01:44:36.980
Een tijdje terug stond het hele wereld in de gek vanwege Log4j inderdaad.

993
01:44:41.240 --> 01:44:44.880
Ik ben benieuwd en dat kunnen mensen wel even in de comments zetten.

994
01:44:45.360 --> 01:44:53.200
Hebben jullie ideeën over hoe je op een soort van preventieve manier

995
01:44:55.020 --> 01:45:00.400
misbruik van dat soort vulnerabilities zou kunnen monitoren.

996
01:45:01.280 --> 01:45:04.600
Bijvoorbeeld te kijken hoe je netwerkverbinding in de zicht draagt.

997
01:45:07.020 --> 01:45:10.560
Zodat je eigenlijk op het moment dat een vulnerability naar buiten komt

998
01:45:10.560 --> 01:45:15.900
al kunt zien als stel dat het een 0D is bijvoorbeeld dat je dan kan zien van oh ja

999
01:45:15.900 --> 01:45:19.060
dit is eigenlijk al vijf keer geprobeerd op onze server.

1000
01:45:20.920 --> 01:45:25.260
Ja dat lijkt me best interessant. Ik heb er geen paskwaar idee op.

1001
01:45:26.720 --> 01:45:32.100
Terwijl we net aan het praten waren dacht ik van het zou wel tof zijn als daar iets voor is.

1002
01:45:34.900 --> 01:45:42.080
Oké, ik heb toevallig een Kubernetes start-up gewerkt.

1003
01:45:43.060 --> 01:45:46.160
Israëlisch is het Kubernetes start-up twee jaar geleden.

1004
01:45:46.160 --> 01:45:52.380
Ik heb er wel een aantal ideeën over maar ik ben inderdaad benieuwd wat er in de community komt.

1005
01:45:52.600 --> 01:45:59.940
Er zijn tools inderdaad specifiek gericht op het detecteren van attack factors en dat soort

1006
01:45:59.940 --> 01:46:03.340
dingen. Het is echt, daar kan je inderdaad ook heel super diep in gaan.

1007
01:46:04.880 --> 01:46:09.640
Ja want ik kan me ook herinneren inderdaad dat jij toch wel in de security vooral

1008
01:46:09.640 --> 01:46:16.620
Kubernetes heel erg actief bent. Ja, meer was dan ben ik.

1009
01:46:19.760 --> 01:46:23.840
En nu nog niet, dus je hebt niet nu al een tipje dat je denkt van hey.

1010
01:46:24.260 --> 01:46:28.200
Nou ik realiseer me nou inderdaad opeens waar de tips van onze luisteraars,

1011
01:46:28.300 --> 01:46:31.820
je had dat inderdaad in je email, ik heb er wel een aantal en dat zijn gewoon dingen

1012
01:46:31.820 --> 01:46:36.640
die helemaal geen ene klap te maken hebben met observabiliteit. Te maken hebben met

1013
01:46:36.980 --> 01:46:41.660
met games. Ik wil een plug doen voor Gorilla Games. Dat is een Nederlandse game studio

1014
01:46:41.660 --> 01:46:48.640
die de Horizon Series gemaakt heeft en een van de delen redelijk recent uitgebracht

1015
01:46:48.640 --> 01:46:56.840
heeft. En het is goed om je producten uit je eigen land te steunen zeg maar.

1016
01:46:57.320 --> 01:47:06.100
Gronings Gas en Horizon Series van Gorilla Games zeg maar. Dat is een tip om te checken.

1017
01:47:07.100 --> 01:47:13.920
Ja goede Nederlandse games. Ja en zijn er ook bepaalde boeken die jullie onlangs hebben gelezen?

1018
01:47:15.600 --> 01:47:18.820
Misschien moet ik dat gewoon even stellen. Wat is de laatste boek dat je gelezen hebt?

1019
01:47:20.320 --> 01:47:27.340
Ik ben recentelijk juist weer begonnen met fiction lezen. De hele tijd eigenlijk niet gedaan.

1020
01:47:29.660 --> 01:47:32.920
En recentelijk eigenlijk was op een conferentie stond ik met

1021
01:47:32.920 --> 01:47:44.340
iemand te praten die me iets aanraden. Ik lees veel science fiction. Het is relaxend om dat

1022
01:47:44.340 --> 01:47:49.600
te lezen en het doet leuke dingen met je brein enzo. Er zijn twee dingen die ik zou noemen.

1023
01:47:50.320 --> 01:48:00.400
De Bobbyverse Series van Danacy Taylor. Dat gaat over iemand die zijn brein ingevroren wordt en

1024
01:48:01.160 --> 01:48:06.620
wakker wordt als een soort van dat zijn consciousness ingeladen is in een in een computer zeg maar.

1025
01:48:07.040 --> 01:48:12.980
En hij gebruikt wordt om de intelligentie te zijn in een van Neumann probe. En een van

1026
01:48:12.980 --> 01:48:20.220
Neumann probe is een ruimtevaartuig dat alles aan boord heeft om zichzelf te repliceren.

1027
01:48:20.380 --> 01:48:25.620
Dus die kan een kopie van zichzelf maken en die kopie van zichzelf wat anders kan laten

1028
01:48:25.620 --> 01:48:34.450
doen en dan door. En hier zitten dan 3D printers aan boord enzo. Dus super interessante serie als

1029
01:48:35.620 --> 01:48:42.780
dat soort dingen je een beetje aanspreken. En een ander is Old Man's War van Scalzi en dat gaat

1030
01:48:43.520 --> 01:48:53.470
over de mensheid verder in de toekomst. Waar de mensheid gepensioneerde recruit om in het leger

1031
01:48:53.470 --> 01:48:59.390
te gaan. Dus die gepensioneerde een nieuw lichaam om dan vervolgens met heel veel ervaring,

1032
01:48:59.470 --> 01:49:06.510
75 jaar ervaring, levenservaring oorlogen te voeren in plaats van daar 20 jaar broekmannetjes

1033
01:49:07.510 --> 01:49:16.110
in te sturen. En allebei interessante creatieve manier om naar de toekomst te kijken. Dus

1034
01:49:16.110 --> 01:49:21.330
ik heb Old Man's War heb ik nog niet uit. Ben ik een deel drie of iets dergelijks,

1035
01:49:21.330 --> 01:49:27.290
maar twee boekerseries die ik in ieder geval goed kan aanraden en vast goed aansluiten met

1036
01:49:27.290 --> 01:49:34.030
de doelgroep van CodeKlets. Wauw, heel goed man, dankjewel. Ik denk zeker dat die aanslaat.

1037
01:49:34.370 --> 01:49:40.450
En weet je, het eerste boek, Bobby's Series, was het nou? Bobby's First. Sorry, Bobby's First.

1038
01:49:40.890 --> 01:49:46.570
Is daar in ieder geval een serie van gemaakt op Amazon. Het klinkt namelijk een beetje bekend,

1039
01:49:46.810 --> 01:49:50.970
want we hebben namelijk ooit een keer een aflevering gehad, dat ging over mobile

1040
01:49:50.970 --> 01:49:58.530
development. De gast daar, die had het ook over, een serie die, dat ging ook over dat

1041
01:49:58.530 --> 01:50:05.630
iemand in verloren werd en dan opnieuw geinjecteerd in het leven met de gedachten. Of is dat iets

1042
01:50:05.630 --> 01:50:12.530
anders? Het is een serie in de vorm van, het zijn zes boeken volgens mij of iets dergelijks,

1043
01:50:12.630 --> 01:50:17.210
maar ik weet niet of, het klinkt alsof jij het over hebt, alsof het een... Ja, precies.

1044
01:50:18.030 --> 01:50:25.650
Maar goed, niet dat ik weet. Maar goed, moeten we even opzoeken. Dat concept van Neumann Probe

1045
01:50:25.650 --> 01:50:35.690
doet me ook een beetje denken aan de boord van Star Trek, die ook schepen hebben die zichzelf

1046
01:50:35.690 --> 01:50:42.110
kunnen genereren en herstellen als er schade is. Ja, inderdaad. Dat klinkt ook nog niet

1047
01:50:42.110 --> 01:50:47.070
gelegd. Ja, cool. En jij Jeroen, heb je nog een tof boek gelezen onlangs?

1048
01:50:47.070 --> 01:50:53.470
Ja, het is een beetje een cliché aan het worden. Ik heb gisteren de Zeven Vinkjes uitgelezen.

1049
01:50:54.050 --> 01:51:09.150
De wat? De Zeven Vinkjes. Dat is een boek. Het is eigenlijk een kritiek op de maatschappij,

1050
01:51:09.210 --> 01:51:14.550
zoals we die in Nederland hebben geschreven, door Joris Luijenwijk. En dat gaat erover

1051
01:51:14.550 --> 01:51:21.890
dat in het Nederlands, zoals dat er nu is, wordt eigenlijk 95 procent van de beslissingen

1052
01:51:21.890 --> 01:51:30.750
genomen door personen die aan zeven kenmerken voldoen. En dat, ik weet, even alle zeven

1053
01:51:30.750 --> 01:51:35.410
zo gauw niet uit mijn hoofd, maar dat is dat je hoog opgeleid bent, dat je hetero bent,

1054
01:51:35.530 --> 01:51:43.130
dat je man bent, dat je blank bent. Ook dat je ouders hoog opgeleid zijn. En ja,

1055
01:51:43.130 --> 01:51:49.870
het legt eigenlijk uit hoe schadelijk dat is, omdat mensen die heel erg op elkaar lijken,

1056
01:51:49.990 --> 01:51:55.130
en dat hebben die mensen die aan die zeven eisen voldoen, die houden elkaar wat kwaliteit

1057
01:51:55.130 --> 01:52:03.470
van de dingen die ze doen. Ja, het hand boven het hoofd. Hij pleit dus eigenlijk voor meer

1058
01:52:04.010 --> 01:52:13.110
diversiteit. Ja, ik zit me wel, al sinds ik het boek uit heb, af te vragen hoe legit is

1059
01:52:13.110 --> 01:52:20.510
het, want de schrijver van het boek voldoet zelf aan al die zeven vinkjes. Oh ja, nu heb ik hem.

1060
01:52:21.050 --> 01:52:26.610
Ik weet het al. Ik heb ooit een keer ook weer zo'n filmpje gezien waar Sylvana Simons en hij

1061
01:52:26.610 --> 01:52:33.070
samen zaten, geloof ik. Volgens mij hebben ze een gigantische ruzie gehad. Precies, ja. En

1062
01:52:33.070 --> 01:52:38.090
ook op LinkedIn op een gegeven moment beland. Het werd op een gegeven moment een grote

1063
01:52:38.090 --> 01:52:46.990
Facebook drama, weet ik nog wel, op LinkedIn toen. Naar aanleiding van die fitties ben ik het boek ook gaan rezen.

1064
01:52:47.230 --> 01:52:52.930
Ja, snap ik. Ik was ook wel nieuwsgierig. Ik was ook gelijk nieuwsgierig, precies. Oké, oké.

1065
01:52:52.990 --> 01:52:57.550
Goeie tip man. Ja, want het rinkelde wel even een belletje bij mij, maar ik kom even die plaatsen,

1066
01:52:58.110 --> 01:53:02.690
dus fijn dat je hem even gedeeld hebt en ik zal hem zeker opnemen in de show note. Ja,

1067
01:53:02.830 --> 01:53:07.610
super man. Nou, hartstikke fijn jongens. Ik zie dat we bijna de twee uur hebben bereikt,

1068
01:53:07.610 --> 01:53:13.570
dus ja, ik wil je sowieso heel erg bedanken voor deze opname over observability.

1069
01:53:15.070 --> 01:53:20.630
Dus bedankt Vincent en Jeroen voor deze aflevering. Ja, ik heb persoonlijk echt best wel

1070
01:53:20.630 --> 01:53:27.550
veel van jullie geleerd, vooral met observability rondom een vraag die ik persoonlijk ook ja,

1071
01:53:27.670 --> 01:53:32.550
eigenlijk niet zo snel zou stellen, maar gewoon omdat ik, ja wat dat betreft ook kudos aan

1072
01:53:32.550 --> 01:53:37.930
Wouter Dijks dat hij die vraag heeft opgesteld. Maar het verschil weet je wel van monitoring,

1073
01:53:38.050 --> 01:53:42.090
tracing en metrics, dat was echt voor mij even een, ik denk echt sterk knoggen. Ik

1074
01:53:42.090 --> 01:53:45.130
ga hem straks de aflevering afluisteren en dan ga ik het ook gelijk documenteren,

1075
01:53:45.250 --> 01:53:49.390
zodat ik het voor altijd in mijn hoofd heb gezet. Dus dank je wel daarvoor.

1076
01:53:49.670 --> 01:53:54.390
Graag gedaan. Ja natuurlijk. Even kijken, nou mochten jullie,

1077
01:53:54.550 --> 01:53:59.410
ja de luisteraars thuis mochten jullie CodeKlets leuk vinden. Vertel het vooral door aan je

1078
01:53:59.410 --> 01:54:05.530
vrienden en collega's. Mocht je met ons ook willen kletsen, kom dan vooral naar onze Slack,

1079
01:54:05.630 --> 01:54:12.990
want we hebben een Slack workspace gemaakt. Op codeklets.nl kun je de link vinden. Ja Jeroen

1080
01:54:12.990 --> 01:54:16.510
en Vincent, ja je bent ook meer dan welkom. Er zullen misschien ook wel vragen richting

1081
01:54:16.510 --> 01:54:20.890
jullie kant op komen. Nou hoe leuk is het als je ze persoonlijk kan beantwoorden. En

1082
01:54:20.890 --> 01:54:26.490
misschien wel een discussie over die vraag van Jeroen, van ideeën om preventieve manieren te

1083
01:54:26.490 --> 01:54:35.030
doen. Nou ja goed, je kan ons inderdaad makkelijk vinden op codeklets.nl. Je kunt

1084
01:54:35.030 --> 01:54:42.870
ons ook vinden op Twitter, at codeklets. En op LinkedIn hebben we ook een company page,

1085
01:54:43.290 --> 01:54:49.070
dus daar ben je ook meer dan welkom om ons te volgen. Ja, dus dat resulteert mij

1086
01:54:49.070 --> 01:54:54.710
alleen maar nogmaals om jullie twee nog een keer te bedanken. En alle luisteraars natuurlijk

1087
01:54:54.710 --> 01:54:59.810
bedankt voor het luisteren deze aflevering en tot de volgende keer. Dankjewel allemaal,

1088
01:55:00.130 --> 01:55:04.670
doeg. Jij ook bedankt voor het hosten Kishen. Jo, graag gedaan. Hoi hoi.