WEBVTT

1
00:00:00.160 --> 00:00:03.720
<v Speaker 1>Welcome to the deep dive. We take complex source material,

2
00:00:03.879 --> 00:00:06.480
<v Speaker 1>you know, dense stuff, and really pull out the actionable

3
00:00:06.480 --> 00:00:07.240
<v Speaker 1>insights you need.

4
00:00:07.320 --> 00:00:07.759
<v Speaker 2>That's right.

5
00:00:08.119 --> 00:00:12.039
<v Speaker 1>Today we're digging into the role of the modern solutions architect.

6
00:00:13.160 --> 00:00:16.079
<v Speaker 1>The essay. We've got some key excerpts here from the

7
00:00:16.120 --> 00:00:18.920
<v Speaker 1>Solutions Architect's Handbook, which is pretty much a go to

8
00:00:19.039 --> 00:00:19.839
<v Speaker 1>text in this space.

9
00:00:20.000 --> 00:00:24.640
<v Speaker 2>Yeah, it really is, and our mission today it's about synthesis.

10
00:00:24.679 --> 00:00:28.600
<v Speaker 2>Really the solutions architect role. It's super dynamic. It's evolved

11
00:00:28.679 --> 00:00:32.640
<v Speaker 2>quite a bit from the older application or it architect roles.

12
00:00:32.759 --> 00:00:34.159
<v Speaker 1>Deem change fast they do.

13
00:00:34.640 --> 00:00:37.920
<v Speaker 2>And if you're interested in this career path, maybe especially

14
00:00:37.960 --> 00:00:40.439
<v Speaker 2>the cloud solutions architect, which is probably the most common

15
00:00:40.479 --> 00:00:43.399
<v Speaker 2>type these days, well, we're aiming to give you the

16
00:00:43.399 --> 00:00:47.000
<v Speaker 2>core principles pretty quickly, the things that really drive strategic

17
00:00:47.000 --> 00:00:48.679
<v Speaker 2>decisions in modern tech.

18
00:00:48.920 --> 00:00:52.799
<v Speaker 1>That's the word strategy. We're not just like listing tasks

19
00:00:52.840 --> 00:00:54.880
<v Speaker 1>from a job description. We're trying to get to the

20
00:00:54.880 --> 00:00:57.799
<v Speaker 1>principles as is used to connect those big business goals

21
00:00:57.920 --> 00:01:01.280
<v Speaker 1>you know, speed, cost with the actual tech choices and

22
00:01:01.320 --> 00:01:04.799
<v Speaker 1>system design. It's about understanding the trade offs they manage

23
00:01:04.840 --> 00:01:08.000
<v Speaker 1>all the time. Okay, so let's let's unpack this, say,

24
00:01:08.120 --> 00:01:10.920
<v Speaker 1>roll a bit. The source material points out it's complex

25
00:01:11.319 --> 00:01:15.480
<v Speaker 1>partly because those old lines between it jobs developer, DBA

26
00:01:15.680 --> 00:01:18.000
<v Speaker 1>Security guide they're getting really blurry.

27
00:01:17.680 --> 00:01:20.640
<v Speaker 2>Now, very blurry. And the essay there are the ones

28
00:01:20.680 --> 00:01:23.719
<v Speaker 2>with that end to end ownership, right from the initial

29
00:01:23.719 --> 00:01:25.599
<v Speaker 2>idea through to deployment.

30
00:01:25.319 --> 00:01:27.879
<v Speaker 1>End to end. That's a lot of responsibility. It is.

31
00:01:27.920 --> 00:01:31.840
<v Speaker 2>They're fundamentally bridge builders. It often starts with translating what

32
00:01:32.000 --> 00:01:35.719
<v Speaker 2>users actually need into requirements you can measure. We talk

33
00:01:35.719 --> 00:01:39.120
<v Speaker 2>about functional requirements with the system does honestly the big

34
00:01:39.239 --> 00:01:43.120
<v Speaker 2>architectural choices, they're usually driven by the non functional.

35
00:01:42.640 --> 00:01:45.400
<v Speaker 1>Requirements ah right, things like how fast it needs to be,

36
00:01:45.519 --> 00:01:48.359
<v Speaker 1>or how secure or how many users it needs to.

37
00:01:48.359 --> 00:01:53.879
<v Speaker 2>Support exactly latency, security scale. Those characteristics really dictate the design.

38
00:01:54.359 --> 00:01:57.040
<v Speaker 2>You know, if the system has to handle say a

39
00:01:57.280 --> 00:02:00.719
<v Speaker 2>million users at once, that's a non functional requirement. That

40
00:02:00.799 --> 00:02:04.480
<v Speaker 2>single need. It pretty much defines your database choice, your

41
00:02:04.519 --> 00:02:06.680
<v Speaker 2>network set up, your whole cloud strategy.

42
00:02:07.120 --> 00:02:07.719
<v Speaker 1>Wow, okay.

43
00:02:07.959 --> 00:02:12.080
<v Speaker 2>And beyond just requirements, the essays constantly juggling constraints, often

44
00:02:12.240 --> 00:02:15.400
<v Speaker 2>high stakes ones. They have to make these really critical

45
00:02:15.439 --> 00:02:18.719
<v Speaker 2>technology selections, you know, often getting into that big debate

46
00:02:19.199 --> 00:02:21.719
<v Speaker 2>do we build this ourselves or do we buy a

47
00:02:21.719 --> 00:02:22.520
<v Speaker 2>third party tool?

48
00:02:22.639 --> 00:02:24.719
<v Speaker 1>The classic build versus.

49
00:02:24.400 --> 00:02:27.800
<v Speaker 2>Buy right and that choice It isn't purely technical, it's

50
00:02:27.879 --> 00:02:30.960
<v Speaker 2>kind of a fundamental bet. Really, you're betting on future

51
00:02:31.000 --> 00:02:34.479
<v Speaker 2>flexibility versus maybe immediate cost savings or speed.

52
00:02:34.599 --> 00:02:36.759
<v Speaker 1>It sounds like what sounds like they could easily get

53
00:02:36.759 --> 00:02:39.560
<v Speaker 1>pulled in too many directions. Yeah, if they're talking to stakeholders,

54
00:02:39.599 --> 00:02:43.479
<v Speaker 1>defining requirements, making these huge bill by calls, handling constraints,

55
00:02:44.120 --> 00:02:45.840
<v Speaker 1>are they basically doing three jobs?

56
00:02:46.639 --> 00:02:48.680
<v Speaker 2>It can feel like that sometimes, I bet, but it's

57
00:02:48.719 --> 00:02:51.520
<v Speaker 2>all sort of unified by one goal managing risk, Okay,

58
00:02:51.560 --> 00:02:54.240
<v Speaker 2>which is why a really key part of their jobs

59
00:02:54.319 --> 00:02:58.280
<v Speaker 2>is discovering risks early. They'll often build a proof of concept,

60
00:02:58.400 --> 00:03:01.240
<v Speaker 2>a pose or maybe a proto type quite early on.

61
00:03:01.680 --> 00:03:03.479
<v Speaker 1>So not just coding for fun.

62
00:03:03.400 --> 00:03:06.560
<v Speaker 2>Definitely not. It's about proving that the tech stack you've

63
00:03:06.599 --> 00:03:09.919
<v Speaker 2>picked can actually handle the trickiest requirements before you commit

64
00:03:10.000 --> 00:03:13.479
<v Speaker 2>huge amounts of resources. It's de risking the whole project.

65
00:03:13.800 --> 00:03:16.520
<v Speaker 1>What's really interesting, and the source mentioned this, is that

66
00:03:16.560 --> 00:03:19.919
<v Speaker 1>the first draft of the architecture often happens incredibly early,

67
00:03:20.400 --> 00:03:23.000
<v Speaker 1>like sometimes even during pre sales, when they're just putting

68
00:03:23.039 --> 00:03:23.960
<v Speaker 1>together an RFP.

69
00:03:23.879 --> 00:03:27.400
<v Speaker 2>Response, yeah, request for proposal or RFI request for information.

70
00:03:27.639 --> 00:03:30.800
<v Speaker 1>Right, so they're already scoping the tech solution, figuring out

71
00:03:30.800 --> 00:03:35.439
<v Speaker 1>the parts, estimating complexity and resources before the contract's even signed.

72
00:03:35.840 --> 00:03:39.840
<v Speaker 2>Absolutely, they're making informed technical bets essentially to help win

73
00:03:39.879 --> 00:03:43.120
<v Speaker 2>the business in the first place. And those early bets, well,

74
00:03:43.199 --> 00:03:46.199
<v Speaker 2>they need to be built on something solid, right, which

75
00:03:46.240 --> 00:03:50.199
<v Speaker 2>brings us neatly to these foundational design attributes or pillars

76
00:03:50.439 --> 00:03:53.400
<v Speaker 2>that really define a good solution. Every decision and essay

77
00:03:53.400 --> 00:03:55.680
<v Speaker 2>makes it kind of needs to map back to these pillars,

78
00:03:56.080 --> 00:03:58.919
<v Speaker 2>especially now with cloud computing completely changing the game.

79
00:03:59.000 --> 00:04:03.439
<v Speaker 1>Yeah, the cloud changed there. Yeah, Okay, let's start with growth, scalability,

80
00:04:04.439 --> 00:04:07.479
<v Speaker 1>the system's ability to handle more work. Why did the

81
00:04:07.479 --> 00:04:10.439
<v Speaker 1>cloud make this so much well easier.

82
00:04:10.439 --> 00:04:13.800
<v Speaker 2>Basically because of elasticity. Think about the old days traditional it.

83
00:04:14.199 --> 00:04:16.439
<v Speaker 2>If you needed more capacity, you had to order hardware

84
00:04:16.560 --> 00:04:18.160
<v Speaker 2>that could take what four to six months?

85
00:04:18.199 --> 00:04:19.319
<v Speaker 1>Yeah, easily, And if you got.

86
00:04:19.240 --> 00:04:23.040
<v Speaker 2>It wrong exactly under provision and your system falls over

87
00:04:23.120 --> 00:04:26.639
<v Speaker 2>during peak times over provision, and you've got expensive servers

88
00:04:26.680 --> 00:04:28.279
<v Speaker 2>just sitting there doing nothing.

89
00:04:28.160 --> 00:04:31.000
<v Speaker 1>Just burning money, a constant guessing game.

90
00:04:31.240 --> 00:04:34.680
<v Speaker 2>Right, Cloud elasticity means we can grow and shrink capacity

91
00:04:34.720 --> 00:04:39.079
<v Speaker 2>almost instantly on demand, and the strategic way says usually

92
00:04:39.079 --> 00:04:42.639
<v Speaker 2>achieve this is through horizontal scaling, adding more machines, not

93
00:04:42.680 --> 00:04:46.160
<v Speaker 2>just making one bigger. Okay, scale out, not up precisely.

94
00:04:46.439 --> 00:04:49.519
<v Speaker 2>And a really key technical decision to enable that is

95
00:04:49.600 --> 00:04:53.759
<v Speaker 2>decoupling user sessions from the actual application server. Instance.

96
00:04:53.920 --> 00:04:56.160
<v Speaker 1>Ah, so you don't store the user shopping cart on

97
00:04:56.199 --> 00:04:56.959
<v Speaker 1>the web server.

98
00:04:56.759 --> 00:04:59.079
<v Speaker 2>They happen to hit exactly. You store that session state

99
00:04:59.120 --> 00:05:03.439
<v Speaker 2>somewhere else, an independent layer that's highly available, like a

100
00:05:03.439 --> 00:05:07.000
<v Speaker 2>no SQL database maybe yeah, Amazon DynamoDB or Mango dB

101
00:05:07.120 --> 00:05:07.639
<v Speaker 2>something like that.

102
00:05:07.680 --> 00:05:08.040
<v Speaker 1>Gotcha.

103
00:05:08.160 --> 00:05:11.519
<v Speaker 2>The insight there is by making the application server stateless,

104
00:05:11.560 --> 00:05:14.519
<v Speaker 2>you can suddenly add or remove hundreds of them instantly

105
00:05:14.519 --> 00:05:17.600
<v Speaker 2>without anyone losing their work, and no SQL databases, with

106
00:05:17.639 --> 00:05:20.160
<v Speaker 2>their speed and flexible schemas, are often perfect for that.

107
00:05:20.560 --> 00:05:23.839
<v Speaker 1>Okay, moving on too, reliability. The sources talk a lot

108
00:05:23.879 --> 00:05:27.720
<v Speaker 1>about resiliency. Specifically, this idea of self healing systems that

109
00:05:27.800 --> 00:05:30.680
<v Speaker 1>recover from problems without a human stepping in sounds a

110
00:05:30.680 --> 00:05:31.920
<v Speaker 1>bit like sci fi still.

111
00:05:31.759 --> 00:05:34.000
<v Speaker 2>Eh, maybe a few years ago, but it's pretty standard

112
00:05:34.000 --> 00:05:37.839
<v Speaker 2>engineering now. It's almost mandatory. Think about a load balancer.

113
00:05:38.279 --> 00:05:41.439
<v Speaker 2>It's not just directing traffic. It's constantly checking the health

114
00:05:41.439 --> 00:05:44.199
<v Speaker 2>of the servers behind it. Bick a health check exactly

115
00:05:44.600 --> 00:05:47.439
<v Speaker 2>If it, season instance, isn't responding right, boom, it pulls

116
00:05:47.439 --> 00:05:51.240
<v Speaker 2>it out of rotation immediately, and then usually through an

117
00:05:51.279 --> 00:05:54.439
<v Speaker 2>auto scaling group, it tells the system to spin up

118
00:05:54.480 --> 00:05:58.319
<v Speaker 2>a brand new, healthy replacement. The end user they probably

119
00:05:58.360 --> 00:06:00.759
<v Speaker 2>never even notice itself.

120
00:06:00.879 --> 00:06:04.319
<v Speaker 1>Okay, that handles small, localized failures. But what about you know,

121
00:06:04.480 --> 00:06:06.920
<v Speaker 1>the big stuff, real disasters, right.

122
00:06:06.759 --> 00:06:10.279
<v Speaker 2>That's where disaster recovery, dr and business continuity planning come in.

123
00:06:10.680 --> 00:06:14.079
<v Speaker 2>The strategic thinking here is all about geography and redundancy,

124
00:06:14.160 --> 00:06:18.839
<v Speaker 2>threading things out way out. For a critical global business,

125
00:06:18.920 --> 00:06:22.000
<v Speaker 2>like say a payment processor, the essay has to plan

126
00:06:22.120 --> 00:06:26.240
<v Speaker 2>for enough it resources in a completely different region, maybe

127
00:06:26.240 --> 00:06:29.279
<v Speaker 2>even a different continent. The goal is simple, really. If

128
00:06:29.319 --> 00:06:33.720
<v Speaker 2>the main data center gets wiped out flood, earthquake, major

129
00:06:33.759 --> 00:06:37.839
<v Speaker 2>power outage, the business has to keep running globally. Often

130
00:06:37.879 --> 00:06:40.639
<v Speaker 2>that means failing over completely to the other regions, sometimes

131
00:06:40.639 --> 00:06:45.160
<v Speaker 2>within minutes. Okay, security, this is huge. It's not just

132
00:06:45.199 --> 00:06:47.480
<v Speaker 2>a feature you add at the end. It has to

133
00:06:47.519 --> 00:06:51.519
<v Speaker 2>be baked into the design from day one. An architectural mindset.

134
00:06:51.879 --> 00:06:55.040
<v Speaker 2>The sources really hammer this defense in depth.

135
00:06:54.759 --> 00:06:57.319
<v Speaker 1>IDEA defence in depth sounds like a layers it is.

136
00:06:57.360 --> 00:07:00.519
<v Speaker 2>It's necessary paranoia. Basically, you have to assume your outer

137
00:07:00.560 --> 00:07:03.439
<v Speaker 2>defenses will be brooched at some point. So security can't

138
00:07:03.439 --> 00:07:05.000
<v Speaker 2>just be at the edge. It needs to be applied

139
00:07:05.040 --> 00:07:07.199
<v Speaker 2>at every single layer, So not.

140
00:07:07.199 --> 00:07:09.920
<v Speaker 1>Just the main firewall at the network edge, but also

141
00:07:10.000 --> 00:07:12.399
<v Speaker 1>controls on the load balancer in the network segments, in

142
00:07:12.399 --> 00:07:15.600
<v Speaker 1>the application code itself, the database, everywhere, everywhere.

143
00:07:15.600 --> 00:07:18.920
<v Speaker 2>Absolutely. A classic example of how an essay thinks defensively

144
00:07:19.040 --> 00:07:22.720
<v Speaker 2>is designing against common web attacks like cross site scripting

145
00:07:22.879 --> 00:07:26.680
<v Speaker 2>XSS or SQL enrection as a nasty totally, so the

146
00:07:26.839 --> 00:07:30.560
<v Speaker 2>essay will mandate using something like a web application firewall

147
00:07:30.680 --> 00:07:34.319
<v Speaker 2>a wave. It sits in front and blocks known malicious

148
00:07:34.360 --> 00:07:37.800
<v Speaker 2>patterns in traffic before it even gets near your actual application.

149
00:07:38.120 --> 00:07:41.600
<v Speaker 1>Makes sense, and for some industries compliance is an optional.

150
00:07:41.680 --> 00:07:44.079
<v Speaker 1>It actually dictates the architecture from the start right.

151
00:07:44.120 --> 00:07:47.759
<v Speaker 2>Oh. Absolutely, compliance is a massive design constraint. If you're

152
00:07:47.800 --> 00:07:52.879
<v Speaker 2>in finance, for instance, dealing with payments regulations like PCIDSS,

153
00:07:53.600 --> 00:07:56.000
<v Speaker 2>they demand comprehensive logging and auditing.

154
00:07:56.120 --> 00:07:57.560
<v Speaker 1>You track everything everything.

155
00:07:57.720 --> 00:08:01.160
<v Speaker 2>The essays design must ensure that there's a clear, unchangeable

156
00:08:01.240 --> 00:08:04.879
<v Speaker 2>log trail for every single transaction, every access attempt. If

157
00:08:04.920 --> 00:08:07.240
<v Speaker 2>you mess that up, it's not just a technical problem,

158
00:08:07.240 --> 00:08:11.120
<v Speaker 2>it's finds maybe losing your license to operate serious business.

159
00:08:11.199 --> 00:08:16.560
<v Speaker 1>Okay, so we've got this solid blueprint. The architecture looks robust, scalable, secure, great,

160
00:08:17.079 --> 00:08:20.199
<v Speaker 1>But a great design is useless if you can't actually

161
00:08:20.240 --> 00:08:21.879
<v Speaker 1>build and deploy it quickly and.

162
00:08:21.839 --> 00:08:25.319
<v Speaker 2>Reliably exactly, which shifts us from those static design principles

163
00:08:25.360 --> 00:08:28.319
<v Speaker 2>to thinking about speed and efficiency and execution getting it

164
00:08:28.360 --> 00:08:30.600
<v Speaker 2>out the door. And this is where the essay really

165
00:08:30.639 --> 00:08:34.240
<v Speaker 2>needs that Agile mindset. They have to embrace continuous feedback,

166
00:08:34.360 --> 00:08:38.159
<v Speaker 2>rapid delivery. The big contrast the sources draw is with

167
00:08:38.240 --> 00:08:39.919
<v Speaker 2>the old waterfall.

168
00:08:39.399 --> 00:08:42.759
<v Speaker 1>Method right waterfall, where you plan everything up front, build

169
00:08:42.799 --> 00:08:44.440
<v Speaker 1>it all, and then show the customer at.

170
00:08:44.399 --> 00:08:46.600
<v Speaker 2>The very end yeah, and often find out it's not

171
00:08:46.720 --> 00:08:50.399
<v Speaker 2>quite what they wanted. Agile, with its short sprints, means

172
00:08:50.440 --> 00:08:55.200
<v Speaker 2>frequent checkpoints. You're focused on delivering small working pieces constantly.

173
00:08:55.480 --> 00:08:58.759
<v Speaker 1>The main benefit there isn't just speed, right, It's also

174
00:08:58.759 --> 00:09:02.600
<v Speaker 1>about catching mistakes, reducing the cost of making changes.

175
00:09:02.440 --> 00:09:06.399
<v Speaker 2>Precisely inspect and adapt. And what really enables that speed

176
00:09:06.559 --> 00:09:11.240
<v Speaker 2>and crucially reliability, it's automation. The sources are pretty clear

177
00:09:11.360 --> 00:09:14.919
<v Speaker 2>automation is the best way to kill human error, boost productivity,

178
00:09:14.919 --> 00:09:16.759
<v Speaker 2>and ultimately cut costs in the long run.

179
00:09:17.039 --> 00:09:19.679
<v Speaker 1>Okay, So if automation is non negotiable, where does the

180
00:09:19.799 --> 00:09:22.039
<v Speaker 1>say need to focus those efforts. What gets automated?

181
00:09:22.159 --> 00:09:25.000
<v Speaker 2>Well, pretty much everything you can Application testing is obvious,

182
00:09:25.480 --> 00:09:28.360
<v Speaker 2>But just as critical, maybe even more so, is automating

183
00:09:28.399 --> 00:09:30.200
<v Speaker 2>the environment itself, the infrastructure.

184
00:09:30.759 --> 00:09:32.440
<v Speaker 1>How do you automate the infrastructure?

185
00:09:32.679 --> 00:09:37.000
<v Speaker 2>That's where infrastructure as code comes in IAC tools like

186
00:09:37.039 --> 00:09:41.559
<v Speaker 2>antsable or Terraform, maybe cloud formation if you're in Awska.

187
00:09:41.879 --> 00:09:46.360
<v Speaker 2>The huge strategic win with IIC is reproducibility. You define

188
00:09:46.360 --> 00:09:51.000
<v Speaker 2>your entire environment servers, networks, databases and code. That means

189
00:09:51.039 --> 00:09:54.159
<v Speaker 2>you can stamp out identical environments repeatedly no more. It

190
00:09:54.200 --> 00:09:57.559
<v Speaker 2>worked in test problems because test is identical to production.

191
00:09:57.879 --> 00:10:00.919
<v Speaker 2>It kills configuration drifts. Ah nice, And then you automate

192
00:10:00.919 --> 00:10:05.799
<v Speaker 2>the whole release pipeline too, Continuous integration, continuous deployment CICD

193
00:10:05.960 --> 00:10:09.279
<v Speaker 2>pipelines that and shows every change goes through the same

194
00:10:09.360 --> 00:10:14.559
<v Speaker 2>automated build, test, and deploy process consistency and velocity. And finally,

195
00:10:14.679 --> 00:10:16.279
<v Speaker 2>related to all this, we need to talk about how

196
00:10:16.279 --> 00:10:19.159
<v Speaker 2>the system itself is organized, which brings us to this

197
00:10:19.279 --> 00:10:24.000
<v Speaker 2>really important design principle loose coupling. Loose coupling, Okay, fundamentally,

198
00:10:24.039 --> 00:10:28.039
<v Speaker 2>it's about minimizing the error radiuses how far things break

199
00:10:28.080 --> 00:10:28.960
<v Speaker 2>when something goes wrong.

200
00:10:29.039 --> 00:10:30.559
<v Speaker 1>Give me a picture that air radius.

201
00:10:30.879 --> 00:10:34.519
<v Speaker 2>Okay, Think of like a giant solid statue versus maybe

202
00:10:34.559 --> 00:10:38.159
<v Speaker 2>a set of Lego blocks in a tightly coupled system,

203
00:10:38.240 --> 00:10:42.879
<v Speaker 2>a monolith. If one critical part breaks, say one big

204
00:10:42.919 --> 00:10:46.840
<v Speaker 2>application server fails, everything connected to it instantly feels the pain.

205
00:10:47.200 --> 00:10:49.639
<v Speaker 2>Maybe all the web servers start getting errors. The whole

206
00:10:49.639 --> 00:10:52.360
<v Speaker 2>system can start to wabble. The blast radius is.

207
00:10:52.440 --> 00:10:54.440
<v Speaker 1>Huge, right, One thing takes down.

208
00:10:54.279 --> 00:10:57.639
<v Speaker 2>Everything pretty much, but with a loosely coupled system, more

209
00:10:57.679 --> 00:11:00.919
<v Speaker 2>like the Lego blocks. If one component one's service fails,

210
00:11:01.159 --> 00:11:03.360
<v Speaker 2>there's usually something in between, like that load balance that

211
00:11:03.440 --> 00:11:06.000
<v Speaker 2>we talked about, or a message queue. It spots the

212
00:11:06.039 --> 00:11:09.000
<v Speaker 2>failure and instantly routes traffic away from the broken bit

213
00:11:09.039 --> 00:11:09.279
<v Speaker 2>to the.

214
00:11:09.200 --> 00:11:11.559
<v Speaker 1>Healthy ones, So the damage is contained exactly.

215
00:11:11.679 --> 00:11:15.080
<v Speaker 2>Only that single failed component is impacted the blast radius

216
00:11:15.120 --> 00:11:17.080
<v Speaker 2>is tiny, much more resilient, and.

217
00:11:16.960 --> 00:11:20.000
<v Speaker 1>That idea limiting the air radius. That's kind of led

218
00:11:20.039 --> 00:11:22.240
<v Speaker 1>to the modern architectures we see everywhere.

219
00:11:21.960 --> 00:11:26.519
<v Speaker 2>Now, absolutely service oriented architecture SOA and its more modern

220
00:11:26.559 --> 00:11:30.759
<v Speaker 2>evolution micro services. That's how we achieve loose coupling today.

221
00:11:31.120 --> 00:11:34.159
<v Speaker 2>You break the application down into these small independent services.

222
00:11:34.360 --> 00:11:37.080
<v Speaker 2>Each does one thing well and they talk to each

223
00:11:37.080 --> 00:11:41.039
<v Speaker 2>other over standard lightweight ways. Often you know RESTful APIs using.

224
00:11:41.000 --> 00:11:45.240
<v Speaker 3>Jason lightweight language independence yep, and the big win teams

225
00:11:45.240 --> 00:11:49.840
<v Speaker 3>can develop, deploy, and scale their individual services independently, which

226
00:11:49.919 --> 00:11:53.240
<v Speaker 3>leads to huge gains in both development speed and overall

227
00:11:53.279 --> 00:11:54.320
<v Speaker 3>system stability.

228
00:11:54.639 --> 00:11:58.399
<v Speaker 2>It's a powerful pattern hashtag tag outro. So when you

229
00:11:58.399 --> 00:12:01.000
<v Speaker 2>pull it all together, looking back at the sources, the

230
00:12:01.000 --> 00:12:06.240
<v Speaker 2>solution's architect prole Wow, it's intensely multidisciplinary, isn't it. Definitely

231
00:12:06.279 --> 00:12:09.159
<v Speaker 2>you need deep technical chops across well, pretty much everything.

232
00:12:09.480 --> 00:12:11.960
<v Speaker 2>But just being a tech wizard isn't enough. That skill

233
00:12:12.080 --> 00:12:14.519
<v Speaker 2>has to be grounded in those crucial soft skills leadership,

234
00:12:14.720 --> 00:12:17.840
<v Speaker 2>being able to think big strategically but still sweat the details,

235
00:12:18.039 --> 00:12:21.919
<v Speaker 2>and being flexible enough to adapt when business needs inevitably change. Yeah,

236
00:12:22.000 --> 00:12:25.399
<v Speaker 2>and continuous learning. It's just table stakes, reading blogs, trying

237
00:12:25.440 --> 00:12:28.120
<v Speaker 2>new tech. You have to stay current. It's non negotiable

238
00:12:28.159 --> 00:12:29.279
<v Speaker 2>for an essay, and I.

239
00:12:29.200 --> 00:12:30.879
<v Speaker 1>Think one thing they should really stand out for you

240
00:12:31.480 --> 00:12:35.240
<v Speaker 1>the listener is this central tension. The essay constantly manages

241
00:12:36.039 --> 00:12:40.480
<v Speaker 1>the fact that performance optimization always always comes with the cost.

242
00:12:41.000 --> 00:12:41.399
<v Speaker 3>Good point.

243
00:12:41.399 --> 00:12:44.320
<v Speaker 1>You know an application doing high speed stock trading, it

244
00:12:44.399 --> 00:12:48.679
<v Speaker 1>might need sub mill second response times. Achieving that requires

245
00:12:48.879 --> 00:12:54.200
<v Speaker 1>really expensive complex architecture, specialized hardware, maybe custom network protocols.

246
00:12:54.799 --> 00:12:57.639
<v Speaker 1>You have to spend big to get that level of performance.

247
00:12:57.799 --> 00:13:00.720
<v Speaker 2>If your application is just say an intro fnel timesheet

248
00:13:00.759 --> 00:13:03.759
<v Speaker 2>system for one hundred employees, spending all that money to

249
00:13:03.759 --> 00:13:07.399
<v Speaker 2>get submillisecond latency, it's completely unjustified. There's no real business

250
00:13:07.480 --> 00:13:09.960
<v Speaker 2>value there. Every single choice, from the database you pick

251
00:13:10.000 --> 00:13:12.559
<v Speaker 2>to the cloud reagion you deploy in, it's always a

252
00:13:12.559 --> 00:13:15.919
<v Speaker 2>trade off technical perfection versus budget reality.

253
00:13:15.639 --> 00:13:17.919
<v Speaker 1>Which leads us right into our final thought for you

254
00:13:17.960 --> 00:13:20.840
<v Speaker 1>to think about for your next project or maybe when

255
00:13:20.879 --> 00:13:23.440
<v Speaker 1>you're working on right now, how do you figure out

256
00:13:23.440 --> 00:13:26.600
<v Speaker 1>that acceptable trade off the balance between pushing for the

257
00:13:26.639 --> 00:13:31.159
<v Speaker 1>absolute best performance, lowest latency, highest throughput and keeping the

258
00:13:31.200 --> 00:13:35.480
<v Speaker 1>costs both upfront capital and ongoing operational costs under control.

259
00:13:35.879 --> 00:13:38.240
<v Speaker 2>Where exactly would you draw that line for your business

260
00:13:38.240 --> 00:13:38.519
<v Speaker 2>needs