Narrator: Infrastructure as code or IAC. 2 2
Now, when we talk about infrastructure as code 3 3
this is a provisioning architecture 4 4
in which the deployment of resources is performed 5 5
by scripted automation and orchestration. 6 6
Now, we mentioned the fact that we use scripted automation 7 7
and orchestration in cloud computing all the time. 8 8
And when we do that 9 9
we're really doing infrastructure as code. 10 10
Now, this is key to the DevSecOps culture, 11 11
because it gives our teams the ability 12 12
to rapidly deploy things within the timeframe 13 13
of what they're working on. 14 14
And because they have operations personnel already there 15 15
and security personnel already there as part of that team 16 16
it's not any less secure by doing infrastructure as code. 17 17
In fact, you'll find it's actually more secure. 18 18
Now, why is it more secure? 19 19
Well, because it allows for the use of scripted approaches 20 20
to provisioning infrastructure in the cloud. 21 21
And the great things about scripts 22 22
is they don't make mistakes. 23 23
Once you have a script and you know it's working and secure 24 24
it's going to run that way every single time. 25 25
So this is going to allow you to get a lot 26 26
of those configurations done 27 27
and the provisioning done in a much more secure manner. 28 28
Now, when we talk about infrastructure as code 29 29
it really comes down to three key areas. 30 30
Part of this is going to be those scripts I just talked about. 31 31
Part of it's going to be security templates, 32 32
and part of it is going to be policies. 33 33
And by applying these three against your infrastructure 34 34
using this approach you're going to have 35 35
much more secure infrastructure. 36 36
Now, when we talk about this 37 37
we are going to have to think about our orchestration. 38 38
And if you have robust orchestration where you've tested it 39 39
and you know it works well, 40 40
then you can lower your overall IT costs, 41 41
speed up your deployments, and you can increase security. 42 42
So this is really a win-win-win. 43 43
It's all goodness here. 44 44
Now, one of the things you have to be careful though 45 45
when you're doing this infrastructure as code, 46 46
because we're using templates and standardization 47 47
for everything is people who want to have 48 48
their special snowflakes. 49 49
Now, when I talk about special snowflakes 50 50
you have people who think they just have the best idea 51 51
and therefore they have to be able to go 52 52
and create their own infrastructure 53 53
the way they want to do it. 54 54
And they don't care about your standardization 55 55
and your scripting and all the efficiencies you've gained. 56 56
And so they create something that is a one-off system. 57 57
Now, when you're a big advocate for using orchestration, 58 58
and using scripts, and using standardization 59 59
sometimes you're going to face some friction at work, 60 60
because somebody thinks they have a better idea 61 61
and they have this special snowflake system 62 62
that they just have to have, 63 63
and they can't use your standard templates. 64 64
Now, when that happens, you end up 65 65
with a special snowflake system. 66 66
And these snowflake systems or any system 67 67
that is different from the configuration, 68 68
that's compared to the standard template 69 69
within the infrastructure as code architecture. 70 70
Now, the problem with this is it adds to security problems. 71 71
It adds to configuration problems 72 72
and supportability problems. 73 73
This lack of consistency is going to lead 74 74
to a lot of issues for you, especially in terms of security 75 75
and inefficiencies in supporting it. 76 76
This is because once you have a one-off system, 77 77
it's unique and it doesn't apply to everything else. 78 78
Think about if you're in a large environment 79 79
that's operating in the cloud 80 80
and you have thousands of virtual machines, 81 81
and out of those thousands of virtual machines, 82 82
one is different. 83 83
When somebody calls up and says something isn't working, 84 84
you have to figure out is it that one exception, 85 85
or is it the thousands of others that are all working? 86 86
And that becomes more of a support issue for you, 87 87
and it leads to a lot of security headaches. 88 88
Now the last thing we need to talk 89 89
about in terms of infrastructure as code is it idempotence. 90 90
Now, this is a property of infrastructure as code 91 91
that automation or orchestration action is always 92 92
going to produce the same result, 93 93
regardless of the component's previous state. 94 94
Essentially, every time you give this input 95 95
you should expect this output. 96 96
Anytime you call up this script 97 97
it should be doing these functions, 98 98
and it should do it every single time. 99 99
That's why we want to eliminate those special snowflakes, 100 100
because we want everything to be consistent. 101 101
Now, by doing this and using carefully developed 102 102
and tested scripts, we can end up doing orchestration 103 103
really consistently. 104 104
We create these runbooks that are going to do all the steps 105 105
for us, that's what we call a script inside of orchestration 106 106
and it's going to generate these very consistent builds 107 107
that have a good security posture 108 108
and they're within compliance for us. 109 109
So really what I'm trying to say here is 110 110
eliminate the special snowflakes. 111 111
Don't allow them to happen. 112 112
If somebody wants to have a special snowflake system 113 113
there should be a really, really good reason for it 114 114
and it should go really high up 115 115
in your organization for approval. 116 116
The default answer should be no special snowflakes. 117 117
We're all going to use the same templates, the same security, 118 118
and the same orchestration, because we know it works 119 119
and it's easier for us to support, 120 120
and it gives us much better security.