WEBVTT

1
00:00:00.040 --> 00:00:03.480
<v Speaker 1>Okay, let's unpack this, because you know, there's a very

2
00:00:03.520 --> 00:00:07.839
<v Speaker 1>specific kind of anxiety that comes with modern software development.

3
00:00:08.400 --> 00:00:09.439
<v Speaker 2>I know what you're talking about.

4
00:00:09.759 --> 00:00:12.000
<v Speaker 1>I feel like we have all been sold this micro

5
00:00:12.080 --> 00:00:15.720
<v Speaker 1>services dream for years now. You know the pitch kill

6
00:00:15.759 --> 00:00:21.280
<v Speaker 1>the monolith, break everything into these sleek, tiny, independent services.

7
00:00:21.359 --> 00:00:22.839
<v Speaker 2>It sounds like utopia.

8
00:00:22.960 --> 00:00:25.760
<v Speaker 1>It sounds perfect. You scale what you need, you deploy

9
00:00:25.800 --> 00:00:27.440
<v Speaker 1>whenever you want. Everyone's happy.

10
00:00:27.679 --> 00:00:31.480
<v Speaker 2>On paper, it is the perfect architecture. It promises agility.

11
00:00:31.199 --> 00:00:34.840
<v Speaker 1>Resilience right on paper. But then you know, reality hits,

12
00:00:34.880 --> 00:00:37.640
<v Speaker 1>and suddenly you aren't just writing business logic anymore. You

13
00:00:37.640 --> 00:00:41.000
<v Speaker 1>aren't just selling cookies or processing payments. Suddenly you have

14
00:00:41.039 --> 00:00:43.880
<v Speaker 1>to become a distributed systems engineer. Just to write a

15
00:00:43.920 --> 00:00:48.280
<v Speaker 1>simple shopping cart app. You're dealing with retries and certificate

16
00:00:48.359 --> 00:00:52.280
<v Speaker 1>rotation and state management and service discovery. It's like buying

17
00:00:52.280 --> 00:00:54.960
<v Speaker 1>a Ferrari but realizing you have to pave the highway

18
00:00:55.000 --> 00:00:56.439
<v Speaker 1>yourself before you can drive it.

19
00:00:56.759 --> 00:01:01.119
<v Speaker 2>That is a painfully accurate analogy. Ustry actually calls these

20
00:01:01.159 --> 00:01:05.719
<v Speaker 2>the fallacies of distributed computing. We assume the network is reliable,

21
00:01:06.159 --> 00:01:09.480
<v Speaker 2>latency is zero, bandwidth is infinite, which they never are

22
00:01:09.760 --> 00:01:14.439
<v Speaker 2>they're not, and handling that complexity usually means writing thousands

23
00:01:14.439 --> 00:01:17.200
<v Speaker 2>of lines of plumbing code that has absolutely nothing to

24
00:01:17.200 --> 00:01:19.599
<v Speaker 2>do with the actual value your software provides.

25
00:01:19.640 --> 00:01:22.439
<v Speaker 1>And that is exactly where today's deep dive comes in.

26
00:01:22.640 --> 00:01:25.159
<v Speaker 1>We are looking at a solution that claims to fix

27
00:01:25.239 --> 00:01:29.640
<v Speaker 1>this plumbing nightmare, Dapper or the distributed application run time.

28
00:01:30.239 --> 00:01:33.280
<v Speaker 1>We're basing this discussion on the book Practical micro Services

29
00:01:33.480 --> 00:01:37.120
<v Speaker 1>with DAPRA and dot Net by David Bidden, and.

30
00:01:37.079 --> 00:01:39.200
<v Speaker 2>This book is essentially a field guide. It doesn't just

31
00:01:39.280 --> 00:01:42.560
<v Speaker 2>theorize it. It walks you through the gritty details of

32
00:01:42.599 --> 00:01:46.319
<v Speaker 2>building a real system and the core argument but an actually,

33
00:01:46.359 --> 00:01:49.239
<v Speaker 2>as your CTO, Mark Orsinovitch, who wrote the forward, makes

34
00:01:49.680 --> 00:01:52.680
<v Speaker 2>is that developers should stop writing this plumbing code entirely.

35
00:01:53.120 --> 00:01:55.439
<v Speaker 1>Orsinovich uses a metaphor that I really want to dig into.

36
00:01:55.519 --> 00:01:57.840
<v Speaker 1>Right at the start. He calls Dappra a butler for

37
00:01:57.920 --> 00:01:58.439
<v Speaker 1>your code.

38
00:01:58.519 --> 00:02:01.760
<v Speaker 2>It's such a great image. Think about it. If you're

39
00:02:01.799 --> 00:02:04.719
<v Speaker 2>a busy executive, you want to focus on strategy, the

40
00:02:04.799 --> 00:02:06.959
<v Speaker 2>what you don't want to worry about how to mail

41
00:02:06.959 --> 00:02:09.120
<v Speaker 2>a letter or how to file a receipt or who

42
00:02:09.159 --> 00:02:10.479
<v Speaker 2>to call to fix the sink.

43
00:02:10.680 --> 00:02:12.159
<v Speaker 1>You want someone to just handle it.

44
00:02:12.360 --> 00:02:16.240
<v Speaker 2>You want a butler to handle the how In this context,

45
00:02:16.439 --> 00:02:19.599
<v Speaker 2>your code focuses on the business logic, and Dapper is

46
00:02:19.599 --> 00:02:22.400
<v Speaker 2>the butler handling all those messy infrastructure tasks.

47
00:02:22.680 --> 00:02:25.280
<v Speaker 1>So instead of me having to hardcode, Hey, connect to

48
00:02:25.360 --> 00:02:27.400
<v Speaker 1>Rettus at this specific IP.

49
00:02:27.280 --> 00:02:29.439
<v Speaker 2>Address, authenticate with this token, and.

50
00:02:29.319 --> 00:02:32.479
<v Speaker 1>Retry three times. If it times out, I just tell

51
00:02:32.479 --> 00:02:34.199
<v Speaker 1>the butler save this and I go back to work.

52
00:02:34.400 --> 00:02:38.400
<v Speaker 2>That is the promise. Yeah, But to understand how it

53
00:02:38.479 --> 00:02:42.879
<v Speaker 2>does that without being magic, because there's no magic in software,

54
00:02:43.319 --> 00:02:45.360
<v Speaker 2>we have to look at the architecture. Right. The part

55
00:02:45.520 --> 00:02:47.879
<v Speaker 2>isn't a library you can pile into your code. It

56
00:02:48.000 --> 00:02:49.319
<v Speaker 2>uses a sidecar pattern.

57
00:02:49.800 --> 00:02:51.599
<v Speaker 1>Okay, this is a term that gets thrown around a

58
00:02:51.599 --> 00:02:55.599
<v Speaker 1>lot in cloud native circles. Sidecar. Let's strip away the jargon.

59
00:02:55.639 --> 00:02:57.080
<v Speaker 1>What does this look like practically?

60
00:02:57.360 --> 00:03:01.199
<v Speaker 2>Okay, visualize your application. Let's say it's a microservice in

61
00:03:01.280 --> 00:03:05.319
<v Speaker 2>dot Net or Python or go. Picture that app as

62
00:03:05.360 --> 00:03:08.719
<v Speaker 2>a person sitting at a desk doing work. In a

63
00:03:08.759 --> 00:03:11.840
<v Speaker 2>traditional setup, that person has to have a phone, a

64
00:03:11.840 --> 00:03:15.719
<v Speaker 2>fax machine, a rolodex, and a massive instruction manual on

65
00:03:15.759 --> 00:03:18.120
<v Speaker 2>their desk just to talk to the outside world.

66
00:03:18.159 --> 00:03:19.719
<v Speaker 1>And they have to know how to operate all of

67
00:03:19.719 --> 00:03:20.879
<v Speaker 1>them perfectly exactly.

68
00:03:21.240 --> 00:03:23.919
<v Speaker 2>Now, with Dapper, you add a sidecar. This is a

69
00:03:23.960 --> 00:03:26.719
<v Speaker 2>separate process, a personal assistant sitting at a desk right

70
00:03:26.759 --> 00:03:27.439
<v Speaker 2>next to them.

71
00:03:27.280 --> 00:03:29.599
<v Speaker 1>So they're practically touching elbows right.

72
00:03:29.879 --> 00:03:32.240
<v Speaker 2>If your app is in Kubernetes, it's a container in

73
00:03:32.280 --> 00:03:34.800
<v Speaker 2>the same pod. If you're on a laptop, it's a

74
00:03:34.840 --> 00:03:38.280
<v Speaker 2>process running alongside. Now, if your application needs to talk

75
00:03:38.319 --> 00:03:41.960
<v Speaker 2>to another service, it doesn't shat across the office. It

76
00:03:42.039 --> 00:03:44.879
<v Speaker 2>leans over and whispers to the assistant, get this message

77
00:03:44.919 --> 00:03:48.240
<v Speaker 2>to shipping. The assistant the Dapper sidecar is the one

78
00:03:48.240 --> 00:03:51.319
<v Speaker 2>that looks up poor shipping is handles security, encrypts the

79
00:03:51.319 --> 00:03:53.159
<v Speaker 2>message and make sure it gets there.

80
00:03:53.240 --> 00:03:56.599
<v Speaker 1>That distinction is crucial because it implies language independence. If

81
00:03:56.599 --> 00:03:59.120
<v Speaker 1>I'm whispering to my assistant, I can whisper in English

82
00:03:59.240 --> 00:04:01.000
<v Speaker 1>or Spanish or even binary.

83
00:04:01.360 --> 00:04:07.840
<v Speaker 2>Precisely, this is the any language, any framework, anywhere philosophy.

84
00:04:07.879 --> 00:04:12.280
<v Speaker 2>Bedin emphasizes your app talks to its DApp sidecar using

85
00:04:12.319 --> 00:04:16.879
<v Speaker 2>standard HTTP or gRPC, just over local host. It's incredibly lightweight,

86
00:04:17.000 --> 00:04:17.680
<v Speaker 2>so I could have.

87
00:04:17.600 --> 00:04:21.120
<v Speaker 1>A legacy Java app talking to a brand new Go service.

88
00:04:21.240 --> 00:04:24.399
<v Speaker 2>It depri acts as the universal translator or maybe diplomat

89
00:04:24.439 --> 00:04:24.879
<v Speaker 2>between them.

90
00:04:24.920 --> 00:04:26.879
<v Speaker 1>Okay, but I have to play Devil's advocate here. I'm

91
00:04:26.879 --> 00:04:31.160
<v Speaker 1>a developer. I hear extra process and network hop. Adding

92
00:04:31.160 --> 00:04:33.560
<v Speaker 1>a hop sending traffic to a sidecar before it goes

93
00:04:33.560 --> 00:04:36.560
<v Speaker 1>to the network. Doesn't that add latency? Are we trading

94
00:04:36.560 --> 00:04:37.839
<v Speaker 1>performance for convenience?

95
00:04:37.920 --> 00:04:40.800
<v Speaker 2>It's a valid concern, and Bedan addresses it technically. Yes,

96
00:04:40.800 --> 00:04:44.240
<v Speaker 2>there is overhead. We're usually talking microseconds or submilisecond times

97
00:04:44.600 --> 00:04:47.959
<v Speaker 2>for that local hop. Okay, but consider the counter argument.

98
00:04:48.519 --> 00:04:52.279
<v Speaker 2>Can you write a better, more optimized retry loop, connection pool,

99
00:04:52.360 --> 00:04:55.600
<v Speaker 2>and security handshake in your custom code than the engineers

100
00:04:55.600 --> 00:04:56.560
<v Speaker 2>who built the run time?

101
00:04:56.720 --> 00:04:59.399
<v Speaker 1>Probably not. I'd likely just write a while true loop

102
00:04:59.439 --> 00:04:59.959
<v Speaker 1>and hope for the best.

103
00:05:00.160 --> 00:05:03.759
<v Speaker 2>Exactly, And here's the kicker dapper. Sidecars communicate with each

104
00:05:03.759 --> 00:05:06.839
<v Speaker 2>other using gRPC. Oh interesting, So even if your app

105
00:05:06.879 --> 00:05:10.600
<v Speaker 2>speaks simple HTTP to its sidecar, the sidecar upgrades that

106
00:05:10.639 --> 00:05:14.079
<v Speaker 2>to gRPC with proto buff serialization when it talks to

107
00:05:14.120 --> 00:05:15.560
<v Speaker 2>other sidecars over the network.

108
00:05:15.720 --> 00:05:17.759
<v Speaker 1>So you might actually see better performance.

109
00:05:18.000 --> 00:05:20.639
<v Speaker 2>You might because the wire protocol is so much more

110
00:05:20.680 --> 00:05:25.720
<v Speaker 2>efficient than a poorly written direct HTDP client. You're outsourcing

111
00:05:25.800 --> 00:05:27.399
<v Speaker 2>the optimization to the runtime.

112
00:05:27.680 --> 00:05:30.480
<v Speaker 1>That's a fair point. Okay, let's get practical. The book

113
00:05:30.600 --> 00:05:34.360
<v Speaker 1>uses a really specific and honestly dangerous for me. Example,

114
00:05:34.680 --> 00:05:38.279
<v Speaker 1>we are building an e commerce site for biscotti booty.

115
00:05:38.079 --> 00:05:41.800
<v Speaker 2>Mobile wanning ugly but good cookies, a classic Italian tree.

116
00:05:41.839 --> 00:05:43.680
<v Speaker 1>I am getting hungry just saying it. So we have

117
00:05:43.759 --> 00:05:46.279
<v Speaker 1>this cookie store, and Benin breaks it down into a

118
00:05:46.439 --> 00:05:50.240
<v Speaker 1>classic micro service triad and order service to take money,

119
00:05:50.240 --> 00:05:52.800
<v Speaker 1>a reservation service to check inventory.

120
00:05:52.360 --> 00:05:54.319
<v Speaker 2>And a shipping service to get the cookies out the door.

121
00:05:54.519 --> 00:05:57.279
<v Speaker 1>Right, it's the Hello world of distributed systems.

122
00:05:57.319 --> 00:05:59.360
<v Speaker 2>But it's perfect because it forces us to deal with

123
00:05:59.360 --> 00:06:03.920
<v Speaker 2>the three bigges headaches, service invocation, state management, and event

124
00:06:04.000 --> 00:06:04.800
<v Speaker 2>driven messaging.

125
00:06:04.959 --> 00:06:09.439
<v Speaker 1>Let's tackle the first one, service invocation. I'm the order service.

126
00:06:09.639 --> 00:06:12.519
<v Speaker 1>I have a customer who wants a dozen biscotties. I

127
00:06:12.600 --> 00:06:16.360
<v Speaker 1>need to ask the reservation service do we have twelve cookies.

128
00:06:16.920 --> 00:06:20.920
<v Speaker 2>In the battle days, you might hardcosee the reservation service's

129
00:06:20.959 --> 00:06:24.800
<v Speaker 2>IP address or DNS name into your configuration.

130
00:06:24.360 --> 00:06:25.160
<v Speaker 1>And then it moves.

131
00:06:25.319 --> 00:06:29.199
<v Speaker 2>It moves, the IP changes, your app crashes. It's fragile.

132
00:06:29.279 --> 00:06:32.600
<v Speaker 2>Extremely With DAP, your order service just calls local host

133
00:06:32.639 --> 00:06:36.480
<v Speaker 2>and says invoke the method. Check inventory on the application

134
00:06:36.639 --> 00:06:38.079
<v Speaker 2>named reservation service.

135
00:06:38.319 --> 00:06:40.360
<v Speaker 1>So I'm addressing it by a logical name, not a

136
00:06:40.360 --> 00:06:41.240
<v Speaker 1>physical location.

137
00:06:41.480 --> 00:06:44.360
<v Speaker 2>Correct. The dapper sidecar looks up that name. If you're

138
00:06:44.399 --> 00:06:47.600
<v Speaker 2>running locally on your laptop, it uses mDNS. If you're

139
00:06:47.600 --> 00:06:50.879
<v Speaker 2>in Kubernetes, it uses the cluster DNS. Okay, it finds

140
00:06:50.920 --> 00:06:54.040
<v Speaker 2>the target. But then it does something really slick. It

141
00:06:54.079 --> 00:06:56.839
<v Speaker 2>automatically applies MTLs mutual TLS.

142
00:06:56.519 --> 00:06:59.959
<v Speaker 1>Encryption, so the traffic is encrypted and both sides verify

143
00:07:00.120 --> 00:07:01.480
<v Speaker 1>each other's identity without you.

144
00:07:01.439 --> 00:07:04.079
<v Speaker 2>Writing a single line of security code. It's zero trust

145
00:07:04.160 --> 00:07:06.639
<v Speaker 2>security right out of the box. And if the reservation

146
00:07:06.720 --> 00:07:09.560
<v Speaker 2>service is restarting or the network blips it failed, Dapper

147
00:07:09.639 --> 00:07:13.639
<v Speaker 2>automatically retries the request with an exponential backoff policy.

148
00:07:13.720 --> 00:07:15.839
<v Speaker 1>That's the butler hiding the mess. I don't see the

149
00:07:15.839 --> 00:07:19.000
<v Speaker 1>network failure. I just see a slightly delayed success exactly.

150
00:07:19.199 --> 00:07:22.519
<v Speaker 2>But now we run into the second headache. Micro services

151
00:07:22.560 --> 00:07:24.120
<v Speaker 2>are supposed to be stateless, right.

152
00:07:24.160 --> 00:07:26.959
<v Speaker 1>If a container crashes, it forgets everything in its memory.

153
00:07:27.040 --> 00:07:30.680
<v Speaker 2>But we are selling cookies. We need to remember that

154
00:07:30.759 --> 00:07:34.040
<v Speaker 2>we only have fifty left. If we forget that we

155
00:07:34.160 --> 00:07:35.079
<v Speaker 2>sell cookies, we.

156
00:07:35.279 --> 00:07:37.759
<v Speaker 1>Don't have and nobody wants a phantom cookie.

157
00:07:38.040 --> 00:07:41.480
<v Speaker 2>This brings us to Dapper State management building block. And

158
00:07:41.560 --> 00:07:43.759
<v Speaker 2>this is the part of the book where the plug

159
00:07:43.759 --> 00:07:46.240
<v Speaker 2>ability aspect really click for me.

160
00:07:46.399 --> 00:07:48.759
<v Speaker 1>Walk us through that, because usually picking a database is

161
00:07:48.800 --> 00:07:51.639
<v Speaker 1>like a marriage. You pick reddis, you install the redssdk,

162
00:07:52.079 --> 00:07:53.680
<v Speaker 1>you write Reddus commands.

163
00:07:53.279 --> 00:07:56.399
<v Speaker 2>And divorce is expensive. Very it is, Yeah, but dappra

164
00:07:56.600 --> 00:08:00.680
<v Speaker 2>treats state as a generic key value store. Your application

165
00:08:00.800 --> 00:08:05.480
<v Speaker 2>sends adjacent payload like cookie inventory fifty to the Dapper

166
00:08:05.600 --> 00:08:08.639
<v Speaker 2>sidecar and says save this. You don't tell it where.

167
00:08:08.800 --> 00:08:10.279
<v Speaker 1>Wait, so how does it know where to put it?

168
00:08:10.439 --> 00:08:14.000
<v Speaker 2>Configuration not code. You have a yamal file, a component

169
00:08:14.040 --> 00:08:17.639
<v Speaker 2>file that defines the state store. On your developer laptop,

170
00:08:18.040 --> 00:08:21.720
<v Speaker 2>that yamal file points to a reddis container running and Docker. Okay,

171
00:08:21.920 --> 00:08:24.879
<v Speaker 2>But when you deploy a production you swamp that yamal

172
00:08:24.959 --> 00:08:29.639
<v Speaker 2>file to point to Azure Cosmos dB or AWS Dynamo GB.

173
00:08:29.560 --> 00:08:33.200
<v Speaker 1>And I don't change my c sharp or Python code.

174
00:08:33.000 --> 00:08:36.919
<v Speaker 2>Not a single line. The application logic is completely decoupled

175
00:08:36.919 --> 00:08:38.480
<v Speaker 2>from the infrastructure implementation.

176
00:08:38.679 --> 00:08:41.320
<v Speaker 1>That's huge for portability. But I have to ask about

177
00:08:41.320 --> 00:08:44.960
<v Speaker 1>the nuance here, because databases aren't just generic buckets. What

178
00:08:45.039 --> 00:08:47.159
<v Speaker 1>happens if two people try to buy the last cookie

179
00:08:47.159 --> 00:08:50.360
<v Speaker 1>at the exact same millisecond. The last Cannoli problem.

180
00:08:50.000 --> 00:08:52.879
<v Speaker 2>A classic race condition. Benden spends time on this because

181
00:08:52.919 --> 00:08:55.720
<v Speaker 2>it's where the abstraction could get leaky if you aren't careful.

182
00:08:56.480 --> 00:08:58.440
<v Speaker 2>Dapper handles this using E tags.

183
00:08:58.879 --> 00:09:00.600
<v Speaker 1>Explain that for the expert.

184
00:09:00.679 --> 00:09:02.559
<v Speaker 2>Think of an E tag like a version number on

185
00:09:02.600 --> 00:09:05.360
<v Speaker 2>a document. When I check the inventory, Daker tells me

186
00:09:05.440 --> 00:09:07.480
<v Speaker 2>there are fifty cookies and this is version one.

187
00:09:07.639 --> 00:09:08.000
<v Speaker 1>Okay.

188
00:09:08.120 --> 00:09:10.600
<v Speaker 2>If I want to buy ten, I tell Dapper update

189
00:09:10.639 --> 00:09:13.200
<v Speaker 2>inventory to forty, but only if it's still version one,

190
00:09:13.320 --> 00:09:13.679
<v Speaker 2>and if.

191
00:09:13.559 --> 00:09:15.399
<v Speaker 1>Someone else sneaked in and bought a cookie while I

192
00:09:15.440 --> 00:09:16.279
<v Speaker 1>was thinking.

193
00:09:16.200 --> 00:09:19.720
<v Speaker 2>The database is now at version two. Dapper sees my

194
00:09:19.759 --> 00:09:24.759
<v Speaker 2>request with version one, realizes it's outdated, and rejects the right.

195
00:09:25.080 --> 00:09:27.639
<v Speaker 2>This is first right wins concurrency. I see that Dapper

196
00:09:27.720 --> 00:09:30.720
<v Speaker 2>exposes this complexity in a standardized way, so you can

197
00:09:30.759 --> 00:09:33.720
<v Speaker 2>handle it properly, regardless of whether the underlying database is

198
00:09:33.720 --> 00:09:35.159
<v Speaker 2>RETTIS or SQL.

199
00:09:35.240 --> 00:09:38.559
<v Speaker 1>So it prevents me from accidentally overwriting someone else's purchase.

200
00:09:38.639 --> 00:09:42.039
<v Speaker 1>That's critical. What about consistency? I know in distributed systems

201
00:09:42.080 --> 00:09:45.559
<v Speaker 1>there's this fight between strong and eventual consistency.

202
00:09:45.639 --> 00:09:48.960
<v Speaker 2>Yes, and Dapper lets you choose. Do you need strong

203
00:09:49.039 --> 00:09:52.200
<v Speaker 2>consistency where all database replicas must confirm the right before

204
00:09:52.200 --> 00:09:52.679
<v Speaker 2>we move.

205
00:09:52.519 --> 00:09:54.039
<v Speaker 1>On safer but slower.

206
00:09:53.840 --> 00:09:56.360
<v Speaker 2>Exactly, or do you want eventual consistency where we just

207
00:09:56.440 --> 00:10:00.159
<v Speaker 2>need one acknowledgment and trust it'll propagate. Dapper gives you

208
00:10:00.200 --> 00:10:03.960
<v Speaker 2>a dial to turn that logic again via the API calls,

209
00:10:04.240 --> 00:10:05.679
<v Speaker 2>not by changing your database driver.

210
00:10:05.840 --> 00:10:08.399
<v Speaker 1>Okay, so we've ordered the cookies, We've reserved them. Now

211
00:10:08.440 --> 00:10:11.120
<v Speaker 1>we need to ship them in a monolith. I'd just

212
00:10:11.240 --> 00:10:14.240
<v Speaker 1>call the shipping class. But here we want to decouple this.

213
00:10:14.759 --> 00:10:16.480
<v Speaker 1>I don't want the order service to hang while the

214
00:10:16.480 --> 00:10:18.399
<v Speaker 1>warehouse printer is warming up exactly.

215
00:10:18.840 --> 00:10:22.399
<v Speaker 2>Shipping is an asynchronous process. The user wants to see

216
00:10:22.600 --> 00:10:25.519
<v Speaker 2>order confirmed immediately. They don't care about the back end

217
00:10:25.559 --> 00:10:29.759
<v Speaker 2>logistics yet. This is where Beddin introduces the publish and

218
00:10:29.840 --> 00:10:31.639
<v Speaker 2>subscribe or pub sub pattern.

219
00:10:31.840 --> 00:10:34.399
<v Speaker 1>So the order service effectively picks up a megaphone and

220
00:10:34.480 --> 00:10:37.960
<v Speaker 1>shots order one twenty three is ready, and it doesn't.

221
00:10:37.679 --> 00:10:41.759
<v Speaker 2>Care who is listening. It publishes that event to a topic. Yeah,

222
00:10:41.799 --> 00:10:44.759
<v Speaker 2>the shipping service subscribes to that topic. Maybe an email

223
00:10:44.799 --> 00:10:47.519
<v Speaker 2>service subscribes to maybe a loyalty point service.

224
00:10:47.559 --> 00:10:49.480
<v Speaker 1>They all react independently.

225
00:10:49.240 --> 00:10:52.320
<v Speaker 2>And sitting in the middle handling the megaphone is Dapper

226
00:10:52.360 --> 00:10:55.759
<v Speaker 2>again I'm guessing so Dapper and a message broker. Just

227
00:10:55.799 --> 00:10:59.120
<v Speaker 2>like with the database, Dapper abstracts the broker. You could

228
00:10:59.159 --> 00:11:01.840
<v Speaker 2>use Redis locally, then switch to as your service bus

229
00:11:01.919 --> 00:11:05.000
<v Speaker 2>or Rabbit MQ in production. But there's a really cool

230
00:11:05.039 --> 00:11:07.639
<v Speaker 2>scalability feature here called competing consumers.

231
00:11:07.720 --> 00:11:10.279
<v Speaker 1>Competing consumers that sounds like Black Friday shoppers. What does

232
00:11:10.279 --> 00:11:10.879
<v Speaker 1>that mean here?

233
00:11:11.080 --> 00:11:13.720
<v Speaker 2>Imagine our cookie shop goes viral. Suddenly you have ten

234
00:11:13.759 --> 00:11:16.639
<v Speaker 2>thousand orders coming in per minute. One instance of the

235
00:11:16.679 --> 00:11:19.919
<v Speaker 2>shipping service can't handle printing that many labels, so you

236
00:11:19.960 --> 00:11:22.240
<v Speaker 2>spin up ten instances of the shipping service.

237
00:11:22.559 --> 00:11:25.879
<v Speaker 1>Okay, but if I shot order ready, won't all ten

238
00:11:25.919 --> 00:11:28.080
<v Speaker 1>of them try to ship the same package.

239
00:11:28.440 --> 00:11:31.440
<v Speaker 2>That would be a disaster. But Dapper is smart enough

240
00:11:31.480 --> 00:11:34.879
<v Speaker 2>to act as a load balancer for these messages. It

241
00:11:35.000 --> 00:11:38.679
<v Speaker 2>uses the consumer group concept. It ensures that order A

242
00:11:38.879 --> 00:11:42.360
<v Speaker 2>goes to instance one, order B goes to instance two.

243
00:11:42.559 --> 00:11:45.080
<v Speaker 1>It spreads the workout automatically.

244
00:11:44.480 --> 00:11:48.919
<v Speaker 2>Correct and if Instance one crashes while processing order A,

245
00:11:49.039 --> 00:11:53.200
<v Speaker 2>Dapper detects the failure. Maybe the acknowledgment never came back

246
00:11:53.639 --> 00:11:55.399
<v Speaker 2>and redelivers it to instance too.

247
00:11:55.519 --> 00:11:58.200
<v Speaker 1>That's the distributed systems engineer stuff. I really don't want

248
00:11:58.200 --> 00:11:59.519
<v Speaker 1>to write it is, I've done it.

249
00:11:59.559 --> 00:12:02.399
<v Speaker 2>I don't recommend it. Writing a lease management system for

250
00:12:02.480 --> 00:12:05.320
<v Speaker 2>message locking is a nightmare, and DAP just gives it

251
00:12:05.320 --> 00:12:06.039
<v Speaker 2>to you for free.

252
00:12:06.120 --> 00:12:07.519
<v Speaker 1>It changes your whole mindset.

253
00:12:07.639 --> 00:12:09.919
<v Speaker 2>It does you stop thinking about calling service B and

254
00:12:09.960 --> 00:12:13.000
<v Speaker 2>start thinking about publishing an event that something happened. It

255
00:12:13.000 --> 00:12:14.480
<v Speaker 2>makes your system much more flexible.

256
00:12:14.679 --> 00:12:17.679
<v Speaker 1>I want to pivot to the developer experience because honestly,

257
00:12:17.759 --> 00:12:21.120
<v Speaker 1>this all sounds great architecturally, but running a distributed system

258
00:12:21.120 --> 00:12:23.559
<v Speaker 1>on my laptop usually sucks.

259
00:12:23.639 --> 00:12:25.039
<v Speaker 2>It's a major friction point.

260
00:12:25.159 --> 00:12:28.639
<v Speaker 1>I need to spin up five different terminals, manage ports,

261
00:12:29.000 --> 00:12:30.519
<v Speaker 1>work about Docker containers.

262
00:12:31.440 --> 00:12:34.600
<v Speaker 2>It's just friction for sure. In the past, people would

263
00:12:34.600 --> 00:12:37.039
<v Speaker 2>just build a monolith locally and hope it worked as

264
00:12:37.080 --> 00:12:40.360
<v Speaker 2>micro services in production, which of course it never did.

265
00:12:40.960 --> 00:12:43.879
<v Speaker 2>But the book dedicates a whole chapter to tooling, specifically

266
00:12:43.919 --> 00:12:46.840
<v Speaker 2>the Dappa TAP extension for vs code and a tool

267
00:12:46.879 --> 00:12:47.600
<v Speaker 2>called tie.

268
00:12:47.720 --> 00:12:50.240
<v Speaker 1>I was looking at the tasks do Jason examples in

269
00:12:50.279 --> 00:12:52.480
<v Speaker 1>the book. It looks like you can script the whole

270
00:12:52.600 --> 00:12:53.600
<v Speaker 1>environment startup.

271
00:12:53.879 --> 00:12:56.000
<v Speaker 2>You can. You can configure it so that when you

272
00:12:56.159 --> 00:12:59.519
<v Speaker 2>hit debug in VS code, it launches your order service,

273
00:12:59.559 --> 00:13:02.960
<v Speaker 2>your reservation service, spins up the dapper of sidecars for both,

274
00:13:03.320 --> 00:13:05.720
<v Speaker 2>and even launches a local REDTIS container. You get a

275
00:13:05.720 --> 00:13:07.559
<v Speaker 2>fully integrated debugging experience.

276
00:13:07.600 --> 00:13:09.240
<v Speaker 1>And can I set break points? Can I step through

277
00:13:09.240 --> 00:13:10.679
<v Speaker 1>the code across services?

278
00:13:10.799 --> 00:13:12.879
<v Speaker 2>You can set brake points in your c shark code

279
00:13:13.000 --> 00:13:15.720
<v Speaker 2>just like a monolith. But when the request leaves your

280
00:13:15.759 --> 00:13:18.720
<v Speaker 2>service and goes to the sidecar, you lose it until

281
00:13:18.720 --> 00:13:19.759
<v Speaker 2>it hits the next service.

282
00:13:20.000 --> 00:13:20.240
<v Speaker 1>Ah.

283
00:13:20.440 --> 00:13:22.360
<v Speaker 2>Right, This is where observability comes in.

284
00:13:22.360 --> 00:13:25.200
<v Speaker 1>Right, Because debugging a single process is easy, Debugging a

285
00:13:25.240 --> 00:13:29.039
<v Speaker 1>request that bounces through five services is like hunting ghosts exactly.

286
00:13:29.159 --> 00:13:32.200
<v Speaker 2>Yeah, a user says my order failed and you have

287
00:13:32.360 --> 00:13:35.360
<v Speaker 2>no idea if it died in the order service, the network,

288
00:13:35.639 --> 00:13:39.159
<v Speaker 2>or the database. And typically to fix this, developers have

289
00:13:39.240 --> 00:13:43.039
<v Speaker 2>to manually instrument their code. They had logging everywhere, entering

290
00:13:43.039 --> 00:13:44.840
<v Speaker 2>function A, leaving function B.

291
00:13:46.080 --> 00:13:48.080
<v Speaker 1>It's tedious and it clutters up the code.

292
00:13:48.200 --> 00:13:52.080
<v Speaker 2>Yeah. But because dapper intercepts every request going in and out,

293
00:13:52.480 --> 00:13:56.679
<v Speaker 2>it automatically generates distributed tracing data. It supports the zipkin

294
00:13:56.759 --> 00:13:58.039
<v Speaker 2>protocol standard.

295
00:13:58.080 --> 00:14:01.399
<v Speaker 1>Zipcn is the tool that draws those waterfall timelines, right, yes.

296
00:14:01.519 --> 00:14:03.919
<v Speaker 2>Yeah, because the traffic flows through the sidecar. You get

297
00:14:03.919 --> 00:14:06.480
<v Speaker 2>that map for free. You could open the zipken dashboard

298
00:14:06.480 --> 00:14:09.240
<v Speaker 2>and see a visual timeline. Okay, the request hit the

299
00:14:09.320 --> 00:14:12.399
<v Speaker 2>order service, spent five meters there, then went to reservation.

300
00:14:12.840 --> 00:14:15.240
<v Speaker 2>Whoa look the database saf took five seconds.

301
00:14:15.279 --> 00:14:16.840
<v Speaker 1>You spot the bottleneck instantly.

302
00:14:17.360 --> 00:14:20.399
<v Speaker 2>It's invaluable. It can expect to the butler analogy. The

303
00:14:20.440 --> 00:14:23.720
<v Speaker 2>butler keeps a log of every visitor and every message pasted.

304
00:14:23.840 --> 00:14:25.320
<v Speaker 2>You don't have to write it down yourself.

305
00:14:25.440 --> 00:14:27.639
<v Speaker 1>You just asked the butler what happened with order one

306
00:14:27.679 --> 00:14:29.600
<v Speaker 1>twenty three, and he hands you the log. That's the

307
00:14:29.679 --> 00:14:34.159
<v Speaker 1>idea that sounds incredibly useful. So we've covered the architecture,

308
00:14:34.320 --> 00:14:39.080
<v Speaker 1>the sidecars, state management, pub sub, the tooling. When you

309
00:14:39.159 --> 00:14:41.960
<v Speaker 1>step back and look at the Biscotti Britty Mborney example

310
00:14:42.000 --> 00:14:44.919
<v Speaker 1>as a whole, what is the synthesis. What's the big

311
00:14:44.960 --> 00:14:45.759
<v Speaker 1>takeaway for me?

312
00:14:45.799 --> 00:14:48.519
<v Speaker 2>It comes down to two words, autonomy and evolution.

313
00:14:49.039 --> 00:14:49.399
<v Speaker 1>Okay.

314
00:14:49.600 --> 00:14:53.080
<v Speaker 2>In a traditional setup, your code is tightly coupled to

315
00:14:53.120 --> 00:14:56.399
<v Speaker 2>your infrastructure choices. If you want to change from rabbit

316
00:14:56.519 --> 00:15:00.360
<v Speaker 2>MQ to service bus, you are rewriting code to move

317
00:15:00.360 --> 00:15:03.120
<v Speaker 2>from on prem to the cloud. Your rewriting code.

318
00:15:02.840 --> 00:15:05.279
<v Speaker 1>And tight coupling is the enemy of speed. It makes

319
00:15:05.320 --> 00:15:07.159
<v Speaker 1>everyone afraid to touch anything.

320
00:15:06.919 --> 00:15:10.919
<v Speaker 2>Exactly daypre decouples the what from the how. It allows

321
00:15:10.919 --> 00:15:13.919
<v Speaker 2>the infrastructure to evolve at a different speed than the

322
00:15:13.960 --> 00:15:17.759
<v Speaker 2>application code. You can modernize your back end storage without

323
00:15:17.759 --> 00:15:20.000
<v Speaker 2>frightening the developers who are just trying to sell cookies.

324
00:15:20.200 --> 00:15:23.360
<v Speaker 1>It standardizes the plumbing across the organization. You don't have

325
00:15:23.399 --> 00:15:26.440
<v Speaker 1>one team implementing retries one way and another team doing

326
00:15:26.440 --> 00:15:27.159
<v Speaker 1>it a different way.

327
00:15:27.360 --> 00:15:28.960
<v Speaker 2>And I think we need to end on a bit

328
00:15:28.960 --> 00:15:30.600
<v Speaker 2>of a provocative thought here.

329
00:15:30.600 --> 00:15:31.679
<v Speaker 1>Hit me, what's the catch?

330
00:15:32.120 --> 00:15:34.879
<v Speaker 2>There is a risk we are creating a very comfortable

331
00:15:34.879 --> 00:15:39.360
<v Speaker 2>abstraction layer. If DAPRA acts as this universal butler handling

332
00:15:39.399 --> 00:15:43.399
<v Speaker 2>all the plumbing. Are we creating a generation of developers

333
00:15:43.440 --> 00:15:46.360
<v Speaker 2>who don't understand how distributed systems actually work.

334
00:15:46.639 --> 00:15:48.559
<v Speaker 1>That's a valid fear. If I don't know how the

335
00:15:48.600 --> 00:15:50.399
<v Speaker 1>sausage is made, do I know how to fix it

336
00:15:50.440 --> 00:15:51.720
<v Speaker 1>when the machine jams?

337
00:15:51.919 --> 00:15:56.399
<v Speaker 2>Exactly? DAPPA hides the complexity, but it shouldn't hide the reality.

338
00:15:56.759 --> 00:16:00.000
<v Speaker 2>You still need to understand that data isn't instantly consistent.

339
00:16:00.440 --> 00:16:02.759
<v Speaker 2>You still need to understand that messages can arrive out

340
00:16:02.799 --> 00:16:05.919
<v Speaker 2>of order. Right, Debra gives you a really fancy electric screwdriver,

341
00:16:06.440 --> 00:16:08.279
<v Speaker 2>but you still need to know how to build the cabinet.

342
00:16:08.320 --> 00:16:11.240
<v Speaker 1>That is a great distinction. It's a tool for professionals,

343
00:16:11.240 --> 00:16:14.159
<v Speaker 1>not a magic wand that removes the need for knowledge.

344
00:16:14.279 --> 00:16:18.759
<v Speaker 2>Well put, it amplifies capability, it doesn't replace understanding.

345
00:16:18.440 --> 00:16:20.399
<v Speaker 1>Well for anyone who wants to see the code behind

346
00:16:20.440 --> 00:16:23.080
<v Speaker 1>the cookies. And frankly, the Dapper un commands are really

347
00:16:23.159 --> 00:16:27.279
<v Speaker 1>satisfying to see in action. Davidybden's book Practical micro Services

348
00:16:27.360 --> 00:16:30.399
<v Speaker 1>with Dapper and dot Net is the source. The examples

349
00:16:30.440 --> 00:16:33.000
<v Speaker 1>are on GitHub and they are definitely worth the clone.

350
00:16:33.120 --> 00:16:36.519
<v Speaker 2>I highly recommend looking at the transition from the controller

351
00:16:36.559 --> 00:16:40.840
<v Speaker 2>approach to the gRPC approach in his code. It really

352
00:16:40.879 --> 00:16:43.080
<v Speaker 2>eliminates the performance benefits we discussed.

353
00:16:43.639 --> 00:16:46.240
<v Speaker 1>Thanks for diving deep with us today. Hopefully your next

354
00:16:46.240 --> 00:16:49.200
<v Speaker 1>distributed system feels a little less like a headache and

355
00:16:49.240 --> 00:16:51.720
<v Speaker 1>a little more like well, like cookies, ugly but good

356
00:16:51.720 --> 00:16:54.200
<v Speaker 1>cookies exactly see on the next deep dive