WEBVTT

1
00:00:14.320 --> 00:00:19.519
Hey, everybody, welcome to another
thrilling episode of Adventures and Develops. I'm

2
00:00:19.559 --> 00:00:24.760
your host today, Will Button and
joining me today is adar Shaw. Adarsh

3
00:00:24.800 --> 00:00:28.960
welcome, Thank you, thanks for
having me my pleasure. So do you

4
00:00:29.000 --> 00:00:32.280
want to give us a quick introduction
and tell us tell us what we're going

5
00:00:32.320 --> 00:00:35.880
to talk about today. Sure.
My name is Adashah. As you mentioned,

6
00:00:36.119 --> 00:00:40.159
I'm the founder and CEO at compus
Est. I've basically played a lot

7
00:00:40.200 --> 00:00:44.439
of different roles over the years,
from a developer to an architect, to

8
00:00:44.479 --> 00:00:50.399
a consultant to technical product owner,
mentor advisor. But I'm an engineer at

9
00:00:50.439 --> 00:00:56.520
HAUT who loves to build stuff that
helps business technology, stuff that helps run

10
00:00:56.560 --> 00:01:02.079
business. And right now I have
built up product as part of a company

11
00:01:02.560 --> 00:01:07.879
that I founded, and also do
some consulting and advising around the DevOps and

12
00:01:07.239 --> 00:01:15.040
infrastructure as code space right on.
So one of the things, and I

13
00:01:15.079 --> 00:01:18.000
want to jump in because I'm really
excited about this. One of the things

14
00:01:18.120 --> 00:01:23.359
that you put in one of the
articles I read from you was talking about

15
00:01:23.120 --> 00:01:29.159
not infrastructure's code, but environment is
code. Do you want to bring everybody

16
00:01:29.239 --> 00:01:34.200
up to speed on that? Yeah, definitely. So what I and some

17
00:01:34.280 --> 00:01:38.799
of the colleagues that I've worked with
realized over the years is like, an

18
00:01:38.879 --> 00:01:44.640
infrastructure code is great, right,
because it helps us automate provisioning of various

19
00:01:44.640 --> 00:01:49.799
infrastructure resources on cloud providers on premises. But what we realize is what people

20
00:01:49.840 --> 00:01:55.519
need is an entire environment. Right. Just having your networking or just having

21
00:01:55.599 --> 00:02:01.000
your EC two instances or what have
you, is not gonna give you everything

22
00:02:01.000 --> 00:02:07.120
you need to run your application.
So what I and my teams have done

23
00:02:07.120 --> 00:02:09.400
in the past is like kind of
go through this painful process of like,

24
00:02:09.680 --> 00:02:15.680
right, pipelines that run stuff,
connect various pieces of these if you think

25
00:02:15.680 --> 00:02:20.400
about it as lego pieces, like
bring them together and kind of those things

26
00:02:20.400 --> 00:02:25.879
get really complicated and very difficult to
manage. So what I kind of thinking

27
00:02:25.879 --> 00:02:30.240
about this more and more in the
last few years, I was like,

28
00:02:30.439 --> 00:02:35.039
you know what I mean, there
has to be a better way of bringing

29
00:02:35.080 --> 00:02:39.199
these pieces together. So started thinking
of this as a concept and eventually named

30
00:02:39.199 --> 00:02:45.439
it as environment as code. It's
just an abstraction over infrastructure is code that

31
00:02:45.560 --> 00:02:51.120
basically provides a way of defining an
entire infrastructure environment, right, not just

32
00:02:51.319 --> 00:02:57.199
a single component or a resource,
but also it manages state for the entire

33
00:02:57.319 --> 00:03:02.960
environment, including the dependencies between where
resources, and also supports best practices,

34
00:03:04.080 --> 00:03:08.039
right, Like when you look at
infrastructure is code, one way of getting

35
00:03:08.080 --> 00:03:14.599
this whole environment is by writing this
monolith infrastructure is code where you can put

36
00:03:14.680 --> 00:03:17.639
everything together. Right, that's not
a good practice, right, like thinking

37
00:03:17.639 --> 00:03:22.240
about loose coupling and things like that. So, yeah, that's kind of

38
00:03:22.360 --> 00:03:27.439
what I call it. Environment is
code. But basically it allows teams to

39
00:03:27.560 --> 00:03:34.759
deliver entire environment instead of individual infrastructure
resources rapidly and reliabily at scale. Yeah,

40
00:03:34.800 --> 00:03:38.000
whenever I just first read the term, it was like this huge light

41
00:03:38.039 --> 00:03:43.439
bulb went off, because I think
the term itself is so much more descriptive

42
00:03:43.520 --> 00:03:49.680
of what we're trying to accomplish many
times with infrastructure's code, because the infrastructure

43
00:03:49.680 --> 00:03:53.280
itself is just a component of the
overall environment, right, and each piece,

44
00:03:53.840 --> 00:04:00.439
each individual piece of the infrastructure is
pretty meaningless unless it's couple with all

45
00:04:00.479 --> 00:04:03.560
the different pieces of that environment.
And like you mentioned, I've built many

46
00:04:04.080 --> 00:04:11.960
environments using that monolith approach, and
then you have to update one dependency in

47
00:04:12.000 --> 00:04:16.319
there or change out one of the
components. And it follows very much along

48
00:04:16.360 --> 00:04:20.600
the lines of building a monolith software
application. You know, we're just making

49
00:04:20.680 --> 00:04:27.720
small changes, becomes this task that
you dread and procrastinate and hope that you

50
00:04:27.720 --> 00:04:30.000
don't have to do it, knowing
full well that you're going to have to

51
00:04:30.120 --> 00:04:32.480
anyway. Yeah, exactly, and
some of the other things. Right.

52
00:04:32.560 --> 00:04:38.480
So some of the principles that we
talk about it like immutability, right,

53
00:04:38.560 --> 00:04:44.560
So you want to be able to
easily provision a brand new set of Like

54
00:04:44.680 --> 00:04:47.639
let's say, if we talk about
servers, rather than updating and keeping a

55
00:04:47.720 --> 00:04:54.079
long lasting server in case of this, applying that same principle to an entire

56
00:04:54.199 --> 00:05:00.160
environment, right, So why keep
your various components living for long? Can

57
00:05:00.199 --> 00:05:05.680
you actually replicate an entire environment rather
than just an individual component. So for

58
00:05:05.759 --> 00:05:12.639
someone listening who's liking this idea and
wants to explore it further, what do

59
00:05:12.639 --> 00:05:18.600
you think the first steps to migrating
from infrastructure's code to environments as code is

60
00:05:19.240 --> 00:05:23.199
like, yeah, so, I
mean, like I said, I think

61
00:05:23.279 --> 00:05:29.040
it's just an abstraction. So thinking
about these various pieces and how they get

62
00:05:29.079 --> 00:05:34.399
together. So what we did is
we essentially to keep it really simple,

63
00:05:34.680 --> 00:05:40.079
is created a simple Yamel format.
Again, this is new, so I'm

64
00:05:40.240 --> 00:05:43.600
like a lot of that I'm saying, at least from my perspective what I've

65
00:05:43.600 --> 00:05:47.000
seen. I haven't seen anyone talk
about it this way, but it's new.

66
00:05:47.120 --> 00:05:53.879
So what we did is we provide
a very simple format, a yamal

67
00:05:53.959 --> 00:06:00.560
format that actually specify these individual resources
or components and how they connect with dependencies.

68
00:06:01.040 --> 00:06:06.399
I have an article that I think
I've shared that talks about the principles

69
00:06:06.399 --> 00:06:11.519
and how what this means. Yeah, I mean it's it's like I said

70
00:06:11.560 --> 00:06:15.720
early stage, So I would say, like something that allows you to create

71
00:06:15.759 --> 00:06:23.120
an abstraction on top of infrastructure's code, that gives you an entire environment rather

72
00:06:23.160 --> 00:06:27.279
than individual component, right, because
a lot of people, like I said,

73
00:06:27.360 --> 00:06:30.600
write pipelines right to do this,
and then you have to think about

74
00:06:30.639 --> 00:06:33.199
things like, hey, how do
I provision stuff? But how do I

75
00:06:33.240 --> 00:06:38.600
tear down right? Because teardown would
be totally totally opposite graph right, So

76
00:06:38.639 --> 00:06:43.079
you have to tear down those leaf
nodes first, and you just write all

77
00:06:43.079 --> 00:06:48.920
this complex logic if you've changed.
So defining an entire environment and easy format

78
00:06:49.600 --> 00:06:56.079
that provides ways to connect those lego
pieces if you talk about it, and

79
00:06:56.120 --> 00:07:01.600
then that takes and enterprets like into
visions, those individual pieces so that you

80
00:07:01.600 --> 00:07:06.279
get an entire environment. One of
the things you put in that article you

81
00:07:06.360 --> 00:07:11.600
mentioned in there about keeping everything in
source code, but then you added to

82
00:07:11.680 --> 00:07:15.639
that a little thing that I know
I've slipped up a lot in the past

83
00:07:15.680 --> 00:07:18.279
doing this, and I've encountered situations
where other people have done the same,

84
00:07:18.680 --> 00:07:23.879
like those one off scripts that you
only run ever once in a while,

85
00:07:24.399 --> 00:07:28.879
about how important it is to get
those into source control as well. Yeah,

86
00:07:28.920 --> 00:07:30.240
definitely, I mean I think,
yeah, talking about I think you're

87
00:07:30.240 --> 00:07:34.519
talking about the patterns and practices in
general for infrastructures, code environment because it

88
00:07:34.519 --> 00:07:38.040
doesn't matter. So yeah, like
I think, yeah, same, yeah,

89
00:07:38.160 --> 00:07:41.639
right in the situation where like hey, we just ran the script and

90
00:07:41.720 --> 00:07:46.319
you know, forget about it,
right, like you it's on someone's machine

91
00:07:46.560 --> 00:07:49.000
and then you try to find who
did that and how it was done.

92
00:07:49.279 --> 00:07:53.519
So yeah, I mean source control
being a place where you can track things,

93
00:07:53.600 --> 00:07:58.959
have auditing, right who pushed so
you can talk to the person about

94
00:07:59.000 --> 00:08:01.160
it. And so yeah, like
I think people say, like, hey,

95
00:08:01.240 --> 00:08:05.879
just put your terraform code or blow
me code or configuration know, everything

96
00:08:05.959 --> 00:08:09.800
including Bash scripts that are lying stuff
like you know that you use once in

97
00:08:09.839 --> 00:08:15.000
a while, everything needs to go
there. Yeah, what about documentation?

98
00:08:15.160 --> 00:08:18.720
Do you like documentation in the code
itself or do you have a preferred tool

99
00:08:18.759 --> 00:08:24.199
like Confluence or something else for keeping
track of docs? Yeah? Yeah,

100
00:08:24.319 --> 00:08:28.560
I mean so one of the things
is docs is like a lot of people

101
00:08:28.560 --> 00:08:31.800
say this, like, hey,
you do infrastructures code or like everything is

102
00:08:31.800 --> 00:08:35.600
in code, why do you white
you need documentation right? And it's just

103
00:08:35.840 --> 00:08:39.840
I mean, yes, you don't. You need less documentation, but you

104
00:08:39.919 --> 00:08:46.240
still need documentation right, And in
general documentation it's hard I understand. But

105
00:08:46.759 --> 00:08:48.000
so like like a lot of people
are like and I used to at one

106
00:08:48.000 --> 00:08:50.279
point, I was like, hey, we don't need documentation because you know

107
00:08:50.360 --> 00:08:56.200
everything is codified, but you still
need right and talking about documentation right,

108
00:08:56.320 --> 00:09:01.600
quality documentation, making it a well
bill where let's say there is an error,

109
00:09:01.799 --> 00:09:05.759
provide a link that can take a
person who's actually looking at it directly

110
00:09:05.840 --> 00:09:11.720
to that. And also it's just
providing a way to keep it updated,

111
00:09:11.919 --> 00:09:16.279
right, so like I can draw
a diagram or like write documentation and just

112
00:09:16.360 --> 00:09:20.360
you know, like hey, it's
out of date, it's not going to

113
00:09:20.360 --> 00:09:26.159
be useful because it's actually giving you
wrong information. So yeah, like I

114
00:09:26.320 --> 00:09:31.039
prefer obviously have naming things better in
your code, right, because that tells

115
00:09:31.039 --> 00:09:37.279
you what it is. But definitely
have some documentation that's external to the code

116
00:09:37.279 --> 00:09:41.200
that will get you started. Even
it could be like, hey, here's

117
00:09:41.240 --> 00:09:45.879
an index of things that you look
at. This is how you onboard a

118
00:09:46.000 --> 00:09:50.000
team member or a customer or a
user of your system. Also look at

119
00:09:50.000 --> 00:09:56.080
things like run books, right,
that helps you look at specific scenarios around

120
00:09:56.279 --> 00:10:03.000
troubleshooting and things like that. Another
important aspect about documentation is like, not

121
00:10:03.159 --> 00:10:07.559
everything is automated, and you actually
don't need to automate everything right away,

122
00:10:07.679 --> 00:10:11.559
right, But you hit that second
or third time you're trying to do the

123
00:10:11.559 --> 00:10:16.360
same thing. Maybe document at first
if it things are not automated, and

124
00:10:16.399 --> 00:10:18.879
then use that run book or what
have you to actually automate things later,

125
00:10:18.960 --> 00:10:24.159
right, because that way there is
a progression into getting to that automated state.

126
00:10:26.120 --> 00:10:30.279
Yeah. I think that's a really
good point, Like everything doesn't have

127
00:10:30.399 --> 00:10:35.320
to be automated because some things,
like in my experience, one of the

128
00:10:35.519 --> 00:10:39.759
common scenarios I've hit over and over
again. I work a lot with early

129
00:10:39.759 --> 00:10:45.799
stage startups, and so we'll build
stuff and then that will fail and it

130
00:10:45.840 --> 00:10:48.960
just gets scrapped and never comes back
to life. And so when I think

131
00:10:50.000 --> 00:10:52.320
about automating things, you know,
I try to automate the things that are

132
00:10:52.360 --> 00:10:58.679
going to survive into the future,
and it seems to save a lot of

133
00:10:58.720 --> 00:11:03.639
time. And I know that's there's
a tendency to automate everything, but for

134
00:11:03.720 --> 00:11:07.200
some things that just are going to
fail fast and then disappear and never be

135
00:11:07.279 --> 00:11:11.440
brought back to life again, you
can actually move a lot faster if you

136
00:11:11.519 --> 00:11:15.240
don't try to automate those. Yeah, yeah, I mean exactly. Especially

137
00:11:15.320 --> 00:11:20.279
let's say you have there is an
error in one of your environments, and

138
00:11:20.320 --> 00:11:24.919
then it's like fixing or troubleshooting,
right, even documenting those steps and then

139
00:11:26.000 --> 00:11:31.159
eventually using that documentation to actually have
a fix. Right. Because so whenever

140
00:11:31.200 --> 00:11:37.320
you talk about environments as code,
is there a right size of team or

141
00:11:37.480 --> 00:11:41.000
environment where it starts to make sense
to implement this, Yeah, And I

142
00:11:41.039 --> 00:11:46.120
think, yeah, it's like if
you have a very simple setup, Yeah,

143
00:11:46.320 --> 00:11:50.080
it doesn't make sense to start complicating
things because obviously with this like that

144
00:11:50.519 --> 00:11:54.120
also comes a little bit of complication. So yeah, I mean I think

145
00:11:54.840 --> 00:11:58.000
I don't have a number for that, but I would say it's like a

146
00:11:58.039 --> 00:12:05.000
typical setup where you have various layers
of your environments, right, so your

147
00:12:05.480 --> 00:12:11.960
networking layer, your platform layer,
your application infrastructure layer, right like databases

148
00:12:11.000 --> 00:12:15.960
and things like that. Once you
get into those kind of things, and

149
00:12:16.000 --> 00:12:22.440
an application is not like your setup
is not as straightforward as let's say I

150
00:12:22.519 --> 00:12:26.279
am just provisioning an easy to instance
or like just you know, using lambdas

151
00:12:26.360 --> 00:12:30.720
or what have you, right,
which is like very straightforward. Yeah,

152
00:12:30.759 --> 00:12:35.559
I would start thinking about it because
the other way to look at it as

153
00:12:35.600 --> 00:12:39.240
well is that, hey, let's
start with writing these pipelines, right that

154
00:12:39.840 --> 00:12:46.000
provision these to start with, and
then once you start feeling that pain of

155
00:12:46.120 --> 00:12:48.320
like adding the third component on the
fourth and I was like, okay,

156
00:12:48.440 --> 00:12:52.399
now this is getting like how do
we tear it down? Then start looking

157
00:12:52.440 --> 00:12:56.960
with anything in software, right,
don't overcomplicate to start with, But once

158
00:12:58.000 --> 00:13:01.919
you start feeling those pain think about
a way to abtract it, which makes

159
00:13:01.960 --> 00:13:05.679
sense for provisioning the entire environment.
I think we can come up with a

160
00:13:05.679 --> 00:13:09.200
new buzzword there. Instead of test
driven development, we can call it pain

161
00:13:09.320 --> 00:13:15.440
driven development. I love it.
Yeah, that's awesome. It seems to

162
00:13:15.440 --> 00:13:20.519
be my big motivator. Yeah,
so you've got you've got some thoughts here

163
00:13:20.559 --> 00:13:24.480
on testing. What is what are
your what's your high level overview of the

164
00:13:24.559 --> 00:13:28.320
type of testing that you need to
have wrapped around us? Yeah, so

165
00:13:28.440 --> 00:13:33.919
testing for infrastructure's code environment code as
in I mean thinking about the test pyrament

166
00:13:35.039 --> 00:13:37.519
that we keep talking about when we
talk about application testing, right, so

167
00:13:37.639 --> 00:13:43.600
kind of similar idea, but obviously
it's different, right, Like, writing

168
00:13:43.679 --> 00:13:48.639
unit tests for your infrastructure's code is
going to be complex. I mean,

169
00:13:48.639 --> 00:13:54.000
there are tools that allow you to
whether you need it is another question,

170
00:13:54.320 --> 00:13:58.159
right, So let's kind of Yeah, so let's kind of talk about a

171
00:13:58.240 --> 00:14:03.159
typical test pyramit for something like this. I start with at the bottom,

172
00:14:03.240 --> 00:14:07.080
it's like do static analysis, right, So if you're doing terraform, like

173
00:14:07.200 --> 00:14:11.919
do things like terraform validate, you
have lend or maybe you're using Puppet or

174
00:14:11.919 --> 00:14:18.919
what have you, Like, all
of these tools have some static analysis tool.

175
00:14:18.200 --> 00:14:24.759
When you get into unit testing,
it really depends. What I tend

176
00:14:24.759 --> 00:14:31.480
to suggest is like if it's something
like terraform that is declarative that actually allows

177
00:14:31.519 --> 00:14:37.039
you to define the desired state,
and it's Terraform's responsibility to actually get you

178
00:14:37.120 --> 00:14:43.279
to that desired state versus more like
your conditionals and things like that, where

179
00:14:43.279 --> 00:14:46.440
you need to write some complex unit
tests and things like that. I would

180
00:14:46.480 --> 00:14:50.720
say you don't need unit tests when
you're talking about declarative stuff because you are

181
00:14:50.759 --> 00:14:56.519
not writing that logic to actually make
something happen. You're just defining a desired

182
00:14:56.679 --> 00:15:01.799
state there. And then it's the
tools shop, right, so if there's

183
00:15:01.799 --> 00:15:03.960
a failure within the tool itself,
it'll tell you that, hey, you

184
00:15:05.120 --> 00:15:07.440
can't get you to that desa state. So like most of the cases,

185
00:15:07.480 --> 00:15:13.080
you don't have those those complex logic
right. But then if you move up

186
00:15:13.200 --> 00:15:18.360
this pyramid, you talk about integration
tests, right, which makes sense in

187
00:15:18.399 --> 00:15:24.200
this case. Could be like in
your provisioning pipeline or whatever you're using,

188
00:15:24.559 --> 00:15:28.360
you can bring up an epheneral environment, a temporary environment and then run some

189
00:15:28.480 --> 00:15:33.799
tests against that. So let's say
you need a setup with networking and like

190
00:15:33.840 --> 00:15:37.720
some platforms like EKS and what have
you, you can run some basic integration

191
00:15:37.840 --> 00:15:43.879
tests to see like if those resources
have the things like for example, running

192
00:15:43.000 --> 00:15:46.879
to make sure like hey, none
of your S three buckets are public,

193
00:15:46.919 --> 00:15:50.080
for example, So you do those
things ahead of time rather than when you

194
00:15:50.120 --> 00:15:54.720
actually provision that production environment, right, so you don't want to be finding

195
00:15:54.759 --> 00:15:58.679
those issues late. Right. And
then the last one there is like which

196
00:15:58.679 --> 00:16:04.039
I have useful, is like the
best pace to test your infrastructure or environment

197
00:16:04.039 --> 00:16:08.279
that you have provisioned is by running
deploying a dummy app. So let's say

198
00:16:08.320 --> 00:16:12.759
you're provisioning a Kuberne dis cluster.
You can run like one simple dummy app

199
00:16:12.759 --> 00:16:18.480
that is close to what you would
be typically running and then run some smoke

200
00:16:18.559 --> 00:16:22.159
tests just to see, like,
you know, if you can get there.

201
00:16:22.600 --> 00:16:26.639
So again, it's a test bit
of it. So at the bottom

202
00:16:26.840 --> 00:16:30.679
where you're static analysis and things like
that, you'll have more of those tests

203
00:16:30.759 --> 00:16:33.519
rather than and when you as you
go up the pyramid, you have less

204
00:16:33.519 --> 00:16:37.600
of these tests because they are more
expensive and time consuming. Yeah. Yeah,

205
00:16:37.639 --> 00:16:41.600
exactly. And I think one of
the things you said in there that

206
00:16:41.759 --> 00:16:47.039
I really want to call attention to
is talking about unit tests. And with

207
00:16:47.120 --> 00:16:52.879
a declarative type framework like Terraform,
there's really not a lot of value in

208
00:16:52.120 --> 00:16:56.559
unit tests because at that point you're
testing like did the tool actually do its

209
00:16:56.720 --> 00:17:02.639
job? And a tool like Terraform
already has tests to cover that, so

210
00:17:02.720 --> 00:17:07.680
you can you can save yourself a
lot of time and effort by just acknowledging

211
00:17:07.240 --> 00:17:11.759
what tests the tool has the test
that the tool is doing its job.

212
00:17:12.279 --> 00:17:15.519
Right. But yeah, I mean
if you're writing let's say Bash maybe like

213
00:17:15.599 --> 00:17:18.880
when you have all this logic,
then in that case that's different. Yeah.

214
00:17:18.920 --> 00:17:26.039
So how do you deal with baking
security into the environment? Yeah,

215
00:17:26.079 --> 00:17:29.559
and that's the thing a lot of
people, I mean, that's a very

216
00:17:29.839 --> 00:17:33.079
important aspect, right, and a
lot of people tend to like, hey,

217
00:17:33.119 --> 00:17:34.799
what do we need to care about
security here? But yeah, I

218
00:17:34.799 --> 00:17:40.440
mean I think a few different things
to consider. One is you with with

219
00:17:40.559 --> 00:17:45.000
these tools, right, since it's
automated, you need to give these languages,

220
00:17:45.160 --> 00:17:48.920
tools or whatever it's running access to
your aid abous azure or whatever you're

221
00:17:49.000 --> 00:17:53.720
using to actually provision these right.
So the easiest thing is give root access

222
00:17:53.799 --> 00:17:57.400
everything. You can do everything,
and then you know if it's compromised.

223
00:17:57.480 --> 00:18:03.079
Right. So I think one of
the things is using a role based access

224
00:18:03.119 --> 00:18:10.640
control or trying to limit the surface
area of attack, right and looking at

225
00:18:10.960 --> 00:18:15.720
if there are various layers of your
infrastructure environment, maybe having different roles for

226
00:18:15.839 --> 00:18:21.279
those that give limited access to doing
those things, because specially when you have

227
00:18:21.319 --> 00:18:26.319
production running, one credential gets compromised
or so, like you can compromise basically

228
00:18:26.440 --> 00:18:33.079
give and I've had those issues that
I've gone through it with multiple customers,

229
00:18:33.079 --> 00:18:37.319
so that'll just stop everything, right, like the whole thing is compromised,

230
00:18:37.680 --> 00:18:41.319
rather than saying like, hey there's
limited access, so even if things are

231
00:18:41.319 --> 00:18:45.640
compromised, the surface area is That's
another thing you can do is if you

232
00:18:45.759 --> 00:18:52.519
use tools like hashikore Vault or I
think even Secrets Manager AWS they have a

233
00:18:52.759 --> 00:18:59.240
rotation policy, right, so you
can you can have these dynamic credentials created

234
00:18:59.799 --> 00:19:04.960
that then used. So again it's
time based they expire, right, so

235
00:19:06.079 --> 00:19:11.599
like you're not exposing it for a
long time. But in general, you

236
00:19:11.680 --> 00:19:17.799
need secrets right when you are provisioning
your environments or infrastructure. So keep it

237
00:19:17.839 --> 00:19:21.000
in in general, like just basics, right, keep it in some kind

238
00:19:21.039 --> 00:19:26.960
of a good secrets management tool which
which stores that and then also looking at

239
00:19:26.000 --> 00:19:33.319
things like security scanning, so basically
running those as part of your provisioning process

240
00:19:33.400 --> 00:19:37.440
early on where you can spin up
a firmeral environments. There are tools like

241
00:19:37.519 --> 00:19:44.079
CES Benchmark, the Amazon airfs as
inspector and things like that that allows you

242
00:19:44.160 --> 00:19:49.240
to run these security tests or scanning
to see like if you have things exposed

243
00:19:49.319 --> 00:19:53.920
right like is your S three buket
public somehow, or like your databases are

244
00:19:53.920 --> 00:19:59.720
exposed and things like that, so
it'll also check for other vulnerabilities. So

245
00:19:59.799 --> 00:20:03.400
yeah, I mean these are some
of the things. Writing some common security

246
00:20:03.440 --> 00:20:08.039
tests like using inspect and things like
that also help. Like where it could

247
00:20:08.039 --> 00:20:14.279
be like just any infrastructure environment you
provision, we just run these kind of

248
00:20:14.359 --> 00:20:19.720
common security tests to see like your
network is secured, your resources that secure

249
00:20:19.880 --> 00:20:23.400
would also be a good idea.
Yeah, And I think that's one of

250
00:20:23.480 --> 00:20:30.440
the one of the possibly hidden benefits
to using this approach that you've got of

251
00:20:30.480 --> 00:20:36.400
the environment the environment based approach,
because like if you have this monolith infrastructure

252
00:20:36.839 --> 00:20:40.559
and you have security groups in there, you've got to think about this security

253
00:20:40.559 --> 00:20:44.200
group, say okay, this security
group they need access to my sequel and

254
00:20:44.279 --> 00:20:48.480
elastic search and the reddest cache,
and then there's an API serve, and

255
00:20:48.519 --> 00:20:52.759
there's all these different rules and exceptions
and all that kind of stuff in there

256
00:20:52.880 --> 00:20:57.640
that creates this huge vulnerability footprint.
But if you break it down like you're

257
00:20:57.960 --> 00:21:03.640
recommending here, where everything is just
a component, then you can when you're

258
00:21:03.640 --> 00:21:07.200
building out that component, you can
say, well, this component needs to

259
00:21:07.240 --> 00:21:11.559
talk to postgrass, so we'll open
the postgrass port and you don't have to

260
00:21:11.559 --> 00:21:15.720
open anything else up. And then
when you tear it down, you know

261
00:21:15.799 --> 00:21:18.799
that you can safely tear down that
security group because you know the one and

262
00:21:18.880 --> 00:21:23.720
only place that it was ever used. Yeah, exactly. And one of

263
00:21:23.759 --> 00:21:27.640
the things that I talk about when
I talk about environment, it's called is

264
00:21:27.720 --> 00:21:33.359
like blueprints or templates for your entire
environment. Right, So if you build

265
00:21:33.400 --> 00:21:40.440
these blueprints using best practices, keeping
security compliance and other best practices in mind,

266
00:21:40.720 --> 00:21:44.799
essentially you can you can templatize it
and then kind of use that and

267
00:21:44.839 --> 00:21:48.680
say like, hey, we did
this and this is like certified or you

268
00:21:48.720 --> 00:21:55.640
know, by our team, and
then you can share it with other teams

269
00:21:55.680 --> 00:21:59.640
within your arc. So that gives
you that versus if you look at like,

270
00:21:59.680 --> 00:22:03.759
you know, doing it using pipeline
or other things, it's very different,

271
00:22:03.079 --> 00:22:07.640
difficult to like, you know,
creates these templates for the entire environment.

272
00:22:10.119 --> 00:22:15.400
Yeah, because once you change the
pipeline, everything downstream is now in

273
00:22:15.640 --> 00:22:19.119
an unknown state. Yeah. Plus
these pipelines are not meant to run these

274
00:22:19.119 --> 00:22:23.319
things. They are more generic and
then like you write all the logic to

275
00:22:23.359 --> 00:22:27.279
make whatever happen, right, so
it just gets complicated. So, speaking

276
00:22:27.319 --> 00:22:33.079
of the pipeline, whenever you do
the infrastructure and build this out, what

277
00:22:33.119 --> 00:22:38.359
are the pros and cons of using
an autumn using a tool like jink injer

278
00:22:38.400 --> 00:22:44.920
circle CI to deploy this out versus
writing it and building it and deploying it

279
00:22:45.200 --> 00:22:48.720
manually. Yeah, yeah, I
mean it's it's a very important aspect,

280
00:22:48.759 --> 00:22:52.359
especially when again, one thing I
say, like, if you have a

281
00:22:52.440 --> 00:22:56.079
very simple setup you're getting started,
maybe you don't need it right away because

282
00:22:56.160 --> 00:22:59.960
let's say you're the only developer,
like you know, you have a very

283
00:23:00.079 --> 00:23:04.799
small theme. But as you as
you grow and you look at provisioning and

284
00:23:04.960 --> 00:23:11.880
automating these things, having this shared
auto execution environment, right, I call

285
00:23:11.920 --> 00:23:18.039
it where things are set up which
are replicated, right, so hey it

286
00:23:18.119 --> 00:23:22.160
works on my machine problem right,
Like like hey I ran this, but

287
00:23:22.279 --> 00:23:25.680
oh you had this version of terraform
or this version of that, right,

288
00:23:25.759 --> 00:23:32.680
so you can avoid that. And
basically I feel like using any of these

289
00:23:32.720 --> 00:23:37.920
pipelines is one way, right or
that have this common setup that you use

290
00:23:37.960 --> 00:23:41.880
every time, right, So it's
not your machine, it's something that has

291
00:23:41.960 --> 00:23:45.880
all the tools and right versions and
things like that. That definitely gives that.

292
00:23:45.920 --> 00:23:51.000
It also gives visibility, especially if
you're running these tools a lot of

293
00:23:51.039 --> 00:23:55.119
times. You know they manage state, and if you've run a lot of

294
00:23:55.119 --> 00:23:59.119
times things locally, you have local
state and stuff like that. Moving all

295
00:23:59.200 --> 00:24:03.440
that to a ship place helps because
then you know, if I'm doing something

296
00:24:03.720 --> 00:24:07.200
one of my team members is running, they all go to the same place

297
00:24:07.240 --> 00:24:11.880
to do that. Also, there's
another way, gitups, which is more

298
00:24:11.920 --> 00:24:18.400
and more talked about recently, but
essentially how icy GitOps is. Basically,

299
00:24:18.720 --> 00:24:23.119
you take your infrastructure's code, add
a workflow to it, which is typically

300
00:24:23.160 --> 00:24:27.480
your PR process which all the developers
are used to. Is like, hey,

301
00:24:27.519 --> 00:24:32.359
create a PR, someone approves it. Once it's approved and merged to

302
00:24:32.480 --> 00:24:37.880
your main branch, it automatically provisions
that so now you don't need to push

303
00:24:37.920 --> 00:24:42.319
a button or do anything right,
but it also has this flow which I

304
00:24:42.359 --> 00:24:47.400
feel is a nice flow off,
like you know PR process, right,

305
00:24:47.440 --> 00:24:52.119
so you can have people approve it, take a look commented before you merge

306
00:24:52.160 --> 00:24:56.839
it. And then I also feel
in there that getups is like this control

307
00:24:56.920 --> 00:25:02.559
loop logic right that talks about this
detect th drift and kind of bringing back

308
00:25:02.640 --> 00:25:06.720
the desired state to actual state to
desired state if things go out of sync.

309
00:25:07.319 --> 00:25:11.920
So I feel like that getop's way
is another way of looking at it.

310
00:25:11.200 --> 00:25:18.960
When you're running your infrastructure's code or
environment code, but using like the Shared Environment