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