WEBVTT

1
00:00:00.160 --> 00:00:02.439
<v Speaker 1>Welcome to the deep dive, where we cut through the

2
00:00:02.480 --> 00:00:04.559
<v Speaker 1>noise to get you well informed on the topics that

3
00:00:04.639 --> 00:00:07.719
<v Speaker 1>truly matter. Today. We're navigating the dynamic world of modern

4
00:00:07.759 --> 00:00:13.960
<v Speaker 1>application development. It's a place where speed, scalability, resilience, they're

5
00:00:14.000 --> 00:00:17.440
<v Speaker 1>all non negotiable, right, but the complexity, well, it can

6
00:00:17.480 --> 00:00:20.760
<v Speaker 1>often feel like a massive tangled knot. We're taking a

7
00:00:20.800 --> 00:00:24.920
<v Speaker 1>deep dive into an incredibly practical guide exploring Azure Container Apps,

8
00:00:25.239 --> 00:00:29.079
<v Speaker 1>scaling modern and cloud native apps and micro services Marching cash.

9
00:00:29.320 --> 00:00:32.960
<v Speaker 1>This book by Naga Santos, Ready, Vutakori, Kaser Judae and

10
00:00:33.079 --> 00:00:36.479
<v Speaker 1>Whale Kodu is really our roadmap today. We're looking at

11
00:00:36.479 --> 00:00:39.679
<v Speaker 1>how Azure Container Apps, which is powered by something called DAP,

12
00:00:39.920 --> 00:00:43.880
<v Speaker 1>simplifies building really robust applications in the cloud. Our mission

13
00:00:43.920 --> 00:00:45.759
<v Speaker 1>today is to unpack how you can get the huge

14
00:00:45.759 --> 00:00:49.200
<v Speaker 1>benefits of container orchestration thank Kubernetes without needing to become

15
00:00:49.240 --> 00:00:52.200
<v Speaker 1>an infrastructure guru. We'll explore the core of Azure Container

16
00:00:52.240 --> 00:00:55.039
<v Speaker 1>apps first, and then we'll reveal how DApp or supercharges

17
00:00:55.079 --> 00:00:58.200
<v Speaker 1>your ability to create resilient, scalable micro services. It makes

18
00:00:58.200 --> 00:01:02.600
<v Speaker 1>really complex tasks surprisingly straightforward. We're here to unravel these complexities,

19
00:01:02.920 --> 00:01:05.239
<v Speaker 1>show you how cloud native can be more accessible than

20
00:01:05.280 --> 00:01:08.640
<v Speaker 1>you might think, maybe sparking some fresh insights for you. Okay,

21
00:01:08.680 --> 00:01:13.400
<v Speaker 1>let's unpack this. What exactly is Azure Container Apps ATA

22
00:01:13.480 --> 00:01:16.319
<v Speaker 1>and why should someone building modern apps really pay attention?

23
00:01:16.439 --> 00:01:18.079
<v Speaker 1>It sounds like it's a significant shift.

24
00:01:18.280 --> 00:01:21.599
<v Speaker 2>It absolutely is that. Think of it this way. ACA

25
00:01:22.040 --> 00:01:25.239
<v Speaker 2>gives you all the robust, sort of self healing power

26
00:01:25.280 --> 00:01:29.680
<v Speaker 2>of Kubernetes, but without the headache, without managing the underlying

27
00:01:29.719 --> 00:01:34.280
<v Speaker 2>infrastructure or wrestling with complex yamal files all day. The

28
00:01:34.319 --> 00:01:38.000
<v Speaker 2>real insight, I think, is it, let's developer ship code faster.

29
00:01:38.239 --> 00:01:41.000
<v Speaker 2>They focus purely on their business logic, not the cloud

30
00:01:41.040 --> 00:01:45.640
<v Speaker 2>plumbing underneath. It provides a fully managed, serverless Kubernetes based

31
00:01:45.680 --> 00:01:48.239
<v Speaker 2>container run time that well, it just works.

32
00:01:48.519 --> 00:01:52.040
<v Speaker 1>So it's essentially Kubernetes leat for developers. Then that sounds

33
00:01:52.120 --> 00:01:55.480
<v Speaker 1>incredibly appealing, almost maybe too good to be true for

34
00:01:55.480 --> 00:01:59.120
<v Speaker 1>anyone who's wrestled with kamil. Are there trayoffs though, or

35
00:01:59.200 --> 00:02:01.840
<v Speaker 1>specific scenarios where you'd still need the full power of

36
00:02:02.159 --> 00:02:03.879
<v Speaker 1>as your kubernaty service akas.

37
00:02:04.079 --> 00:02:05.920
<v Speaker 2>That's a great question, and it really gets to the

38
00:02:05.959 --> 00:02:10.199
<v Speaker 2>heart of ACA's value. It fully embraces that serverlest paradigm,

39
00:02:10.199 --> 00:02:12.759
<v Speaker 2>meaning you don't manage the underlying servers at all. The

40
00:02:12.800 --> 00:02:15.719
<v Speaker 2>platform dynamically gives you resources based on your apps load.

41
00:02:15.960 --> 00:02:19.240
<v Speaker 2>It scales automatically, even down to zero instances when it's idle,

42
00:02:19.400 --> 00:02:20.800
<v Speaker 2>then scales up for traffic.

43
00:02:20.479 --> 00:02:22.039
<v Speaker 1>Spikes, right scaling to zero.

44
00:02:22.439 --> 00:02:26.960
<v Speaker 2>Yeah, which ensures efficient resource use and cost optimization. It

45
00:02:27.000 --> 00:02:29.800
<v Speaker 2>aligns perfectly with that pay as you go model. You

46
00:02:29.879 --> 00:02:32.199
<v Speaker 2>only pay for what your application actually uses and the

47
00:02:32.199 --> 00:02:35.479
<v Speaker 2>trade off you mentioned. That's exactly why workload profiles exist.

48
00:02:35.680 --> 00:02:38.759
<v Speaker 1>Okay, that dynamic scaling from zero sounds like a game

49
00:02:38.879 --> 00:02:42.280
<v Speaker 1>changer for cost, But what if you have a really specific,

50
00:02:42.319 --> 00:02:45.680
<v Speaker 1>demanding workload. Does ACA still give you that flexibility?

51
00:02:45.840 --> 00:02:48.719
<v Speaker 2>It does, yeah, through its workload profiles. The default the

52
00:02:48.759 --> 00:02:52.280
<v Speaker 2>consumption profile is like you said, perfect for those variable workloads.

53
00:02:52.639 --> 00:02:55.439
<v Speaker 2>Scales on demand goes to zero when idle. But for

54
00:02:55.479 --> 00:02:59.639
<v Speaker 2>specialized workloads things needing consistent performance or maybe separation, there's

55
00:02:59.639 --> 00:03:03.080
<v Speaker 2>the DEBT de CATD profile. This offers specific hardware resources,

56
00:03:03.120 --> 00:03:07.439
<v Speaker 2>general purpose memory focused, even GPU powered instances. Sometimes you

57
00:03:07.479 --> 00:03:10.120
<v Speaker 2>can define your min and max instances tweak the scaling

58
00:03:10.159 --> 00:03:12.960
<v Speaker 2>behavior to match exactly what you need. This moves way

59
00:03:13.000 --> 00:03:17.360
<v Speaker 2>beyond traditional infrastructure as a service where you'd be managing

60
00:03:17.439 --> 00:03:21.000
<v Speaker 2>VMS and operating systems yourself. ACA handles all that set

61
00:03:21.080 --> 00:03:24.360
<v Speaker 2>up in scaling automatically. It really does abstract away that

62
00:03:24.479 --> 00:03:25.479
<v Speaker 2>operational burden.

63
00:03:25.800 --> 00:03:27.960
<v Speaker 1>That's a huge shift, and it sounds like it's inherently

64
00:03:28.039 --> 00:03:30.280
<v Speaker 1>suited for micro services. Is that one of his main

65
00:03:30.439 --> 00:03:31.080
<v Speaker 1>use cases?

66
00:03:31.159 --> 00:03:35.280
<v Speaker 2>Absolutely, it's perfect for micro services architectures because containers, while

67
00:03:35.280 --> 00:03:38.280
<v Speaker 2>they're the ideal way to package and deploy these independent services,

68
00:03:38.319 --> 00:03:42.560
<v Speaker 2>aren't they the insurer services are isolated, portable, consistent across

69
00:03:42.560 --> 00:03:45.680
<v Speaker 2>different environments. ACA just makes managing a whole bunch of

70
00:03:45.680 --> 00:03:51.039
<v Speaker 2>microservices significantly easier. And beyond that core functionality, ACA is

71
00:03:51.120 --> 00:03:56.879
<v Speaker 2>built in monitoring and logging through Azure Monitor, seamless CICD integration. Plus,

72
00:03:56.879 --> 00:03:59.400
<v Speaker 2>it's built on great open source tech like Dapra, which

73
00:03:59.439 --> 00:04:02.639
<v Speaker 2>we'll talk more out, Keta for scaling, and Envoy for networking.

74
00:04:03.039 --> 00:04:07.159
<v Speaker 2>That open source foundation means transparency and flexibility, which honestly

75
00:04:07.280 --> 00:04:08.599
<v Speaker 2>is a huge win for developers.

76
00:04:08.879 --> 00:04:11.599
<v Speaker 1>That's a pretty comprehensive feature set. Now for those of

77
00:04:11.680 --> 00:04:14.520
<v Speaker 1>us trying to place ACA in the let's say the

78
00:04:14.560 --> 00:04:18.360
<v Speaker 1>wider Azure World. How does it stack up against Azure

79
00:04:18.399 --> 00:04:20.680
<v Speaker 1>App Services or even AKS right.

80
00:04:20.560 --> 00:04:23.480
<v Speaker 2>That's a crucial distinction to make, as your app services

81
00:04:23.720 --> 00:04:26.600
<v Speaker 2>is more of a pitess platform as a service, it

82
00:04:26.720 --> 00:04:30.120
<v Speaker 2>hides a lot of the infrastructure, gives you a managed runtime. ACA,

83
00:04:30.160 --> 00:04:33.399
<v Speaker 2>on the other hand, is distinctly container centric. It offers

84
00:04:33.439 --> 00:04:37.160
<v Speaker 2>more granular control over the container environment itself, and you

85
00:04:37.199 --> 00:04:41.759
<v Speaker 2>get more precise scaling tightly integrated with those container orchestration capabilities.

86
00:04:42.199 --> 00:04:45.439
<v Speaker 2>It's really about flexibility for containerized apps now. Comparing to

87
00:04:45.480 --> 00:04:49.560
<v Speaker 2>azur Kupernetes service, AKAS AKS provides really deep, fine grain

88
00:04:49.639 --> 00:04:53.319
<v Speaker 2>control over Kupernetes itself, but that requires significant expertise to

89
00:04:53.360 --> 00:04:57.279
<v Speaker 2>manage and operate effectively. ACA, even though it's built on Kupernetes,

90
00:04:57.319 --> 00:04:59.800
<v Speaker 2>it abstracts away those complexities. It offers a much more

91
00:05:00.040 --> 00:05:03.759
<v Speaker 2>dreamline developer experience. So it's a choice really deep control

92
00:05:03.800 --> 00:05:07.360
<v Speaker 2>with AKAS or simplified faster development with ACA, where you

93
00:05:07.399 --> 00:05:10.120
<v Speaker 2>get the KS benefits without needing to master every single

94
00:05:10.160 --> 00:05:11.839
<v Speaker 2>operational detail. Got it.

95
00:05:12.360 --> 00:05:15.600
<v Speaker 1>Now, let's start to a practical application. The book uses

96
00:05:15.639 --> 00:05:19.040
<v Speaker 1>a really clear hands on example an expense management solution

97
00:05:19.199 --> 00:05:21.519
<v Speaker 1>using micro services. Can you give us a snapshot of

98
00:05:21.560 --> 00:05:24.959
<v Speaker 1>what that application looks like and how its core parts

99
00:05:25.000 --> 00:05:26.000
<v Speaker 1>get deployed initially.

100
00:05:26.079 --> 00:05:28.839
<v Speaker 2>Sure thing. The Benefits Manager application in the book is

101
00:05:28.879 --> 00:05:32.439
<v Speaker 2>a great real world demo of ACA, Dopra, and Keto

102
00:05:32.600 --> 00:05:36.560
<v Speaker 2>working together. It lets external users, say employees submit expenses

103
00:05:36.600 --> 00:05:40.079
<v Speaker 2>and internal users administrators they review them. The core micro

104
00:05:40.120 --> 00:05:42.879
<v Speaker 2>services involved are things like an ACA web app frontend

105
00:05:42.920 --> 00:05:46.079
<v Speaker 2>that's a Blazer server app for managing the expenses. Then

106
00:05:46.120 --> 00:05:49.000
<v Speaker 2>an ACA Web API BFF you know, back end for

107
00:05:49.079 --> 00:05:52.800
<v Speaker 2>frontend it's a minimal sp dot Net API holding the

108
00:05:52.800 --> 00:05:56.120
<v Speaker 2>business logic specifically for that front end. There's an ACA

109
00:05:56.240 --> 00:05:59.199
<v Speaker 2>processor back end that's an event driven background thing for

110
00:05:59.279 --> 00:06:02.759
<v Speaker 2>tasks like sending emails, an ACA mail search service hosting

111
00:06:02.759 --> 00:06:04.879
<v Speaker 2>an open source search engine, and then a couple of

112
00:06:04.879 --> 00:06:08.199
<v Speaker 2>ACA jobs, an indexer service and a scheduled service maybe

113
00:06:08.199 --> 00:06:09.079
<v Speaker 2>for nightly reports.

114
00:06:09.120 --> 00:06:11.639
<v Speaker 1>Wow. Okay, that's quite a collection of services. Definitely highlights

115
00:06:11.639 --> 00:06:14.399
<v Speaker 1>a modern distributed approach. So how do they go from

116
00:06:14.439 --> 00:06:16.800
<v Speaker 1>code on a dev machine to actually running in Azure

117
00:06:16.839 --> 00:06:17.639
<v Speaker 1>container apps?

118
00:06:17.759 --> 00:06:20.639
<v Speaker 2>Right? So, the initial deployment, which the book covers in

119
00:06:20.720 --> 00:06:24.399
<v Speaker 2>chapters two and three, starts pretty standardly. Create the back

120
00:06:24.519 --> 00:06:27.759
<v Speaker 2>end API, create the Blazer front end. But the process

121
00:06:27.800 --> 00:06:32.240
<v Speaker 2>shows key steps. First containerization packaging both the API and

122
00:06:32.279 --> 00:06:36.800
<v Speaker 2>the Blazer app into Docker containers standard stuff. Then using

123
00:06:36.800 --> 00:06:40.959
<v Speaker 2>Azure Container Registry ACR. It's a managed Azure service to

124
00:06:41.040 --> 00:06:45.160
<v Speaker 2>store and manage those container images. It handles off integrates

125
00:06:45.160 --> 00:06:49.959
<v Speaker 2>with CICD pipelines. Finally deploying to ACA itself. This involves

126
00:06:50.000 --> 00:06:53.480
<v Speaker 2>creating some Azure infrastructure first, like a log analytics workspace

127
00:06:53.519 --> 00:06:57.040
<v Speaker 2>for logging, application insights for tracing. Then the container apps

128
00:06:57.040 --> 00:06:59.120
<v Speaker 2>are deployed into an ACA environment, so.

129
00:06:59.079 --> 00:07:02.199
<v Speaker 1>A full life cycle from dev to deployed and monitored.

130
00:07:02.480 --> 00:07:05.800
<v Speaker 1>Did the book offer any practical security tips during this

131
00:07:05.839 --> 00:07:06.920
<v Speaker 1>initial setup.

132
00:07:06.680 --> 00:07:09.399
<v Speaker 2>Yes, it did. A really crucial security insight comes right

133
00:07:09.439 --> 00:07:12.199
<v Speaker 2>after deploying the front end. The book shows updating the

134
00:07:12.240 --> 00:07:15.360
<v Speaker 2>back end web API's ingress setting from external to internal.

135
00:07:15.439 --> 00:07:16.480
<v Speaker 1>Oh okay, what does that do?

136
00:07:16.879 --> 00:07:19.879
<v Speaker 2>It means the back end API becomes accessible only by

137
00:07:19.920 --> 00:07:23.680
<v Speaker 2>other applications running within the same Azure container environment. This

138
00:07:23.800 --> 00:07:28.319
<v Speaker 2>massively enhances security by blocking direct public Internet access to

139
00:07:28.399 --> 00:07:31.319
<v Speaker 2>your back end services. It shows how you tailor can

140
00:07:31.360 --> 00:07:33.959
<v Speaker 2>figs for real world security, not just theory.

141
00:07:34.399 --> 00:07:37.000
<v Speaker 1>Right. Locking down access between services makes sense?

142
00:07:37.079 --> 00:07:37.279
<v Speaker 2>Right?

143
00:07:37.319 --> 00:07:39.839
<v Speaker 1>So okay, we've got our micro services running an ACA.

144
00:07:40.480 --> 00:07:43.279
<v Speaker 1>But distributed systems, like you mentioned, they have their own challenges,

145
00:07:43.399 --> 00:07:47.439
<v Speaker 1>right state management, finding other services, secure communication. This is

146
00:07:47.480 --> 00:07:49.879
<v Speaker 1>where depro comes in. I gather and it seems like

147
00:07:49.920 --> 00:07:51.360
<v Speaker 1>depth really simplifies all of this.

148
00:07:51.600 --> 00:07:55.120
<v Speaker 2>That's exactly right. DAP the Distributed Application run Time. It's

149
00:07:55.160 --> 00:08:00.000
<v Speaker 2>open source, portable, event driven designed specifically to make building, resilience,

150
00:08:00.240 --> 00:08:04.480
<v Speaker 2>scalable micro services easier. It was originally launched by Microsoft,

151
00:08:04.519 --> 00:08:07.000
<v Speaker 2>but now it's a graduated project in the CNCF, the

152
00:08:07.040 --> 00:08:10.759
<v Speaker 2>Cloud Nedive Computing Foundation, so it's got broad industry backing.

153
00:08:11.319 --> 00:08:14.439
<v Speaker 2>Dapper's whole purpose is basically debstract away those common tricky

154
00:08:14.480 --> 00:08:18.120
<v Speaker 2>parts of distributed systems. Let's developers focus purely on their

155
00:08:18.160 --> 00:08:19.120
<v Speaker 2>application code.

156
00:08:19.360 --> 00:08:23.720
<v Speaker 1>A distributed Application run time sounds powerful, Yeah, but how

157
00:08:23.759 --> 00:08:26.079
<v Speaker 1>does it actually integrate with my application? Does it add

158
00:08:26.120 --> 00:08:29.079
<v Speaker 1>a ton of new code or dependencies right into my

159
00:08:29.120 --> 00:08:29.680
<v Speaker 1>core logic?

160
00:08:29.839 --> 00:08:31.600
<v Speaker 2>No, and that's the beauty of it. It uses what's

161
00:08:31.600 --> 00:08:35.120
<v Speaker 2>called the sidecar approach. DAPPER runs alongside your application as

162
00:08:35.120 --> 00:08:37.960
<v Speaker 2>a separate process. A sidecar doesn't matter if you're running

163
00:08:38.000 --> 00:08:41.279
<v Speaker 2>locally or in the cloud like ACA. Your application just

164
00:08:41.360 --> 00:08:44.720
<v Speaker 2>talks to its local Dapper sidecar, usually over standard HGTP

165
00:08:44.879 --> 00:08:48.600
<v Speaker 2>or gRPC calls, and that sidecar then handles the complexities

166
00:08:48.639 --> 00:08:51.399
<v Speaker 2>talking to state stores, message brokers, other services.

167
00:08:51.519 --> 00:08:54.360
<v Speaker 1>Okay, so the app talks to Dapper, Dapper talks.

168
00:08:54.159 --> 00:08:57.200
<v Speaker 2>To the world pretty much. You know. Before Dapper trying

169
00:08:57.240 --> 00:09:01.000
<v Speaker 2>to implement, say state management or service discovery car micro services,

170
00:09:01.559 --> 00:09:03.879
<v Speaker 2>it often felt like building a custom bridge for every

171
00:09:03.879 --> 00:09:08.399
<v Speaker 2>single river crossing, super time consuming, error prone. Dapper basically

172
00:09:08.399 --> 00:09:12.279
<v Speaker 2>gives you a standardized, configurable bridge kit for all those rivers.

173
00:09:12.559 --> 00:09:14.879
<v Speaker 2>It abstracts away the plumbing, lets you focus on your

174
00:09:14.919 --> 00:09:17.919
<v Speaker 2>actual business logic, and when your application scales, the Dapper

175
00:09:17.960 --> 00:09:19.559
<v Speaker 2>sidecar scales right alongside it.

176
00:09:19.840 --> 00:09:22.039
<v Speaker 1>That's a really clever way to keep the application code

177
00:09:22.039 --> 00:09:24.879
<v Speaker 1>itself clean. So what are some of these complexities that

178
00:09:25.000 --> 00:09:27.440
<v Speaker 1>Dapper handles Through these building blocks you.

179
00:09:27.399 --> 00:09:30.960
<v Speaker 2>Mentioned right, the DAP prab building blocks. They encapsulate best

180
00:09:31.000 --> 00:09:34.799
<v Speaker 2>practices for common patterns. There's service to service invocation for

181
00:09:34.879 --> 00:09:39.600
<v Speaker 2>secure communication between your micro services, state management for reliable

182
00:09:39.639 --> 00:09:43.240
<v Speaker 2>ways to save and retrieve, state publish and subscribe or

183
00:09:43.320 --> 00:09:47.519
<v Speaker 2>pub sub for asynchronous messaging bindings which we'll get to

184
00:09:47.759 --> 00:09:51.200
<v Speaker 2>for connecting to external systems, and even things like workflows

185
00:09:51.200 --> 00:09:54.879
<v Speaker 2>and jobs for orchestration and scheduling. When you integrate DAPER

186
00:09:54.919 --> 00:09:58.279
<v Speaker 2>into ACA, you automatically get features like automatic retries on

187
00:09:58.320 --> 00:10:02.960
<v Speaker 2>service calls, secure communit cation using MUTUALTLS, access control policies,

188
00:10:03.279 --> 00:10:06.919
<v Speaker 2>plus comprehensive traces and metrics for diagnostics, all flowing into

189
00:10:06.919 --> 00:10:10.679
<v Speaker 2>tools like Application Insights. It injects these useful cross cutting

190
00:10:10.720 --> 00:10:11.840
<v Speaker 2>behaviors transparently.

191
00:10:12.000 --> 00:10:14.879
<v Speaker 1>Wow, that's a lot of crucial functionality just handle. Can

192
00:10:14.919 --> 00:10:16.720
<v Speaker 1>you give us a concrete example, like, how does that

193
00:10:16.799 --> 00:10:20.480
<v Speaker 1>state management building block really make a difference in practice?

194
00:10:20.679 --> 00:10:24.559
<v Speaker 2>Yeah? The book illustrates this really well with DAP state management. Initially,

195
00:10:24.720 --> 00:10:27.759
<v Speaker 2>the example claims manager back ends stores its data locally

196
00:10:27.840 --> 00:10:31.799
<v Speaker 2>using REDTIS that's configured via a simple YAML file telling

197
00:10:31.840 --> 00:10:34.919
<v Speaker 2>Dapper use reddus for state. But here's where it gets

198
00:10:34.960 --> 00:10:38.120
<v Speaker 2>really powerful. Without changing any of the application code that

199
00:10:38.279 --> 00:10:41.559
<v Speaker 2>saves or loads data, no code changes it all none,

200
00:10:41.960 --> 00:10:45.919
<v Speaker 2>zero code changes it. Then seamlessly switches to using azure

201
00:10:45.960 --> 00:10:49.960
<v Speaker 2>Cosmos dB as the state store instead. This shows dapper's

202
00:10:49.960 --> 00:10:53.960
<v Speaker 2>plugable component model in action, same application code, different underlying

203
00:10:53.960 --> 00:10:58.759
<v Speaker 2>state store. Dapper abstracts away the implementation details. Your code

204
00:10:58.840 --> 00:11:01.600
<v Speaker 2>just uses the Dapper client SDK to call something like

205
00:11:01.679 --> 00:11:05.080
<v Speaker 2>save state acinc or get state entry async. Dapper figures

206
00:11:05.080 --> 00:11:07.159
<v Speaker 2>out where to save it based on the configuration.

207
00:11:07.440 --> 00:11:10.759
<v Speaker 1>That's huge for flexibility and avoiding vendor lock in. And

208
00:11:10.840 --> 00:11:14.279
<v Speaker 1>how does dapprehandle security for those state stores, especially in Azure?

209
00:11:14.600 --> 00:11:16.159
<v Speaker 1>Is it managing connection strings?

210
00:11:16.320 --> 00:11:19.879
<v Speaker 2>Good question for cloud deployments Like with Cosmos dB, Dapper

211
00:11:19.960 --> 00:11:23.519
<v Speaker 2>leverages Azure managed identities. This completely eliminates the need to

212
00:11:23.559 --> 00:11:26.720
<v Speaker 2>store or manage sensitive connection strengths directly in your application

213
00:11:26.799 --> 00:11:27.679
<v Speaker 2>code or configuration.

214
00:11:28.000 --> 00:11:30.120
<v Speaker 1>AH managed identities good Exactly.

215
00:11:30.159 --> 00:11:32.879
<v Speaker 2>You assign a system managed identity to your container app

216
00:11:32.879 --> 00:11:35.639
<v Speaker 2>in ACA, then you grant that identity a role like

217
00:11:35.759 --> 00:11:40.480
<v Speaker 2>Cosmos dB built in data contributor on your Cosmos dB instance.

218
00:11:40.960 --> 00:11:44.879
<v Speaker 2>Dapper uses that identity automatically to authenticate securely. It's a

219
00:11:44.879 --> 00:11:49.279
<v Speaker 2>crucial security best practice. Simplifies credential management immensely.

220
00:11:49.519 --> 00:11:53.360
<v Speaker 1>Okay, so that's state. What about building loosely coupled systems?

221
00:11:53.399 --> 00:11:56.240
<v Speaker 1>The book also dives into Dapper's pub sub pattern for

222
00:11:56.279 --> 00:11:59.279
<v Speaker 1>acin communication. Why is that so important for micro services

223
00:11:59.320 --> 00:12:00.360
<v Speaker 1>and how does Dapper help.

224
00:12:00.639 --> 00:12:04.159
<v Speaker 2>Yeah, loose coupling is absolutely vital for resilient micro services.

225
00:12:04.559 --> 00:12:07.039
<v Speaker 2>It means your services don't need direct knowledge of each other.

226
00:12:07.080 --> 00:12:09.919
<v Speaker 2>They don't need to know implementation details or even if

227
00:12:09.919 --> 00:12:12.720
<v Speaker 2>a consumer service is available writ when a message is sent,

228
00:12:13.240 --> 00:12:17.039
<v Speaker 2>the dapperpub sub building block abstracts away the complexities of

229
00:12:17.039 --> 00:12:20.799
<v Speaker 2>the underlying message broker, whether it's reddis rabit, MQ as

230
00:12:20.799 --> 00:12:25.200
<v Speaker 2>your service bus. It provides a single consistent API for sending, publishing,

231
00:12:25.320 --> 00:12:29.279
<v Speaker 2>and receiving subscribing to messages. Publishers just send messages to

232
00:12:29.360 --> 00:12:32.720
<v Speaker 2>a name topic. Any interested subscribers receive them without the

233
00:12:32.720 --> 00:12:35.759
<v Speaker 2>publisher knowing who or how many subscribers there are. This

234
00:12:35.879 --> 00:12:38.320
<v Speaker 2>drastically improves resilience and scalability.

235
00:12:38.440 --> 00:12:40.440
<v Speaker 1>That makes a lot of sense for event riven designs.

236
00:12:40.679 --> 00:12:44.120
<v Speaker 1>How does the example application, the Benefits Manager, use this right?

237
00:12:44.440 --> 00:12:47.279
<v Speaker 2>This is where the app introduces that new background service,

238
00:12:47.679 --> 00:12:51.200
<v Speaker 2>the ACA processor back end. Its only job is to

239
00:12:51.240 --> 00:12:55.000
<v Speaker 2>process messages received from a queue, for instance, sending emails

240
00:12:55.039 --> 00:12:58.720
<v Speaker 2>when an expense claim status changes. This offloads that task

241
00:12:58.799 --> 00:13:01.879
<v Speaker 2>from the main APS service, keeping the API focused just

242
00:13:01.960 --> 00:13:06.120
<v Speaker 2>on managing claims data improves responsiveness, keeps things separate. The

243
00:13:06.120 --> 00:13:08.919
<v Speaker 2>book first shows this locally using RDDUS again, but this

244
00:13:09.039 --> 00:13:12.480
<v Speaker 2>time as the message brooker configured with a pubsub dot

245
00:13:12.600 --> 00:13:15.960
<v Speaker 2>YAML file. The API publishes messages to a topic maybe

246
00:13:15.960 --> 00:13:19.120
<v Speaker 2>claim save topic, and the back end processor consumes messages.

247
00:13:18.759 --> 00:13:20.440
<v Speaker 1>From that topic. And I assume when you move to

248
00:13:20.480 --> 00:13:23.960
<v Speaker 1>the cloud, Dapper simplifies that transition too, like it did for.

249
00:13:23.919 --> 00:13:27.759
<v Speaker 2>State, exactly the same principle for cloud readiness. The implementation

250
00:13:27.879 --> 00:13:31.000
<v Speaker 2>then shifts easily to Azure service Bus. You provision a

251
00:13:31.000 --> 00:13:33.440
<v Speaker 2>service bus name, space and a topic in Azure, then

252
00:13:33.480 --> 00:13:36.519
<v Speaker 2>you just update the Dapper component configuration YAML to point

253
00:13:36.519 --> 00:13:39.159
<v Speaker 2>to Azure service Bus instead of reddis and crucially in

254
00:13:39.240 --> 00:13:42.720
<v Speaker 2>Azure Container apps, authentication with service bus also switches to

255
00:13:42.799 --> 00:13:45.559
<v Speaker 2>using managed identities, just like we saw with Cosmos dB,

256
00:13:46.080 --> 00:13:47.360
<v Speaker 2>no connection strings needed.

257
00:13:47.639 --> 00:13:52.200
<v Speaker 1>That consistency and configuration and security across different services is

258
00:13:52.240 --> 00:13:55.279
<v Speaker 1>really appealing. Can you walk us through how a publisher

259
00:13:55.279 --> 00:13:58.159
<v Speaker 1>and subscriber actually work with Dapper pub sub in this scenario?

260
00:13:58.519 --> 00:13:59.600
<v Speaker 1>The mechanics of it.

261
00:13:59.600 --> 00:14:02.480
<v Speaker 2>Sure On the publisher side. Let's say the claims manager

262
00:14:02.480 --> 00:14:05.279
<v Speaker 2>back end API needs to publish an event. It uses

263
00:14:05.320 --> 00:14:09.240
<v Speaker 2>the DAP ray client SDK's publish event ACNC method. It

264
00:14:09.320 --> 00:14:12.039
<v Speaker 2>sends the data. Maybe the claim model specifies the pub

265
00:14:12.080 --> 00:14:15.879
<v Speaker 2>subcomponent name like dapro pub sub services and the topic

266
00:14:15.960 --> 00:14:18.919
<v Speaker 2>name claim saved Topic. Dapray handles getting it to the broker.

267
00:14:19.320 --> 00:14:22.639
<v Speaker 2>On the subscriber side. The ACA processor back end service

268
00:14:22.759 --> 00:14:26.840
<v Speaker 2>uses a simple attribute like topic. Dapropub subservice claims save

269
00:14:26.919 --> 00:14:30.399
<v Speaker 2>topic on one of its API endpoints, say Apple claims

270
00:14:30.480 --> 00:14:33.519
<v Speaker 2>notifier claim saved. When the service starts up, the DAPPER

271
00:14:33.639 --> 00:14:36.759
<v Speaker 2>sidecar actually calls a well known endpoint dap subscribe on

272
00:14:36.799 --> 00:14:40.559
<v Speaker 2>the application to discover these subscriptions. DAPRA then automatically tells

273
00:14:40.559 --> 00:14:43.320
<v Speaker 2>the message broker service bus in this case, to create

274
00:14:43.320 --> 00:14:46.240
<v Speaker 2>the necessary subscription to route messages from that topic to

275
00:14:46.360 --> 00:14:49.200
<v Speaker 2>this service. So when a message hits the topic, Dapper

276
00:14:49.279 --> 00:14:51.960
<v Speaker 2>receives it from the broker and calls the designated endpoint

277
00:14:52.039 --> 00:14:55.320
<v Speaker 2>on your service with the message payload. There's middleware involved too,

278
00:14:55.440 --> 00:14:57.519
<v Speaker 2>like app dot use cloud events to unwrap the event

279
00:14:57.600 --> 00:15:00.559
<v Speaker 2>data into a standard format, and app dot mamp subscribe

280
00:15:00.559 --> 00:15:04.159
<v Speaker 2>handler to make the subscription endpoint discoverable by Depper, But

281
00:15:04.320 --> 00:15:07.879
<v Speaker 2>mostly Dopper handles the routing and delivery behind the scenes.

282
00:15:08.080 --> 00:15:11.919
<v Speaker 1>Okay, that clarifies the pubsub mechanism. Now, building on that,

283
00:15:11.960 --> 00:15:15.799
<v Speaker 1>the book introduces Depper bindings. If pubsub is mainly for

284
00:15:15.840 --> 00:15:19.480
<v Speaker 1>communication between our own micro services, what makes bindings different?

285
00:15:19.879 --> 00:15:22.600
<v Speaker 1>How do they help us connect with systems outside our application?

286
00:15:22.720 --> 00:15:27.240
<v Speaker 2>Bauttery Exactly. That's the crucial difference. Pubsub is primarily for

287
00:15:27.519 --> 00:15:32.159
<v Speaker 2>internal asynchronous service to service communication within your distributed application.

288
00:15:33.080 --> 00:15:37.559
<v Speaker 2>Depper bindings, however, are specifically designed for connectivity and interoperability

289
00:15:37.600 --> 00:15:41.039
<v Speaker 2>with diverse external systems or services. Think of them as

290
00:15:41.159 --> 00:15:44.519
<v Speaker 2>universal adapters or connectors. They let your application interact with

291
00:15:44.559 --> 00:15:48.440
<v Speaker 2>things like databases, message queues, cloud services like Tulio, or

292
00:15:48.480 --> 00:15:52.759
<v Speaker 2>sendrid file systems even on prem systems, all without needing

293
00:15:52.759 --> 00:15:56.399
<v Speaker 2>to write specific integration code or include SDKs for each

294
00:15:56.440 --> 00:15:58.320
<v Speaker 2>external system directly in your service.

295
00:15:58.639 --> 00:16:02.279
<v Speaker 1>So bindings are outward facing connectors. What's a practical use

296
00:16:02.320 --> 00:16:03.919
<v Speaker 1>case the book uses to illustrate this.

297
00:16:04.360 --> 00:16:06.799
<v Speaker 2>The book presents a really good scenario. Imagine there's some

298
00:16:07.000 --> 00:16:10.639
<v Speaker 2>external system totally separate from your application and it owns

299
00:16:10.639 --> 00:16:15.240
<v Speaker 2>an Azure storage queue. Your ACA processor back end needs

300
00:16:15.279 --> 00:16:18.480
<v Speaker 2>to react whenever a message lands in that external queue.

301
00:16:18.960 --> 00:16:22.200
<v Speaker 2>It uses a dapper input binding to trigger an event

302
00:16:22.279 --> 00:16:25.840
<v Speaker 2>in your service. Then, after processing the message, your service

303
00:16:25.919 --> 00:16:28.399
<v Speaker 2>might need to store the result in an Azure blob

304
00:16:28.440 --> 00:16:31.759
<v Speaker 2>storage container that also belongs to that external system. It

305
00:16:31.840 --> 00:16:34.440
<v Speaker 2>uses a Dapper output binding to do that. It really

306
00:16:34.519 --> 00:16:37.720
<v Speaker 2>demonstrates integrating seamlessly with resources that aren't part of your

307
00:16:37.799 --> 00:16:39.360
<v Speaker 2>core applications infrastructure.

308
00:16:39.480 --> 00:16:41.879
<v Speaker 1>Okay, interesting, Can you elaborate a bit on how those

309
00:16:41.879 --> 00:16:45.080
<v Speaker 1>input and output bindings actually function in that scenario without

310
00:16:45.120 --> 00:16:46.600
<v Speaker 1>getting lost in code specifics.

311
00:16:46.720 --> 00:16:50.000
<v Speaker 2>Absolutely, for the input binding to receive events from that

312
00:16:50.039 --> 00:16:53.279
<v Speaker 2>external queue, our ACA processor back end just needs to

313
00:16:53.320 --> 00:16:57.200
<v Speaker 2>register a public API endpoint maybe external claims process or process.

314
00:16:57.960 --> 00:17:02.120
<v Speaker 2>Then a simple depth binding configuringtion file. Another yemol tells

315
00:17:02.200 --> 00:17:05.119
<v Speaker 2>Dapper how to connect to that external Azure storage Q

316
00:17:05.680 --> 00:17:09.440
<v Speaker 2>stored account name, qname, maybe credentials if not using managed

317
00:17:09.519 --> 00:17:12.240
<v Speaker 2>identity for storage. Yet, when a message arrives in that

318
00:17:12.319 --> 00:17:15.680
<v Speaker 2>external queue, the Dapper sidecar's input binding component automatically picks

319
00:17:15.680 --> 00:17:18.720
<v Speaker 2>it up. It then invokes your registered apin point external

320
00:17:18.720 --> 00:17:21.839
<v Speaker 2>claims processor process sending the message content as a clean

321
00:17:22.039 --> 00:17:25.440
<v Speaker 2>JSON payload. Dapri even handles things like base sixty fourty

322
00:17:25.480 --> 00:17:28.200
<v Speaker 2>coding if needed. Because Q messages are often encoded. Your

323
00:17:28.240 --> 00:17:30.319
<v Speaker 2>application just gets clean BETA.

324
00:17:30.000 --> 00:17:32.920
<v Speaker 1>So the app doesn't even need the Azure storage SDK.

325
00:17:32.799 --> 00:17:36.880
<v Speaker 2>For queues exactly. Dappri handles the interaction now for the

326
00:17:36.920 --> 00:17:39.759
<v Speaker 2>output binding, triggering an action on the external system like

327
00:17:39.799 --> 00:17:43.160
<v Speaker 2>writing to that block container. Again, another configuration yamol tells

328
00:17:43.200 --> 00:17:47.240
<v Speaker 2>Dapper how to connect to the external Azure blob storage, container, account,

329
00:17:47.319 --> 00:17:51.039
<v Speaker 2>container name, etc. Our ACA processor back end can then

330
00:17:51.079 --> 00:17:55.160
<v Speaker 2>invoke this output binding simply by making an HTTP postd

331
00:17:55.319 --> 00:17:58.720
<v Speaker 2>call to its own Dapper sidecars binding end point like

332
00:17:58.839 --> 00:18:02.200
<v Speaker 2>v one point zero bindings, external claims, blob store, or

333
00:18:02.240 --> 00:18:05.440
<v Speaker 2>more easily using the Dapper client SDK. It passes the

334
00:18:05.480 --> 00:18:08.759
<v Speaker 2>data it wants to write. The Dapper sidecar receives this request,

335
00:18:09.000 --> 00:18:12.119
<v Speaker 2>uses the binding configuration to connect to the external blob storage,

336
00:18:12.319 --> 00:18:15.000
<v Speaker 2>and performs the operation like creating a new blog file.

337
00:18:15.319 --> 00:18:18.839
<v Speaker 2>The key takeaway again is simplification Dapper abstracts away the

338
00:18:18.880 --> 00:18:22.640
<v Speaker 2>specific SDKs and interaction patterns. For all these diverse external systems.

339
00:18:22.640 --> 00:18:24.960
<v Speaker 2>You use the same Dapper binding APIs regardless of the

340
00:18:25.000 --> 00:18:26.000
<v Speaker 2>external technology.

341
00:18:26.119 --> 00:18:29.599
<v Speaker 1>What an incredible deep dive into modern application architecture we've

342
00:18:29.599 --> 00:18:33.440
<v Speaker 1>had today, really fascinating stuff, from simplifying container deployment with

343
00:18:33.480 --> 00:18:37.319
<v Speaker 1>Azure container apps to really supercharging micro services with Dapper's

344
00:18:37.359 --> 00:18:41.440
<v Speaker 1>building block state pubsub bindings. We've seen how developers can

345
00:18:41.480 --> 00:18:46.319
<v Speaker 1>tackle these complex distributed system challenges with well surprising ease. Actually,

346
00:18:46.759 --> 00:18:49.640
<v Speaker 1>so the key takeaways for you, our listener. You've learned

347
00:18:49.640 --> 00:18:52.119
<v Speaker 1>you can gain the power of Kubernetes without necessarily being

348
00:18:52.200 --> 00:18:55.519
<v Speaker 1>a K eight expert. You can build loosely coupled systems

349
00:18:55.599 --> 00:18:59.119
<v Speaker 1>using patterns like pubsub. You can seamlessly switch underlined state

350
00:18:59.160 --> 00:19:03.400
<v Speaker 1>stores likes to COSMOSDB with no code changes. You can

351
00:19:03.440 --> 00:19:07.880
<v Speaker 1>integrate with external systems effortlessly using bindings, and deploy securely

352
00:19:07.960 --> 00:19:10.599
<v Speaker 1>using managed identities. It really is all about abstracting a

353
00:19:10.599 --> 00:19:13.519
<v Speaker 1>way that infrastructure boiler plate, isn't it, so you can

354
00:19:13.559 --> 00:19:18.079
<v Speaker 1>focus on what truly differentiates your application, the business logic itself.

355
00:19:18.599 --> 00:19:21.519
<v Speaker 1>So here's a provocative thought to leave you with. Imagine

356
00:19:21.559 --> 00:19:24.440
<v Speaker 1>the possibilities when you could build complex, scalable and resilient

357
00:19:24.440 --> 00:19:27.480
<v Speaker 1>applications without getting bogged down and all that infrastructure complexity.

358
00:19:27.559 --> 00:19:30.400
<v Speaker 1>What kind of innovative cloud native app could you build

359
00:19:30.839 --> 00:19:35.119
<v Speaker 1>if these complexities were just abstracted away, allowing your ideas

360
00:19:35.160 --> 00:19:37.640
<v Speaker 1>to truly take flight. We definitely encourage you to explore

361
00:19:37.640 --> 00:19:41.039
<v Speaker 1>these powerful tools ACA and dapriye and unlock your own

362
00:19:41.079 --> 00:19:42.599
<v Speaker 1>next generation of applications,