WEBVTT

1
00:00:00.160 --> 00:00:04.000
<v Speaker 1>Welcome to the deep dive. Okay, so you've given us

2
00:00:04.040 --> 00:00:08.039
<v Speaker 1>this really dense stack of sources. It looks like it

3
00:00:08.080 --> 00:00:11.519
<v Speaker 1>takes us right from the basics the core of a

4
00:00:11.560 --> 00:00:14.759
<v Speaker 1>Linux server all the way up to managing stuff across

5
00:00:14.839 --> 00:00:15.679
<v Speaker 1>multiple clouds.

6
00:00:15.839 --> 00:00:16.839
<v Speaker 2>Yeah, that's the idea.

7
00:00:16.960 --> 00:00:19.640
<v Speaker 1>So our mission today it's pretty simple. We're giving you

8
00:00:19.679 --> 00:00:21.640
<v Speaker 1>the shortcut. We're not going to wade through, you know,

9
00:00:21.719 --> 00:00:24.320
<v Speaker 1>setting up servers by hand, definitely not. We're cutting straight

10
00:00:24.359 --> 00:00:26.960
<v Speaker 1>to the strategic stuff, the why and the how of

11
00:00:27.160 --> 00:00:29.039
<v Speaker 1>real DevOps automation exactly.

12
00:00:29.640 --> 00:00:32.119
<v Speaker 2>This deep dive it really tracks a huge shift in

13
00:00:32.159 --> 00:00:36.679
<v Speaker 2>it thinking. I mean, we're moving from system admins clicking

14
00:00:36.719 --> 00:00:39.719
<v Speaker 2>through installs one by one the old way right towards

15
00:00:39.719 --> 00:00:41.960
<v Speaker 2>a true DevOps model, and that's all about speed, being

16
00:00:42.000 --> 00:00:45.479
<v Speaker 2>able to audit everything, and well collaboration. The main thing

17
00:00:45.520 --> 00:00:47.799
<v Speaker 2>is breaking down those old walls using automation to get

18
00:00:47.799 --> 00:00:51.479
<v Speaker 2>things delivered faster and crucially reliably.

19
00:00:51.600 --> 00:00:54.679
<v Speaker 1>Okay, so we'll start with the basics, the foundation links, fundamentals,

20
00:00:54.759 --> 00:00:59.280
<v Speaker 1>and then pretty quickly ramp up towards infrastructure as cotatchies, containers, Kubernetes,

21
00:00:59.719 --> 00:01:01.479
<v Speaker 1>and and multi cloud strategies.

22
00:01:01.600 --> 00:01:04.000
<v Speaker 2>Think of it as your quick start guide. We want

23
00:01:04.079 --> 00:01:06.719
<v Speaker 2>you to get the whole picture, focusing on the insights

24
00:01:06.760 --> 00:01:09.000
<v Speaker 2>you really need, not all the low level detail.

25
00:01:09.079 --> 00:01:12.000
<v Speaker 1>Got it, Let's dive in app Okay, let's start right

26
00:01:12.000 --> 00:01:16.159
<v Speaker 1>at the beginning. Then Linux it's open source, which means

27
00:01:17.359 --> 00:01:20.159
<v Speaker 1>lots of different versions. Right, Distributions are distros.

28
00:01:19.959 --> 00:01:23.079
<v Speaker 2>Yep created by different groups, companies, communities.

29
00:01:23.280 --> 00:01:25.959
<v Speaker 1>So what's the like the strategic difference when you're choosing

30
00:01:25.959 --> 00:01:26.799
<v Speaker 1>between the big ones.

31
00:01:27.079 --> 00:01:30.879
<v Speaker 2>Well, it really boils down to risk versus reward, especially

32
00:01:30.920 --> 00:01:34.000
<v Speaker 2>around support. So on one side, you've got Red Hat

33
00:01:34.079 --> 00:01:38.480
<v Speaker 2>Enterprise Linux RHL, that's your corporate choice, the subscription model.

34
00:01:38.560 --> 00:01:39.200
<v Speaker 1>You pay for it.

35
00:01:39.280 --> 00:01:42.560
<v Speaker 2>You pay, but you get guaranteed support, stability that's certified,

36
00:01:42.640 --> 00:01:47.239
<v Speaker 2>and this is important compatibility with their enterprise software like

37
00:01:47.319 --> 00:01:48.200
<v Speaker 2>JBoss and stuff.

38
00:01:48.239 --> 00:01:50.640
<v Speaker 1>Okay, stable, supported, predictable exactly.

39
00:01:51.200 --> 00:01:53.599
<v Speaker 2>Then on the other side you have things like Debian

40
00:01:53.680 --> 00:01:58.519
<v Speaker 2>and it's very popular derivative Ubuntu. These are fully community maintained,

41
00:01:58.719 --> 00:02:04.079
<v Speaker 2>so free as in cost, yes, maximum freedom. But you know,

42
00:02:04.319 --> 00:02:07.760
<v Speaker 2>if something breaks, you're leaning on the community forums, mailing lists.

43
00:02:08.800 --> 00:02:10.840
<v Speaker 2>The fix isn't guaranteed on a deadline.

44
00:02:10.879 --> 00:02:14.680
<v Speaker 1>It's that classic trade off then, paid certainty versus free

45
00:02:15.439 --> 00:02:19.199
<v Speaker 1>community efforts precisely. Okay, So once you've picked your OS,

46
00:02:19.439 --> 00:02:21.639
<v Speaker 1>we're talking about putting it on a server. And the

47
00:02:21.680 --> 00:02:24.639
<v Speaker 1>sources remind us a server is really just a powerful

48
00:02:24.639 --> 00:02:29.039
<v Speaker 1>computer doing a specific job, like hosting a website or

49
00:02:29.280 --> 00:02:30.280
<v Speaker 1>running a database.

50
00:02:30.319 --> 00:02:32.680
<v Speaker 2>That's all it is. And when you pick the software

51
00:02:32.719 --> 00:02:34.960
<v Speaker 2>for that job, you're defining what we call a stack.

52
00:02:35.159 --> 00:02:37.000
<v Speaker 1>A stack like a set of tools to solve a

53
00:02:37.000 --> 00:02:37.759
<v Speaker 1>particular problem.

54
00:02:37.919 --> 00:02:40.159
<v Speaker 2>Right, you define the solution by the tools you choose.

55
00:02:40.159 --> 00:02:44.719
<v Speaker 2>Everyone knows the classic LMP stack, right, Linux, APATCHEQL, PHP.

56
00:02:44.520 --> 00:02:46.479
<v Speaker 1>The original workhorse totally.

57
00:02:46.520 --> 00:02:49.919
<v Speaker 2>But modern stacks are way more varied. The sources mentioned

58
00:02:49.919 --> 00:02:53.280
<v Speaker 2>one NPM and Jinx as the web server, piping for

59
00:02:53.280 --> 00:02:57.039
<v Speaker 2>the application itself, and Mango dB for the database, different

60
00:02:57.080 --> 00:02:58.080
<v Speaker 2>tools for different needs.

61
00:02:58.280 --> 00:03:00.719
<v Speaker 1>And the last bit of this foundation, where does the

62
00:03:00.759 --> 00:03:03.360
<v Speaker 1>server actually live? We're shifting here too, aren't we, from

63
00:03:03.360 --> 00:03:06.400
<v Speaker 1>on premise to cloud big shift on premise.

64
00:03:06.639 --> 00:03:10.319
<v Speaker 2>That meant the servers were physically inside the company in

65
00:03:10.400 --> 00:03:13.039
<v Speaker 2>their own data center, maybe even under someone's desk.

66
00:03:13.560 --> 00:03:15.319
<v Speaker 1>Huh hopefully not, hopefully not.

67
00:03:15.800 --> 00:03:19.000
<v Speaker 2>But they own the hardware, the cooling, everything. They manage

68
00:03:19.000 --> 00:03:22.759
<v Speaker 2>their own virtual machines too, maybe using tools like open stack.

69
00:03:22.560 --> 00:03:24.639
<v Speaker 1>Or overt right at the cloud.

70
00:03:24.960 --> 00:03:27.840
<v Speaker 2>Cloud just means those virtual servers are running on someone

71
00:03:27.879 --> 00:03:34.639
<v Speaker 2>else's hardware in a third party's huge data center think AWS, Azure, GCP.

72
00:03:35.080 --> 00:03:36.400
<v Speaker 1>And the big advantage there.

73
00:03:36.280 --> 00:03:40.240
<v Speaker 2>Elasticity and cost. Mostly you can spin up resources when

74
00:03:40.240 --> 00:03:42.840
<v Speaker 2>you need them and crucially turn them off when you don't,

75
00:03:43.039 --> 00:03:46.000
<v Speaker 2>like overnight or weekends. You only pay for the run

76
00:03:46.039 --> 00:03:48.199
<v Speaker 2>time and storage you actually consume. That can be a

77
00:03:48.240 --> 00:03:49.879
<v Speaker 2>massive cost saving for organization.

78
00:03:50.039 --> 00:03:53.439
<v Speaker 1>Makes sense. Pay for what you use. Yeah, all right,

79
00:03:53.479 --> 00:03:55.439
<v Speaker 1>so we have our servers maybe in the cloud, but

80
00:03:55.520 --> 00:03:58.400
<v Speaker 1>once you get more than a handful, doing things manually

81
00:04:00.120 --> 00:04:01.439
<v Speaker 1>just breaks down right immediately.

82
00:04:01.479 --> 00:04:04.639
<v Speaker 2>It doesn't scale. That's where automation becomes absolutely essential. And

83
00:04:04.680 --> 00:04:07.280
<v Speaker 2>the first tool pretty much everyone learns is Bash.

84
00:04:07.400 --> 00:04:09.159
<v Speaker 1>Bash the command line.

85
00:04:09.000 --> 00:04:11.840
<v Speaker 2>Yeah, the command line interpreter, but it's also a scripting language.

86
00:04:11.879 --> 00:04:15.000
<v Speaker 2>It's the system admin's Swiss army knife, you know, great

87
00:04:15.000 --> 00:04:19.519
<v Speaker 2>for automating simple repetitive things like whati oh, rotating log files,

88
00:04:19.639 --> 00:04:23.000
<v Speaker 2>checking if disk space is low, restarting a service, quick,

89
00:04:23.079 --> 00:04:24.079
<v Speaker 2>imperative commands.

90
00:04:24.079 --> 00:04:27.600
<v Speaker 1>Imperative. That's the key word here, isn't it. Bash tells

91
00:04:27.600 --> 00:04:29.439
<v Speaker 1>the system how to do something step by step.

92
00:04:29.519 --> 00:04:31.959
<v Speaker 2>Exactly. Step one, do this, step two do that.

93
00:04:32.079 --> 00:04:34.879
<v Speaker 1>But if you're trying to set up say fifty identical

94
00:04:34.920 --> 00:04:39.439
<v Speaker 1>web servers, writing a Bash script for that gets complicated fast.

95
00:04:39.680 --> 00:04:43.120
<v Speaker 1>You're downloading ISO images, figuring out disc allocation.

96
00:04:43.319 --> 00:04:46.639
<v Speaker 2>Oh yeah, dynamic allocation for your test lab maybe, but

97
00:04:46.879 --> 00:04:49.560
<v Speaker 2>fixed size for production so you don't accidentally fill up

98
00:04:49.600 --> 00:04:52.680
<v Speaker 2>the whole storage system. It's slow, it's prone to errors.

99
00:04:53.120 --> 00:04:55.720
<v Speaker 2>That whole pain point is really what led to infrastructure

100
00:04:55.720 --> 00:04:59.160
<v Speaker 2>as card I see. Absolutely nobody wants to sit there

101
00:04:59.279 --> 00:05:02.759
<v Speaker 2>manually prove visioning one hundred vms every day. IC is

102
00:05:02.800 --> 00:05:05.959
<v Speaker 2>the answer for the provisioning part, setting up the infrastructure itself.

103
00:05:06.199 --> 00:05:09.439
<v Speaker 2>It goes way beyond just simple task scripting.

104
00:05:09.040 --> 00:05:10.759
<v Speaker 1>So tools like Vagrant come in here.

105
00:05:11.120 --> 00:05:15.160
<v Speaker 2>Vagrant is often the first IC tool developers meet. Instead

106
00:05:15.160 --> 00:05:18.399
<v Speaker 2>of you know, clicking through all the virtual box setup screens,

107
00:05:18.399 --> 00:05:23.319
<v Speaker 2>defining memory disk size, enabling virtualization in the bios. Yes,

108
00:05:23.519 --> 00:05:27.199
<v Speaker 2>you just write a simple configuration file code. Vagrant reads

109
00:05:27.240 --> 00:05:30.079
<v Speaker 2>that code, talks to virtual box, and automatically builds the

110
00:05:30.160 --> 00:05:33.680
<v Speaker 2>VM for you. It usually uses pre built OS images

111
00:05:33.720 --> 00:05:36.720
<v Speaker 2>they call them boxes from places like Vagrant Cloud gets

112
00:05:36.720 --> 00:05:38.360
<v Speaker 2>the BASEOS installed instantly.

113
00:05:38.560 --> 00:05:41.439
<v Speaker 1>Okay, so that's a huge leap. We've gone from telling

114
00:05:41.439 --> 00:05:44.279
<v Speaker 1>the computer how to run each step with Bash to

115
00:05:44.439 --> 00:05:46.439
<v Speaker 1>just declaring what we want the end result to look

116
00:05:46.519 --> 00:05:47.800
<v Speaker 1>like with Vagrant and IIC.

117
00:05:48.079 --> 00:05:52.199
<v Speaker 2>That's the core philosophical shift. It makes the whole process repeatable, consistent,

118
00:05:52.279 --> 00:05:55.399
<v Speaker 2>and auditible. If your code says you need three gigs

119
00:05:55.399 --> 00:05:57.560
<v Speaker 2>of RAM, you get three gigs of RAM every single

120
00:05:57.639 --> 00:05:59.519
<v Speaker 2>time nopes I click the wrong button.

121
00:06:00.040 --> 00:06:03.399
<v Speaker 1>Automation is getting serious now, but we can accelerate even more. Right.

122
00:06:03.839 --> 00:06:07.759
<v Speaker 1>Moving beyond full virtual machines to containers, let's talk Docker.

123
00:06:08.040 --> 00:06:11.399
<v Speaker 1>People often call it lightweight virtualization. What's actually happening under

124
00:06:11.399 --> 00:06:12.120
<v Speaker 1>the hood in Linux?

125
00:06:12.480 --> 00:06:15.600
<v Speaker 2>Yeah, lightweight's a good description. Fundamentally, a container is about

126
00:06:15.639 --> 00:06:19.439
<v Speaker 2>isolating processes and their filesystems. Think of it like an

127
00:06:19.480 --> 00:06:23.319
<v Speaker 2>advanced version of an old Linux command crut. It creates

128
00:06:23.319 --> 00:06:26.240
<v Speaker 2>a sort of walled off directory that acts like its

129
00:06:26.279 --> 00:06:28.240
<v Speaker 2>own little OS.

130
00:06:27.800 --> 00:06:28.879
<v Speaker 1>Install walled off.

131
00:06:29.079 --> 00:06:33.360
<v Speaker 2>Yeah. It uses Linux kernel features control groups name spaces

132
00:06:33.480 --> 00:06:36.480
<v Speaker 2>to keep the container's resources. It's network traffic, it's view

133
00:06:36.480 --> 00:06:39.680
<v Speaker 2>of the filesystem separate from the host and other containers.

134
00:06:40.199 --> 00:06:43.439
<v Speaker 2>That's what makes it so portable. Everything the app needs

135
00:06:43.600 --> 00:06:45.680
<v Speaker 2>is bundled inside Okay, so let's.

136
00:06:45.480 --> 00:06:48.000
<v Speaker 1>Walk through an example. Say we're developing a simple web

137
00:06:48.040 --> 00:06:51.639
<v Speaker 1>app and Python using the Flask framework. How does the

138
00:06:51.639 --> 00:06:54.319
<v Speaker 1>whole container ecosystem build up around that to make it

139
00:06:54.360 --> 00:06:55.120
<v Speaker 1>ready for production?

140
00:06:55.360 --> 00:06:58.240
<v Speaker 2>Right, So you start coding with Flask, but flask itself

141
00:06:58.279 --> 00:07:00.560
<v Speaker 2>it even warns you it's built in server is just

142
00:07:00.600 --> 00:07:03.000
<v Speaker 2>for development. It's not tough enough for real traffic.

143
00:07:03.079 --> 00:07:05.439
<v Speaker 1>Okay, so step one need a better.

144
00:07:05.279 --> 00:07:09.600
<v Speaker 2>Server exactly for production. You need a proper WSGI server

145
00:07:10.199 --> 00:07:13.000
<v Speaker 2>that stands for a Web Server Gateway interface. It's a

146
00:07:13.040 --> 00:07:16.000
<v Speaker 2>standard way for Python web apps to talk to web servers.

147
00:07:16.279 --> 00:07:17.879
<v Speaker 2>Guncorn is a really popular one.

148
00:07:18.000 --> 00:07:21.920
<v Speaker 1>Gunnacorn handles the Python part robustly, but you still need

149
00:07:21.959 --> 00:07:24.879
<v Speaker 1>something to face the public internet right to handle all

150
00:07:24.920 --> 00:07:26.120
<v Speaker 1>the incoming connections.

151
00:07:26.279 --> 00:07:28.480
<v Speaker 2>You got it. You need a traffic cop out front

152
00:07:28.720 --> 00:07:32.360
<v Speaker 2>reverse proxy precisely. Typically you'd use something like in jincs.

153
00:07:32.759 --> 00:07:36.759
<v Speaker 2>Jinx is fantastic at handling tons and tons of simultaneous connections.

154
00:07:37.199 --> 00:07:40.519
<v Speaker 2>It does a few key things. It can load balance

155
00:07:40.600 --> 00:07:42.959
<v Speaker 2>traffic if you have multiple guncorn.

156
00:07:42.399 --> 00:07:43.959
<v Speaker 1>Workers, spreads the load yep.

157
00:07:44.480 --> 00:07:48.360
<v Speaker 2>It can also cash static files your images, CSS, JavaScript.

158
00:07:48.600 --> 00:07:51.439
<v Speaker 2>That stuff doesn't need to hit the Python app every time,

159
00:07:51.800 --> 00:07:54.560
<v Speaker 2>and jinc serves it directly, which is super.

160
00:07:54.240 --> 00:07:56.600
<v Speaker 1>Fast, takes load off the application server exactly.

161
00:07:56.839 --> 00:08:00.120
<v Speaker 2>It only forwards the request that actually need dynamic processing,

162
00:08:00.199 --> 00:08:03.120
<v Speaker 2>like fetching data from a database back to Gunnicorn. This

163
00:08:03.279 --> 00:08:06.800
<v Speaker 2>massively reduces the CPU load on your application servers and

164
00:08:06.879 --> 00:08:09.240
<v Speaker 2>makes everything much faster and more responsive.

165
00:08:09.480 --> 00:08:12.800
<v Speaker 1>Okay, so now we have this perfectly packaged production ready

166
00:08:12.839 --> 00:08:16.000
<v Speaker 1>container with then Jenks and Gunnicorn and our app. But

167
00:08:16.079 --> 00:08:19.120
<v Speaker 1>one container isn't usually enough, is it? What happens when

168
00:08:19.160 --> 00:08:22.759
<v Speaker 1>we need hundreds running across lots of physical machines, Doctor

169
00:08:22.800 --> 00:08:23.680
<v Speaker 1>swarm maybe isn't.

170
00:08:23.600 --> 00:08:27.079
<v Speaker 2>Quite enough right at that scale, you need serious orchestration.

171
00:08:27.519 --> 00:08:31.399
<v Speaker 2>You need Kubernetes K eight's the eight hundred pound Gorilla

172
00:08:31.519 --> 00:08:35.000
<v Speaker 2>pretty much. It's the standard now originally based on Google's

173
00:08:35.000 --> 00:08:39.519
<v Speaker 2>internal system called Borg. When you're managing hundreds, maybe thousands

174
00:08:39.519 --> 00:08:44.600
<v Speaker 2>of containers, the real challenge is maintaining the state you want. Declaratively,

175
00:08:45.360 --> 00:08:47.639
<v Speaker 2>you tell Kubernetes I want five copies of my web

176
00:08:47.639 --> 00:08:49.120
<v Speaker 2>server running and it makes it happen.

177
00:08:49.240 --> 00:08:51.799
<v Speaker 1>How does it manage that? What are the key concepts

178
00:08:51.799 --> 00:08:52.519
<v Speaker 1>we need to grasp?

179
00:08:52.639 --> 00:08:56.159
<v Speaker 2>Okay, three key objects to start with. First is the pod.

180
00:08:56.279 --> 00:08:58.840
<v Speaker 2>That's the smallest thing you can employ in Kubernetes. It's

181
00:08:58.879 --> 00:09:02.360
<v Speaker 2>basically one or moreiners that are always scheduled together, run

182
00:09:02.399 --> 00:09:05.679
<v Speaker 2>on the same node, and share resources like networking and storage.

183
00:09:05.879 --> 00:09:08.200
<v Speaker 1>So a pod might have my Jinx container and my

184
00:09:08.240 --> 00:09:09.720
<v Speaker 1>Gunicorn container running.

185
00:09:09.440 --> 00:09:12.679
<v Speaker 2>Side by side exactly. Then you have the deployment. Think

186
00:09:12.720 --> 00:09:15.559
<v Speaker 2>of this as the rulebook for your application. It defines

187
00:09:15.679 --> 00:09:18.240
<v Speaker 2>how many copies or replicas of a pod you want

188
00:09:18.279 --> 00:09:21.320
<v Speaker 2>running at all times. If a pod crashes, the deployment

189
00:09:21.360 --> 00:09:24.120
<v Speaker 2>controller notices and starts a new one automatically to get

190
00:09:24.120 --> 00:09:25.240
<v Speaker 2>back to the desired.

191
00:09:24.960 --> 00:09:29.480
<v Speaker 1>Number self healing. Nice. Okay, pods are the runners, deployments

192
00:09:29.519 --> 00:09:32.080
<v Speaker 1>are the rules. What's the third piece? How do users

193
00:09:32.120 --> 00:09:35.000
<v Speaker 1>actually reach these pods? If they can come and go?

194
00:09:35.159 --> 00:09:38.600
<v Speaker 2>Ah, that's the service. Pods are ephemeral, right, They can

195
00:09:38.600 --> 00:09:41.919
<v Speaker 2>be destroyed and recreated, and they'll get new internal IP addresses.

196
00:09:42.120 --> 00:09:45.519
<v Speaker 2>You can't rely on those ips. A service provides a stable,

197
00:09:45.799 --> 00:09:49.200
<v Speaker 2>single point of contact. It maps a fixed IP address

198
00:09:49.360 --> 00:09:53.240
<v Speaker 2>maybe an internal cluster IP or an external load balancer IP,

199
00:09:53.519 --> 00:09:55.840
<v Speaker 2>to the group of pods managed by a deployment.

200
00:09:55.960 --> 00:09:58.159
<v Speaker 1>So the service acts like a permanent front door even

201
00:09:58.200 --> 00:09:59.879
<v Speaker 1>if the rooms behind it keep changing.

202
00:10:00.039 --> 00:10:04.279
<v Speaker 2>Perfect analogy. It ensures traffic gets to healthy pods, enabling

203
00:10:04.320 --> 00:10:07.759
<v Speaker 2>real scaling and resilience without users noticing pods restarting.

204
00:10:07.799 --> 00:10:10.200
<v Speaker 1>Okay, it makes sense, But now we have potentially thousands

205
00:10:10.240 --> 00:10:13.879
<v Speaker 1>of these pods spitting out logs across maybe hundreds of servers.

206
00:10:14.240 --> 00:10:15.440
<v Speaker 1>Checking logs manually is.

207
00:10:15.480 --> 00:10:18.960
<v Speaker 2>Impossible, utterly impossible. Forget tailing log files at this scale.

208
00:10:19.000 --> 00:10:20.840
<v Speaker 2>You need centralized logging instantly, and.

209
00:10:20.759 --> 00:10:22.240
<v Speaker 1>That's where the efkstack comes in.

210
00:10:22.519 --> 00:10:27.600
<v Speaker 2>Yeah, EFK, elastic Search, Fluent, and Cubana. It's pretty standard

211
00:10:27.639 --> 00:10:31.679
<v Speaker 2>practice in Cubernetes environments. Flunid is the log collector and shipper.

212
00:10:31.840 --> 00:10:34.279
<v Speaker 2>It usually runs as a small agent on every single

213
00:10:34.320 --> 00:10:37.039
<v Speaker 2>node in your cluster, grabs all the container log streams

214
00:10:37.039 --> 00:10:39.840
<v Speaker 2>and sends them off, sends them where to elastic search.

215
00:10:39.879 --> 00:10:43.000
<v Speaker 2>That's the powerhouse. It receives all these logs, parses them,

216
00:10:43.159 --> 00:10:45.960
<v Speaker 2>indexes them so they're searchable, and stores them. It's built

217
00:10:46.000 --> 00:10:48.399
<v Speaker 2>for handling huge volumes of text data.

218
00:10:48.559 --> 00:10:52.360
<v Speaker 1>Okay, logs collected, indexed, how do we actually use them?

219
00:10:52.480 --> 00:10:55.440
<v Speaker 2>That's Cubana. Cubana is the web interface on top of

220
00:10:55.519 --> 00:10:58.440
<v Speaker 2>elastic Search. It lets you search across all your logs

221
00:10:58.480 --> 00:11:01.039
<v Speaker 2>from all your containers in near real time. You can

222
00:11:01.080 --> 00:11:05.399
<v Speaker 2>search for specific errors, filter by application, timeframe, whatever you need.

223
00:11:05.840 --> 00:11:09.200
<v Speaker 2>Plus you can create dashboards visualized trends like graphing the

224
00:11:09.279 --> 00:11:11.799
<v Speaker 2>number of four hundred and four or five hundred errors

225
00:11:11.799 --> 00:11:15.039
<v Speaker 2>over time, invaluable for troubleshooting and monitoring.

226
00:11:15.279 --> 00:11:17.919
<v Speaker 1>Right, so, we've built the infrastructure, we've containerized and scaled

227
00:11:17.919 --> 00:11:21.159
<v Speaker 1>the application. We're logging everything centrally. But there's another big

228
00:11:21.240 --> 00:11:25.840
<v Speaker 1>challenge organizations face today dealing with multiple cloud providers, the

229
00:11:25.960 --> 00:11:30.960
<v Speaker 1>rise of multi cloud. We've got the big three AWS, GCP, Azure.

230
00:11:30.720 --> 00:11:33.759
<v Speaker 2>Yep, the titans AWS is you know, the original Giant

231
00:11:33.840 --> 00:11:36.639
<v Speaker 2>still the main player, has an absolutely massive range of

232
00:11:36.679 --> 00:11:39.279
<v Speaker 2>services for almost anything, would be full choice for many

233
00:11:39.399 --> 00:11:43.440
<v Speaker 2>often Yeah, then you've got GCP, Google Cloud a bit newer,

234
00:11:43.559 --> 00:11:46.440
<v Speaker 2>often seen as being strong in data analytics and machine learning,

235
00:11:46.519 --> 00:11:49.919
<v Speaker 2>things like big Query for huge data sets, specialized hardware

236
00:11:49.960 --> 00:11:53.919
<v Speaker 2>for tensoflow, and sometimes it's cheaper, especially for raw compute power.

237
00:11:54.000 --> 00:11:54.919
<v Speaker 1>Interesting and Azure.

238
00:11:55.159 --> 00:11:58.360
<v Speaker 2>Azure is Microsoft's cloud, so its big strength is integration

239
00:11:58.440 --> 00:12:01.799
<v Speaker 2>with the Microsoft ecosystem. If your company relies heavily on

240
00:12:01.879 --> 00:12:05.240
<v Speaker 2>Windows Server Active Directory SQL server. Azure often makes the

241
00:12:05.279 --> 00:12:08.519
<v Speaker 2>most sense, is generally seen as very reliable, very enterprise focus,

242
00:12:08.559 --> 00:12:11.000
<v Speaker 2>but often the most expensive of the three.

243
00:12:11.159 --> 00:12:14.039
<v Speaker 1>Okay, so they each have their niches. But the problem

244
00:12:14.080 --> 00:12:16.480
<v Speaker 1>comes when a company wants to use services from more

245
00:12:16.480 --> 00:12:20.200
<v Speaker 1>than one. Right, maybe they need Azure Active Directory for identity,

246
00:12:20.360 --> 00:12:23.320
<v Speaker 1>by the one GCP's Big Query for analytics, and perhaps

247
00:12:23.360 --> 00:12:26.120
<v Speaker 1>they run some Core apps on AWS using Dynamo dB.

248
00:12:26.279 --> 00:12:31.240
<v Speaker 2>Exactly that's becoming super common. But managing that Each cloud

249
00:12:31.279 --> 00:12:33.480
<v Speaker 2>has its own way of doing things, its own dashboard,

250
00:12:33.559 --> 00:12:38.840
<v Speaker 2>and crucially, its own command line interface the awscli, Google's

251
00:12:38.919 --> 00:12:42.679
<v Speaker 2>u cloud Cli, azures as cli. They all work differently,

252
00:12:42.720 --> 00:12:44.279
<v Speaker 2>different commands, different syntax.

253
00:12:44.360 --> 00:12:46.320
<v Speaker 1>It's chaos trying to automate across them.

254
00:12:46.360 --> 00:12:51.759
<v Speaker 2>Total chaos, inconsistent, complex, aero prone. And that specific problem

255
00:12:51.799 --> 00:12:56.480
<v Speaker 2>managing infrastructure consistently across multiple providers is exactly what Hashi

256
00:12:56.519 --> 00:12:58.080
<v Speaker 2>Core's Terraform was built to solve.

257
00:12:58.159 --> 00:13:00.240
<v Speaker 1>Caere Form the big name in IAC.

258
00:13:00.080 --> 00:13:03.159
<v Speaker 2>It's become the de facto standard for multi cloud infrastructure

259
00:13:03.279 --> 00:13:05.600
<v Speaker 2>s code. Its brilliance is that it lets you define

260
00:13:05.600 --> 00:13:10.039
<v Speaker 2>your infrastructure, servers, databases, networks, load balancers, everything using one

261
00:13:10.159 --> 00:13:12.879
<v Speaker 2>single universal syntax. In its configuration.

262
00:13:12.399 --> 00:13:14.519
<v Speaker 1>Files one syntax for all clouds.

263
00:13:14.279 --> 00:13:17.840
<v Speaker 2>One syntax. You write your Terraform code describing what you want,

264
00:13:18.120 --> 00:13:20.759
<v Speaker 2>and Terraform itself figures out how to talk to the

265
00:13:20.799 --> 00:13:25.440
<v Speaker 2>specific APIs of AWS or GCP or Azure or dozens

266
00:13:25.480 --> 00:13:27.000
<v Speaker 2>of other providers to make it happen.

267
00:13:27.480 --> 00:13:31.039
<v Speaker 1>So if Vagrant brought iac to managing single vms easily,

268
00:13:31.600 --> 00:13:35.200
<v Speaker 1>Terraform brings that same declarative power to managing your entire

269
00:13:35.600 --> 00:13:37.440
<v Speaker 1>complex multi cloud setup.

270
00:13:37.600 --> 00:13:39.600
<v Speaker 2>That's a great way to put it. It manages the

271
00:13:39.639 --> 00:13:42.879
<v Speaker 2>state of your whole infrastructure, and probably its most critical

272
00:13:42.919 --> 00:13:45.799
<v Speaker 2>feature isn't even the apply part. It's the safety that

273
00:13:45.879 --> 00:13:47.840
<v Speaker 2>it provides before you apply changes.

274
00:13:48.080 --> 00:13:49.519
<v Speaker 1>You mean, the planning step.

275
00:13:49.320 --> 00:13:52.840
<v Speaker 2>Absolutely, the Terraform plan command before you actually change anything.

276
00:13:52.960 --> 00:13:56.240
<v Speaker 2>You run plan Terraform reads your code, checks the current

277
00:13:56.279 --> 00:13:58.879
<v Speaker 2>state of your actual live infrastructure. It keeps track of

278
00:13:58.879 --> 00:14:01.279
<v Speaker 2>this in a state file and tells you precisely what

279
00:14:01.360 --> 00:14:02.320
<v Speaker 2>it intends to do.

280
00:14:02.519 --> 00:14:06.200
<v Speaker 1>What it will add, change or dot delete exactly.

281
00:14:06.240 --> 00:14:09.240
<v Speaker 2>It shows you this resource will be created, plus this

282
00:14:09.279 --> 00:14:12.320
<v Speaker 2>one will be modified, and the really scary one, this

283
00:14:12.360 --> 00:14:16.679
<v Speaker 2>resource will be destroyed. That preview, that ability to see

284
00:14:16.679 --> 00:14:20.279
<v Speaker 2>the potential impact and catch mistakes before you accidentally delete

285
00:14:20.279 --> 00:14:24.559
<v Speaker 2>your production database. It's an absolutely essential guardrail for managing

286
00:14:24.679 --> 00:14:26.519
<v Speaker 2>complex infrastructure safely.

287
00:14:26.840 --> 00:14:29.240
<v Speaker 1>Okay, we've used Terraform to build it. We use Docker

288
00:14:29.279 --> 00:14:31.799
<v Speaker 1>and Kubernators to deploy and scale the app. Yeah, what's

289
00:14:31.840 --> 00:14:34.799
<v Speaker 1>the final piece tying all this automation together, Getting code

290
00:14:34.840 --> 00:14:40.159
<v Speaker 1>from a developer's laptop into production reliably. The CICD pipeline right.

291
00:14:40.200 --> 00:14:44.480
<v Speaker 2>CICD often orchestrated by tools like Jenkins get lab, CI

292
00:14:44.679 --> 00:14:48.279
<v Speaker 2>GitHub actions. There are many CI stands for continuous integration.

293
00:14:48.039 --> 00:14:49.759
<v Speaker 1>Checking the code quality automatically.

294
00:14:49.840 --> 00:14:52.559
<v Speaker 2>Pretty much every time a developer commits code, the CI

295
00:14:52.639 --> 00:14:55.360
<v Speaker 2>server automatically pulls it, builds it, and runs a series

296
00:14:55.399 --> 00:14:58.840
<v Speaker 2>of checks unit tests, integration tests, maybe static code analysis

297
00:14:58.879 --> 00:15:01.519
<v Speaker 2>tools like linters. The goal is to catch bugs early

298
00:15:01.559 --> 00:15:04.919
<v Speaker 2>and often makes sense fail fast exactly. Then if all

299
00:15:04.919 --> 00:15:08.000
<v Speaker 2>those cichecks pass, you move to CD. That can mean

300
00:15:08.039 --> 00:15:12.519
<v Speaker 2>continuous delivery or continuous deployment. Continuous delivery means the code

301
00:15:12.559 --> 00:15:16.000
<v Speaker 2>is proven ready to deploy, maybe with one final manual

302
00:15:16.039 --> 00:15:19.080
<v Speaker 2>approval click. Continuous deployment means it goes all the way

303
00:15:19.120 --> 00:15:19.360
<v Speaker 2>out to.

304
00:15:19.360 --> 00:15:21.559
<v Speaker 1>Production automatically, now fully automated.

305
00:15:22.080 --> 00:15:24.799
<v Speaker 2>The goal is to be able to reliably push new

306
00:15:24.879 --> 00:15:29.840
<v Speaker 2>versions frequently. And this whole complex workflow, build, test, deploy

307
00:15:30.000 --> 00:15:33.159
<v Speaker 2>is itself defined as code, pipeline as code they call it.

308
00:15:33.559 --> 00:15:37.120
<v Speaker 2>So the delivery process itself is versioned, repeatable and auditible,

309
00:15:37.320 --> 00:15:38.399
<v Speaker 2>just like the infrastructure.

310
00:15:38.639 --> 00:15:41.200
<v Speaker 1>Okay, wow, we have really covered a lot of ground.

311
00:15:41.279 --> 00:15:43.039
<v Speaker 1>We went from the Linux foundation, the.

312
00:15:42.960 --> 00:15:46.840
<v Speaker 2>Different district RHL versus w Nbuntu, through Bash scripting, the

313
00:15:46.840 --> 00:15:50.480
<v Speaker 2>limitations there, and then the big philosophical leap to infrastructure

314
00:15:50.519 --> 00:15:54.320
<v Speaker 2>as code with tools like Vagrant and crucially paraform for

315
00:15:54.399 --> 00:15:55.279
<v Speaker 2>managing multi.

316
00:15:55.080 --> 00:15:57.279
<v Speaker 1>Cloud Declarative configuration became key.

317
00:15:57.360 --> 00:16:00.679
<v Speaker 2>Then we got into modern application delivery Docker cant the

318
00:16:00.879 --> 00:16:04.960
<v Speaker 2>jin scuncorn pattern and scaling it all with Kubernetes, understanding pods,

319
00:16:05.159 --> 00:16:08.559
<v Speaker 2>deployments and especially services to connect the moving parts and

320
00:16:08.600 --> 00:16:13.159
<v Speaker 2>not forgetting centralized logging with EFK for managing that scale.

321
00:16:13.279 --> 00:16:18.120
<v Speaker 1>Right, The whole journey shows this relentless drive towards automation.

322
00:16:17.799 --> 00:16:20.519
<v Speaker 2>Doesn't it the overarching theme? It isn't just knowing the

323
00:16:20.559 --> 00:16:23.840
<v Speaker 2>individual tools, is it. It's understanding that automation has to

324
00:16:23.879 --> 00:16:28.440
<v Speaker 2>deliver resilience, consistency and auditibility. That's the goal.

325
00:16:28.519 --> 00:16:30.360
<v Speaker 1>So let's leave you with a final thought to chew on.

326
00:16:31.120 --> 00:16:34.360
<v Speaker 1>If the ultimate goal for a professional DevOps engineer is

327
00:16:34.360 --> 00:16:37.840
<v Speaker 1>to build infrastructure that's so well defined by code that

328
00:16:37.879 --> 00:16:41.919
<v Speaker 1>you could literally destroy it and recreate it perfectly identically

329
00:16:42.200 --> 00:16:46.399
<v Speaker 1>in moments, what people often call immutable infrastructure the dream state.

330
00:16:46.799 --> 00:16:49.639
<v Speaker 1>Can you realistically achieve that by clicking around in cloud

331
00:16:49.679 --> 00:16:53.159
<v Speaker 1>provider dashboards or by relying on a patchwork of custom

332
00:16:53.240 --> 00:16:57.559
<v Speaker 1>Bash scripts? Or is the unified declarative plan and apply

333
00:16:57.679 --> 00:17:01.279
<v Speaker 1>approach of something like terraform the only truly sustainable way

334
00:17:01.279 --> 00:17:04.680
<v Speaker 1>to manage the sheer, complexity and scale of modern, often

335
00:17:04.759 --> 00:17:06.039
<v Speaker 1>multi cloud reality.

336
00:17:06.279 --> 00:17:08.559
<v Speaker 2>How you answer that probably defines your approach as a

337
00:17:08.559 --> 00:17:09.880
<v Speaker 2>modern engineer, something.

338
00:17:09.720 --> 00:17:11.920
<v Speaker 1>They think about. That's all the time we have for

339
00:17:11.960 --> 00:17:14.160
<v Speaker 1>this deep dive. Thanks for joining us, See you next time.