WEBVTT

1
00:00:00.160 --> 00:00:02.839
<v Speaker 1>Welcome to the deep dive. You know, if you're online

2
00:00:02.879 --> 00:00:06.440
<v Speaker 1>right now listening to this, you're using the cloud. It's everywhere,

3
00:00:06.519 --> 00:00:07.120
<v Speaker 1>it really is.

4
00:00:07.320 --> 00:00:09.599
<v Speaker 2>But it's more than just a buzzword, right, it's this

5
00:00:09.880 --> 00:00:13.199
<v Speaker 2>vast shared infrastructure that's kind of invisible.

6
00:00:12.880 --> 00:00:18.399
<v Speaker 1>Exactly, and it has completely rewired global business, global economics.

7
00:00:19.320 --> 00:00:22.800
<v Speaker 1>So today we're doing a deep dive into cloud computing fundamentals.

8
00:00:22.960 --> 00:00:25.800
<v Speaker 2>Yeah, our goal here is to give you a really solid,

9
00:00:26.160 --> 00:00:29.879
<v Speaker 2>structured understanding. We want to get past the jargon and

10
00:00:29.960 --> 00:00:32.799
<v Speaker 2>look at the architecture, the models, the tech that makes

11
00:00:33.000 --> 00:00:35.159
<v Speaker 2>while modern digital life possible.

12
00:00:35.359 --> 00:00:38.439
<v Speaker 1>We'll hit the why, the how, and the what the

13
00:00:38.479 --> 00:00:39.719
<v Speaker 1>strategic disruptions.

14
00:00:39.920 --> 00:00:42.399
<v Speaker 2>Let's start with the why because it's a classic story

15
00:00:42.479 --> 00:00:44.280
<v Speaker 2>really necessity driving invention.

16
00:00:44.399 --> 00:00:47.399
<v Speaker 1>Our source material has this great example. Souris he's got

17
00:00:47.399 --> 00:00:50.039
<v Speaker 1>a small business, maybe twenty employees. Think about the old

18
00:00:50.039 --> 00:00:50.920
<v Speaker 1>way he'd have to operate.

19
00:00:50.960 --> 00:00:54.320
<v Speaker 2>Oh yeah, he'd need a server room, actual physical hardware,

20
00:00:54.439 --> 00:00:58.000
<v Speaker 2>software licenses, security stuff, backup systems.

21
00:00:57.799 --> 00:01:00.000
<v Speaker 1>Plus a dedicated IT team just to keep the wife.

22
00:01:00.039 --> 00:01:02.159
<v Speaker 1>It's on for email and basic operations.

23
00:01:02.439 --> 00:01:06.319
<v Speaker 2>And the killer is as Sorage's company grows, that cost

24
00:01:06.519 --> 00:01:11.120
<v Speaker 2>that capital expenditure or capex, it just balloons buying servers,

25
00:01:11.159 --> 00:01:12.920
<v Speaker 2>paying for power cooling.

26
00:01:13.079 --> 00:01:16.319
<v Speaker 1>Every new hire, every new software feature means buying more stuff.

27
00:01:16.319 --> 00:01:19.959
<v Speaker 1>It's a huge drain, a management headache exactly.

28
00:01:20.159 --> 00:01:23.519
<v Speaker 2>So the cloud emerges to fix that specific pain point.

29
00:01:23.640 --> 00:01:26.840
<v Speaker 1>At its core, it's about flipping that huge upfront capex

30
00:01:26.879 --> 00:01:29.920
<v Speaker 1>into a variable cost, an operational cost. Right.

31
00:01:30.079 --> 00:01:34.879
<v Speaker 2>Cloud offers this scalable, convenient, on demand access and crucially,

32
00:01:35.120 --> 00:01:36.519
<v Speaker 2>paper use access to.

33
00:01:36.519 --> 00:01:41.879
<v Speaker 1>This massive shared pool of resources, storage, networks, computing power, application.

34
00:01:41.519 --> 00:01:44.840
<v Speaker 2>Delivered instantly over the internet, usually just through your web browser.

35
00:01:44.840 --> 00:01:46.920
<v Speaker 1>You're not building the power plan anymore. You're just plugging

36
00:01:46.959 --> 00:01:48.799
<v Speaker 1>in your toaster and paying for the electricity you use.

37
00:01:48.920 --> 00:01:51.799
<v Speaker 2>Precisely, and that radically cuts cost because you don't own

38
00:01:51.799 --> 00:01:53.959
<v Speaker 2>the physical gear, you just consume the service.

39
00:01:54.040 --> 00:01:57.439
<v Speaker 1>Okay, so let's get into the defining features. What makes

40
00:01:57.439 --> 00:02:00.480
<v Speaker 1>something cloud. It's not just remote access, right, There are

41
00:02:00.560 --> 00:02:04.079
<v Speaker 1>specific rules, specific characteristics. NIST has a definition.

42
00:02:04.439 --> 00:02:07.719
<v Speaker 2>Yeah, these characteristics are key to how it all works strategically.

43
00:02:08.400 --> 00:02:11.280
<v Speaker 2>First up, on demand self service.

44
00:02:11.560 --> 00:02:12.560
<v Speaker 1>Which sounds like what it.

45
00:02:12.520 --> 00:02:15.439
<v Speaker 2>Is pretty much. It means you the user can get

46
00:02:15.439 --> 00:02:19.000
<v Speaker 2>computing resources, spin up a server, adds storied whenever you

47
00:02:19.039 --> 00:02:19.560
<v Speaker 2>need it.

48
00:02:19.479 --> 00:02:22.000
<v Speaker 1>Through a simple web portal, usually no need to file

49
00:02:22.039 --> 00:02:23.560
<v Speaker 1>a ticket and wait for an admin.

50
00:02:23.439 --> 00:02:26.960
<v Speaker 2>Exactly, no human intervention needed from the provider side to

51
00:02:27.039 --> 00:02:27.719
<v Speaker 2>provision it.

52
00:02:27.719 --> 00:02:31.240
<v Speaker 1>It's instant, and that speed connects directly. The next one

53
00:02:31.560 --> 00:02:32.680
<v Speaker 1>rapid elasticity.

54
00:02:33.400 --> 00:02:37.879
<v Speaker 2>Elasticity. This is huge. It's the ability for those resources

55
00:02:37.919 --> 00:02:41.039
<v Speaker 2>to scale up or down really quickly, automatically.

56
00:02:41.039 --> 00:02:44.439
<v Speaker 1>Even so, if your website suddenly gets slammed with traffic.

57
00:02:44.240 --> 00:02:47.159
<v Speaker 2>The cloud infrastructure just expands to handle it and then

58
00:02:47.199 --> 00:02:50.360
<v Speaker 2>shrinks back when the traffic dies down. You match capacity

59
00:02:50.400 --> 00:02:51.719
<v Speaker 2>to demand almost perfectly.

60
00:02:51.840 --> 00:02:55.479
<v Speaker 1>Which sounds expensive. That instant scaling, how is that affordable?

61
00:02:55.879 --> 00:02:58.879
<v Speaker 2>Well, that brings us to the economic engine. Multi tenancy.

62
00:02:59.000 --> 00:03:01.680
<v Speaker 2>This is where the uh the real efficiency comes from.

63
00:03:01.840 --> 00:03:04.919
<v Speaker 1>Meaning multiple customers are using the same underlying hardware.

64
00:03:05.280 --> 00:03:10.120
<v Speaker 2>Exactly, thousands of businesses like Sourishes are sharing the same

65
00:03:10.199 --> 00:03:14.479
<v Speaker 2>physical server, the same storage array. The provider pools these

66
00:03:14.520 --> 00:03:16.080
<v Speaker 2>resources at massive.

67
00:03:15.680 --> 00:03:20.080
<v Speaker 1>Scale, turning everyone's potential CAPEX headache into their own highly

68
00:03:20.080 --> 00:03:22.479
<v Speaker 1>efficient operational cost their op X.

69
00:03:22.639 --> 00:03:26.159
<v Speaker 2>Precisely, that sharing drives down the cost per user and

70
00:03:26.240 --> 00:03:27.800
<v Speaker 2>makes the elasticity possible.

71
00:03:27.840 --> 00:03:32.439
<v Speaker 1>Okay, but sharing that immediately raises security questions. If we're

72
00:03:32.439 --> 00:03:33.520
<v Speaker 1>all on the same box.

73
00:03:33.680 --> 00:03:36.639
<v Speaker 2>That's a critical point and it leads into the architecture

74
00:03:36.680 --> 00:03:40.199
<v Speaker 2>and especially virtualization, which we'll dig into. The short answer

75
00:03:40.240 --> 00:03:43.840
<v Speaker 2>is the resources are logically isolated, very rigorously.

76
00:03:44.120 --> 00:03:47.240
<v Speaker 1>So even though you're sharing hardware, your data and processes

77
00:03:47.240 --> 00:03:49.639
<v Speaker 1>are kept private and secure from other tenants. If their

78
00:03:49.719 --> 00:03:51.680
<v Speaker 1>virtual server crashes, yours is fine.

79
00:03:51.719 --> 00:03:56.439
<v Speaker 2>Correct. That isolation is fundamental. So we have on demand elasticity,

80
00:03:56.520 --> 00:03:58.800
<v Speaker 2>multi tenancy. And the last key bit is paper use.

81
00:03:59.039 --> 00:04:01.400
<v Speaker 1>You only pay for what you can and zume like utilities.

82
00:04:01.520 --> 00:04:04.800
<v Speaker 1>Like utilities, measure the resources you use, CPU hours, gigabytes

83
00:04:04.840 --> 00:04:08.360
<v Speaker 1>stored and get built for just that simple, transparent Okay,

84
00:04:08.599 --> 00:04:11.639
<v Speaker 1>those are the rules of engagement. Now, how is the

85
00:04:11.680 --> 00:04:15.439
<v Speaker 1>system actually structured? The architecture right, front end and back end.

86
00:04:15.560 --> 00:04:18.160
<v Speaker 2>Right. The front end is pretty straightforward. It's what you

87
00:04:18.560 --> 00:04:20.720
<v Speaker 2>the user see and interact with.

88
00:04:20.519 --> 00:04:24.199
<v Speaker 1>My laptop, my phone, the web browser, the app interface

89
00:04:25.079 --> 00:04:26.439
<v Speaker 1>like Gmail or Google.

90
00:04:26.279 --> 00:04:28.759
<v Speaker 2>Docs exactly, the client side interface.

91
00:04:28.959 --> 00:04:33.040
<v Speaker 1>And the back end that's the mysterious part. The cloud itself.

92
00:04:33.199 --> 00:04:36.480
<v Speaker 2>That's the provider's domain. It's the massive data centers. The

93
00:04:36.519 --> 00:04:40.600
<v Speaker 2>warehouse is full of servers, the huge storage systems, the networks,

94
00:04:40.680 --> 00:04:44.439
<v Speaker 2>the security infrastructure, everything that makes the cloud work.

95
00:04:44.600 --> 00:04:47.519
<v Speaker 1>And as a user, I don't know or really need

96
00:04:47.600 --> 00:04:50.399
<v Speaker 1>to know where that back end physically is or how

97
00:04:50.399 --> 00:04:51.120
<v Speaker 1>it's configured.

98
00:04:51.240 --> 00:04:54.560
<v Speaker 2>Correct, That complexity is abstracted away. That's part of the service.

99
00:04:54.600 --> 00:04:57.560
<v Speaker 2>You interact with the simple front end. The provider manages

100
00:04:57.680 --> 00:04:58.560
<v Speaker 2>the complex back.

101
00:04:58.480 --> 00:05:01.079
<v Speaker 1>End right moving up the stack or maybe down, depending

102
00:05:01.079 --> 00:05:03.480
<v Speaker 1>on how you see it. The service models. This is

103
00:05:03.480 --> 00:05:06.199
<v Speaker 1>about what you're actually buying and how much control you

104
00:05:06.279 --> 00:05:07.279
<v Speaker 1>keep versus handover.

105
00:05:07.319 --> 00:05:09.600
<v Speaker 2>Yeah, it's often shown as a pyramid or stack. Three

106
00:05:09.639 --> 00:05:13.279
<v Speaker 2>main layers sauces, Polus, and ISS. It's about the division

107
00:05:13.319 --> 00:05:14.240
<v Speaker 2>of responsibility.

108
00:05:14.680 --> 00:05:18.000
<v Speaker 1>Start at the top with sas software as service. This

109
00:05:18.120 --> 00:05:20.319
<v Speaker 1>feels like the most common one for end users.

110
00:05:20.639 --> 00:05:24.399
<v Speaker 2>It is SAUCE is delivering software applications over the Internet.

111
00:05:24.639 --> 00:05:27.759
<v Speaker 2>You just access them, usually through your browser, think Gmail,

112
00:05:28.040 --> 00:05:30.240
<v Speaker 2>Salesforce Office three sixty five.

113
00:05:30.519 --> 00:05:33.160
<v Speaker 1>You don't install anything, you don't manage updates, you don't

114
00:05:33.160 --> 00:05:35.279
<v Speaker 1>worry about the servers of the OS it runs on.

115
00:05:35.439 --> 00:05:38.079
<v Speaker 2>Nope, the vendor handles all of that. You just use

116
00:05:38.120 --> 00:05:41.079
<v Speaker 2>the software. Our source analogy is good here. Sauce is

117
00:05:41.120 --> 00:05:42.079
<v Speaker 2>like hailing a cab.

118
00:05:42.240 --> 00:05:43.959
<v Speaker 1>You get the ride, you don't worry about the car,

119
00:05:44.079 --> 00:05:47.079
<v Speaker 1>the driver, the fuel, the maintenance. You just use the service.

120
00:05:47.319 --> 00:05:50.959
<v Speaker 1>You manage your data, maybe user access, but that's it exactly.

121
00:05:51.199 --> 00:05:55.199
<v Speaker 2>Maximum convenience, minimum control over the underlying stuff.

122
00:05:55.319 --> 00:06:00.160
<v Speaker 1>Okay, moving down one level. PASS platform is a service's

123
00:06:00.160 --> 00:06:01.000
<v Speaker 1>more for developers.

124
00:06:01.079 --> 00:06:04.319
<v Speaker 2>It generally is PASS provides a platform and environment for

125
00:06:04.399 --> 00:06:07.959
<v Speaker 2>developers to build, deploy, and manage their own applications.

126
00:06:08.000 --> 00:06:11.720
<v Speaker 1>So the vendor still manages the infrastructure, servers, storage, networking,

127
00:06:12.120 --> 00:06:13.519
<v Speaker 1>the operating system.

128
00:06:13.439 --> 00:06:17.040
<v Speaker 2>Right, but you, the customer, you manage your application code

129
00:06:17.079 --> 00:06:20.000
<v Speaker 2>and your data. The vendor provides the workshop and the

130
00:06:20.000 --> 00:06:23.399
<v Speaker 2>heavy machinery. You bring your tools and build your product.

131
00:06:23.720 --> 00:06:27.759
<v Speaker 1>What's in that platform they provide beyond just the OS.

132
00:06:27.879 --> 00:06:33.160
<v Speaker 2>Crucially, it includes middleware, things like database management systems, messaging queues,

133
00:06:33.240 --> 00:06:37.600
<v Speaker 2>development tools, business intelligence services. Stuff you normally have to

134
00:06:37.639 --> 00:06:38.879
<v Speaker 2>install and manage yourself.

135
00:06:39.120 --> 00:06:43.120
<v Speaker 1>Ah okay, So it streamlines the development process. The analogy here.

136
00:06:43.120 --> 00:06:46.399
<v Speaker 2>Calling a cab, but driving it yourself. The cars provided

137
00:06:46.439 --> 00:06:49.319
<v Speaker 2>and maintained, making it easier, but you control the journey

138
00:06:49.360 --> 00:06:52.879
<v Speaker 2>the destination. Examples are things like Google app Engine or

139
00:06:52.959 --> 00:06:55.839
<v Speaker 2>Heroku or Microsoft Azure app Service.

140
00:06:55.959 --> 00:06:59.120
<v Speaker 1>Got it so less convenience than saws, but more control

141
00:06:59.160 --> 00:07:00.360
<v Speaker 1>for building custom.

142
00:07:00.120 --> 00:07:04.240
<v Speaker 2>Some things precisely now the base layer IAS infrastructure as

143
00:07:04.240 --> 00:07:04.759
<v Speaker 2>a service.

144
00:07:04.959 --> 00:07:08.120
<v Speaker 1>This sounds like the most fundamental raw ingredients.

145
00:07:08.160 --> 00:07:11.439
<v Speaker 2>Pretty much. ISS provides the basic building blocks of computing

146
00:07:11.480 --> 00:07:16.319
<v Speaker 2>resources like virtual servers, storage networks. You rent it infrastructure

147
00:07:16.399 --> 00:07:17.519
<v Speaker 2>on a paper use basis.

148
00:07:17.560 --> 00:07:18.879
<v Speaker 1>Like we discussed.

149
00:07:18.600 --> 00:07:22.480
<v Speaker 2>Exactly with IRIS, you manage almost everything above the raw

150
00:07:22.519 --> 00:07:27.360
<v Speaker 2>hardware virtualization, your own operating systems, your middleware, your applications,

151
00:07:27.399 --> 00:07:27.920
<v Speaker 2>your data.

152
00:07:28.639 --> 00:07:31.120
<v Speaker 1>So wait, if I'm managing the OS and everything else,

153
00:07:32.439 --> 00:07:35.079
<v Speaker 1>haven't I just swapped owning a physical server in my

154
00:07:35.160 --> 00:07:38.480
<v Speaker 1>office for rending a virtual server somewhere else Where's the

155
00:07:38.480 --> 00:07:41.680
<v Speaker 1>big advantage over just running my own data center? Apart

156
00:07:41.720 --> 00:07:44.480
<v Speaker 1>from maybe initial cost, That's a.

157
00:07:44.399 --> 00:07:47.920
<v Speaker 2>Really important question. The revolutionary gain isn't just cost, though

158
00:07:47.920 --> 00:07:49.920
<v Speaker 2>that's part of it. It's the scale and speed.

159
00:07:50.199 --> 00:07:50.480
<v Speaker 1>Okay.

160
00:07:50.519 --> 00:07:55.040
<v Speaker 2>With iiras, you get access to essentially unlimited resources provisioned

161
00:07:55.160 --> 00:07:58.360
<v Speaker 2>almost instantly. Need one thousand servers for a four hour

162
00:07:58.439 --> 00:07:59.519
<v Speaker 2>data processing job.

163
00:07:59.600 --> 00:08:02.879
<v Speaker 1>With a WSEC two or Google Compute engine, you click

164
00:08:02.920 --> 00:08:05.240
<v Speaker 1>a few buttons, run your job, and then shut them down.

165
00:08:05.360 --> 00:08:06.639
<v Speaker 1>You pay only for those four hours.

166
00:08:06.800 --> 00:08:10.120
<v Speaker 2>Try doing that with physical hardware the procurement, time, the setup.

167
00:08:10.160 --> 00:08:13.759
<v Speaker 2>It's impossible. That elasticity, that ability to access massive scale

168
00:08:13.800 --> 00:08:17.000
<v Speaker 2>on demand is what changes the game. No small or

169
00:08:17.040 --> 00:08:20.319
<v Speaker 2>even medium business could replicate that capability on their own.

170
00:08:20.480 --> 00:08:22.959
<v Speaker 1>Okay, that makes sense. It's the scale and the agility

171
00:08:23.000 --> 00:08:26.319
<v Speaker 1>you're buying, so we know the whatsas pi os ohes.

172
00:08:26.800 --> 00:08:29.680
<v Speaker 1>But where does this stuff live and who else is

173
00:08:29.800 --> 00:08:33.840
<v Speaker 1>using it? That brings us to deployment models, right.

174
00:08:33.799 --> 00:08:36.679
<v Speaker 2>This defines the access and ownership. The most common one

175
00:08:36.720 --> 00:08:38.799
<v Speaker 2>you hear about is the public cloud.

176
00:08:39.360 --> 00:08:42.600
<v Speaker 1>Like AWS, Google Cloud, Azure exactly.

177
00:08:42.960 --> 00:08:46.399
<v Speaker 2>Resources, servers, storage networks are owned and operated by the

178
00:08:46.399 --> 00:08:49.360
<v Speaker 2>provider and they're offered over the public Internet to anyone

179
00:08:49.399 --> 00:08:50.279
<v Speaker 2>who wants to sign up.

180
00:08:50.360 --> 00:08:53.000
<v Speaker 1>It's multi tenant, like we talked about shared infrastructure.

181
00:08:53.120 --> 00:08:57.200
<v Speaker 2>Yes, the big advantages are massive scalability and cost effectiveness

182
00:08:57.279 --> 00:09:00.840
<v Speaker 2>because you're leveraging the provider's huge scale and only paying

183
00:09:00.840 --> 00:09:03.720
<v Speaker 2>for your slice. The vendor handles all the maintenance.

184
00:09:03.879 --> 00:09:08.919
<v Speaker 1>Okay, so maximum scale, potentially lowest cost, but maybe less

185
00:09:08.919 --> 00:09:09.960
<v Speaker 1>control over the environment.

186
00:09:10.000 --> 00:09:12.879
<v Speaker 2>What's the opposite That would be the private cloud. This

187
00:09:12.919 --> 00:09:16.799
<v Speaker 2>is cloud infrastructure operated solely for a single organization.

188
00:09:16.559 --> 00:09:19.039
<v Speaker 1>So they might build it themselves in their own data center,

189
00:09:19.399 --> 00:09:21.240
<v Speaker 1>or have a third party host it just for them,

190
00:09:21.399 --> 00:09:23.000
<v Speaker 1>but it's dedicated, single tenant.

191
00:09:23.240 --> 00:09:27.279
<v Speaker 2>Correct resources are usually accessed over a private network, often

192
00:09:27.320 --> 00:09:28.879
<v Speaker 2>behind the company firewall.

193
00:09:29.240 --> 00:09:31.720
<v Speaker 1>Why do this? Seems like you lose some of the

194
00:09:31.759 --> 00:09:33.159
<v Speaker 1>cost benefits of public.

195
00:09:32.840 --> 00:09:38.320
<v Speaker 2>Cloud control and security. For organizations with really strict regulatory

196
00:09:38.399 --> 00:09:43.960
<v Speaker 2>requirements or sensitive data think finance, government, healthcare, a private

197
00:09:43.960 --> 00:09:47.799
<v Speaker 2>cloud offers much leater control over the infrastructure and data security.

198
00:09:47.840 --> 00:09:51.559
<v Speaker 1>Okay, public for scale and cost, private for control and security.

199
00:09:51.879 --> 00:09:53.000
<v Speaker 1>But the real world.

200
00:09:52.759 --> 00:09:55.080
<v Speaker 2>Is messy, right it is, and that's why the hybrid

201
00:09:55.120 --> 00:09:57.480
<v Speaker 2>cloud is so common, especially for larger.

202
00:09:57.279 --> 00:09:59.320
<v Speaker 1>Enterprises, mixing and matching.

203
00:09:59.120 --> 00:10:02.440
<v Speaker 2>Exactly, binding a private cloud with one or more public

204
00:10:02.440 --> 00:10:04.960
<v Speaker 2>cloud services you orchestrate between the two.

205
00:10:05.200 --> 00:10:07.039
<v Speaker 1>What's the strategy there? Why combine them?

206
00:10:07.120 --> 00:10:10.480
<v Speaker 2>It lets you optimize. You can keep your super sensitive

207
00:10:10.559 --> 00:10:13.759
<v Speaker 2>data and core applications on your private cloud for security

208
00:10:13.799 --> 00:10:14.799
<v Speaker 2>and control, but.

209
00:10:14.879 --> 00:10:17.399
<v Speaker 1>Use the public cloud for things that need massive scale

210
00:10:17.639 --> 00:10:20.639
<v Speaker 1>or are less sensitive, like maybe customer facing websites, or

211
00:10:20.759 --> 00:10:24.200
<v Speaker 1>development and testing environments or big data analytics.

212
00:10:24.600 --> 00:10:28.000
<v Speaker 2>Precisely, you get the best of both worlds security where

213
00:10:28.000 --> 00:10:30.879
<v Speaker 2>you need it, scale and cost efficiency where you can

214
00:10:31.000 --> 00:10:31.919
<v Speaker 2>leverage it, and this.

215
00:10:31.960 --> 00:10:35.240
<v Speaker 1>Hybrid approach enables a really cool concept cloud bursting.

216
00:10:35.360 --> 00:10:38.679
<v Speaker 2>Ah, cloud bursting. Yeah, this is a fantastic use case

217
00:10:38.720 --> 00:10:42.519
<v Speaker 2>for hybrid. Imagine your application running happily on your private cloud.

218
00:10:43.039 --> 00:10:46.320
<v Speaker 1>Then suddenly a massive spike in demand hits, like a

219
00:10:46.360 --> 00:10:49.240
<v Speaker 1>big sale event or end of quarter reporting.

220
00:10:49.360 --> 00:10:52.600
<v Speaker 2>Your private cloud might get overwhelmed. With cloud bursting. The

221
00:10:52.639 --> 00:10:56.559
<v Speaker 2>application can automatically burst spill over the extra demand to

222
00:10:56.559 --> 00:10:57.720
<v Speaker 2>the public cloud.

223
00:10:57.679 --> 00:11:01.159
<v Speaker 1>So you seamlessly tap into the public clouds elasticity just

224
00:11:01.200 --> 00:11:02.200
<v Speaker 1>for that peak period.

225
00:11:02.320 --> 00:11:05.159
<v Speaker 2>Right, You handle the spike without crashing, pay for the

226
00:11:05.200 --> 00:11:08.120
<v Speaker 2>extra public cloud resources only while you need them, and

227
00:11:08.159 --> 00:11:10.960
<v Speaker 2>then scale back down. It's a great way to balance cost,

228
00:11:11.320 --> 00:11:13.519
<v Speaker 2>performance and availability smart.

229
00:11:13.840 --> 00:11:17.039
<v Speaker 1>We should also quickly mention the community cloud. It's less common,

230
00:11:17.080 --> 00:11:17.799
<v Speaker 1>but it exists.

231
00:11:17.879 --> 00:11:19.600
<v Speaker 2>Yeah, it's kind of a niche model. It's like a

232
00:11:19.639 --> 00:11:23.639
<v Speaker 2>semi private cloud where infrastructure is shared by several organizations

233
00:11:23.679 --> 00:11:25.159
<v Speaker 2>with common concerns.

234
00:11:24.759 --> 00:11:28.639
<v Speaker 1>Maybe specific security requirements or compliance needs, or a joint

235
00:11:28.679 --> 00:11:30.159
<v Speaker 1>project exactly.

236
00:11:30.519 --> 00:11:34.240
<v Speaker 2>Think of a group of government agencies or universities, or

237
00:11:34.240 --> 00:11:37.240
<v Speaker 2>maybe companies in a specific industry sharing the cost of

238
00:11:37.279 --> 00:11:38.600
<v Speaker 2>a tailored cloud environment.

239
00:11:38.919 --> 00:11:42.960
<v Speaker 1>Okay, we've covered the models, the services, the deployments. But

240
00:11:43.159 --> 00:11:47.120
<v Speaker 1>none of this, the elasticity, the multi tenancy, the paper use,

241
00:11:47.559 --> 00:11:51.240
<v Speaker 1>none of it works without one core enabling technology.

242
00:11:51.279 --> 00:11:54.720
<v Speaker 2>You got it, virtualization. It's the absolute foundation, the engine

243
00:11:54.799 --> 00:11:55.720
<v Speaker 2>driving the whole thing.

244
00:11:56.000 --> 00:11:57.039
<v Speaker 1>What is it exactly?

245
00:11:57.360 --> 00:12:01.039
<v Speaker 2>In simple terms, virtualization is basically using software to create

246
00:12:01.080 --> 00:12:04.919
<v Speaker 2>a virtual version of something physical. Most often it's creating

247
00:12:05.000 --> 00:12:09.000
<v Speaker 2>virtual machines vms that act like real physical computers.

248
00:12:09.200 --> 00:12:11.759
<v Speaker 1>So you take one powerful physical server, you.

249
00:12:11.759 --> 00:12:15.519
<v Speaker 2>Use software to slice it up into multiple independent virtual servers.

250
00:12:15.840 --> 00:12:20.240
<v Speaker 2>Each VM gets its own share of the physical servers CPU, memory, storage,

251
00:12:20.279 --> 00:12:21.559
<v Speaker 2>and networking, and each.

252
00:12:21.559 --> 00:12:24.879
<v Speaker 1>VM can run its own operating system and applications completely

253
00:12:24.879 --> 00:12:26.399
<v Speaker 1>isolated from the others. Correct.

254
00:12:26.720 --> 00:12:29.919
<v Speaker 2>This is how cloud providers can efficiently pack many customers

255
00:12:29.919 --> 00:12:32.679
<v Speaker 2>onto the same physical hardware. It gives each customer the

256
00:12:32.720 --> 00:12:35.399
<v Speaker 2>illusion of having their own dedicated machine.

257
00:12:35.080 --> 00:12:38.679
<v Speaker 1>That ability to run many pretend computers on one real one.

258
00:12:39.519 --> 00:12:42.759
<v Speaker 1>That's the source of the efficiency and cost savings. Who

259
00:12:42.799 --> 00:12:44.879
<v Speaker 1>manages this slicing and dicing.

260
00:12:45.039 --> 00:12:47.759
<v Speaker 2>That magic piece of software is called the hypervisor, or

261
00:12:47.799 --> 00:12:50.080
<v Speaker 2>sometimes the virtual machine monitor VMM.

262
00:12:50.159 --> 00:12:53.600
<v Speaker 1>The hypervisor sits between the physical hardware and the virtual.

263
00:12:53.320 --> 00:12:56.720
<v Speaker 2>Machines exactly it's the traffic cop It creates the vms,

264
00:12:56.879 --> 00:13:00.840
<v Speaker 2>runs them, and allocates the physical resources among them. It

265
00:13:00.879 --> 00:13:03.120
<v Speaker 2>makes sure they don't interfere with each other, which.

266
00:13:02.960 --> 00:13:05.679
<v Speaker 1>Brings us back to that isolation benefit we mentioned earlier.

267
00:13:05.759 --> 00:13:09.519
<v Speaker 2>Absolutely critical because the hypervisor isolates each VM. If one

268
00:13:09.639 --> 00:13:12.799
<v Speaker 2>VM crashes or gets compromised, it doesn't take down the

269
00:13:12.840 --> 00:13:14.639
<v Speaker 2>others running on the same physical host.

270
00:13:14.960 --> 00:13:18.080
<v Speaker 1>That's essential for multi tenancy to work securely totally.

271
00:13:18.360 --> 00:13:22.080
<v Speaker 2>So virtualization gives you cost reduction, fewer physical servers needed,

272
00:13:22.159 --> 00:13:26.360
<v Speaker 2>less power, less space, much better resource utilization, packing more

273
00:13:26.399 --> 00:13:30.799
<v Speaker 2>workloads onto hardware, and that crucial isolation. It's the technology

274
00:13:30.799 --> 00:13:34.720
<v Speaker 2>that makes the cloud business model possible. Hashtag tag tag outrop.

275
00:13:34.840 --> 00:13:38.360
<v Speaker 1>Wow. Okay, we've really covered the landscape here, the why,

276
00:13:38.639 --> 00:13:42.639
<v Speaker 1>solving the CAPEX burden, the how, the architecture and virtualization,

277
00:13:43.600 --> 00:13:47.639
<v Speaker 1>what's a sauce passis, and the deployment models, and.

278
00:13:47.600 --> 00:13:51.679
<v Speaker 2>You can see why it's so popular. Rapid resources, amazing scalability,

279
00:13:51.840 --> 00:13:56.559
<v Speaker 2>significant cost savings, especially avoiding buying and maintaining all that

280
00:13:56.600 --> 00:13:57.840
<v Speaker 2>expensive hardware yourself.

281
00:13:58.440 --> 00:14:01.919
<v Speaker 1>But like anything power, there's another side to the coin.

282
00:14:02.480 --> 00:14:05.639
<v Speaker 1>Convenience often comes with trade offs with challenges. You need

283
00:14:05.679 --> 00:14:06.879
<v Speaker 1>to be aware of absolutely.

284
00:14:07.000 --> 00:14:09.519
<v Speaker 2>Let's touch on a few key ones. The most obvious,

285
00:14:09.559 --> 00:14:14.720
<v Speaker 2>perhaps is dependency on the Internet connection. Totally your entire operation,

286
00:14:15.039 --> 00:14:18.480
<v Speaker 2>your apps, your data, your servers is accessed over the Internet.

287
00:14:18.840 --> 00:14:21.000
<v Speaker 2>If that connection goes down or even just get slow

288
00:14:21.039 --> 00:14:22.279
<v Speaker 2>and unreliable.

289
00:14:21.799 --> 00:14:24.399
<v Speaker 1>You dead in a water. Your access just vanishes. That's

290
00:14:24.399 --> 00:14:24.919
<v Speaker 1>a big one.

291
00:14:25.159 --> 00:14:29.000
<v Speaker 2>It is. Then there are ongoing security issues. Now, providers

292
00:14:29.039 --> 00:14:32.679
<v Speaker 2>are incredibly good at securing the underlying infrastructure, the data centers,

293
00:14:32.720 --> 00:14:33.159
<v Speaker 2>but you're.

294
00:14:33.000 --> 00:14:36.159
<v Speaker 1>Still often sharing resources in a multi tenant environment, and

295
00:14:36.200 --> 00:14:39.320
<v Speaker 1>the customer still has responsibility for securing their own applications

296
00:14:39.320 --> 00:14:41.799
<v Speaker 1>and data configurations within the cloud. Right.

297
00:14:42.159 --> 00:14:45.919
<v Speaker 2>It creates a shared responsibility model and storing sensitive data

298
00:14:45.960 --> 00:14:49.919
<v Speaker 2>on servers you don't physically control. Well, it's a persistent concern,

299
00:14:50.200 --> 00:14:54.799
<v Speaker 2>requires constant vigilance, robust security practices on the user side too.

300
00:14:54.919 --> 00:14:58.440
<v Speaker 1>Okay, dependency security. What else?

301
00:14:58.799 --> 00:15:01.759
<v Speaker 2>A big one actually, if you lean heavily into pass

302
00:15:01.919 --> 00:15:04.799
<v Speaker 2>or ias, is the risk of vendor lock.

303
00:15:04.679 --> 00:15:07.399
<v Speaker 1>In, meaning it's hard to switch providers later.

304
00:15:07.559 --> 00:15:10.480
<v Speaker 2>It can be Yeah, imagine you build a complex application

305
00:15:10.679 --> 00:15:16.039
<v Speaker 2>deeply integrated with one provider's specific platform services, their proprietary database,

306
00:15:16.120 --> 00:15:20.639
<v Speaker 2>their unique machine learning tools. Their specific APIs.

307
00:15:20.159 --> 00:15:23.200
<v Speaker 1>Moving that whole setup to a different cloud provider who

308
00:15:23.240 --> 00:15:24.840
<v Speaker 1>has different proprietary services.

309
00:15:24.879 --> 00:15:28.279
<v Speaker 2>It can become incredibly complex, time consuming, and expensive. It's

310
00:15:28.320 --> 00:15:31.480
<v Speaker 2>like building your house perfectly fitted to one very specific

311
00:15:31.519 --> 00:15:34.320
<v Speaker 2>plot of land. Moving the whole house later is often

312
00:15:34.360 --> 00:15:35.720
<v Speaker 2>harder than just building a new one.

313
00:15:35.799 --> 00:15:38.080
<v Speaker 1>Yeah, that makes sense. You trade some portability for the

314
00:15:38.120 --> 00:15:40.360
<v Speaker 1>convenience of those integrated platform services.

315
00:15:40.600 --> 00:15:45.399
<v Speaker 2>And all these challenges dependency, security, complexity, lock in, they

316
00:15:45.440 --> 00:15:48.360
<v Speaker 2>all feed into what might be the biggest strategic challenge

317
00:15:48.480 --> 00:15:52.679
<v Speaker 2>for enterprises using cloud today, especially multi cloud environments, which

318
00:15:52.720 --> 00:15:57.399
<v Speaker 2>is governance and control. Think about it, the provider manages

319
00:15:57.480 --> 00:16:00.919
<v Speaker 2>all the underlying infrastructure. As a client, you often lack

320
00:16:01.039 --> 00:16:05.200
<v Speaker 2>deep visibility and fine grained control over exactly how resources

321
00:16:05.200 --> 00:16:08.519
<v Speaker 2>are provisioned, how data is handled, how compliance is enforced

322
00:16:08.559 --> 00:16:10.840
<v Speaker 2>consistently across different cloud environments.

323
00:16:10.919 --> 00:16:15.000
<v Speaker 1>So you gain massive convenience in scale, but you potentially

324
00:16:15.080 --> 00:16:19.559
<v Speaker 1>lose that direct, granular oversight you had when everything was

325
00:16:19.600 --> 00:16:20.080
<v Speaker 1>in your own.

326
00:16:20.000 --> 00:16:23.879
<v Speaker 2>Data center exactly managing it governance, risk, and compliance in

327
00:16:23.919 --> 00:16:26.679
<v Speaker 2>a world where your infrastructure is abstracted and spread across

328
00:16:26.759 --> 00:16:29.679
<v Speaker 2>multiple providers, that's a huge ongoing challenge.

329
00:16:29.720 --> 00:16:31.559
<v Speaker 1>So The final thought for you, the listener might be

330
00:16:32.080 --> 00:16:35.720
<v Speaker 1>what's the real price of convenience? Wrestling with that tension,

331
00:16:36.200 --> 00:16:39.440
<v Speaker 1>balancing the cloud's power with the need for robust governance

332
00:16:39.480 --> 00:16:42.840
<v Speaker 1>and control. That's the critical task is you navigate this landscape.