-: Infrastructure as Code or IAC.
Now, when we talk about infrastructure as code,
this is a provisioning architecture
in which the deployment of resources is performed
by scripted automation and orchestration.
Now, we mentioned the fact that we use scripted automation
and orchestration in cloud computing all the time.
And when we do that,
we're really doing infrastructure as code.
Now, this is key to the DevSecOps culture
because it gives our teams the ability
to rapidly deploy things
within the timeframe of what they're working on,
and because they have operations personnel already there
and security personnel already there as part of that team,
it's not any less secure by doing infrastructure as code.
In fact, you'll find it's actually more secure.
Now, why is it more secure?
Well, because it allows for the use of scripted approaches
to provisioning infrastructure in the cloud.
And the great things about scripts is
they don't make mistakes.
Once you have a script and you know it's working and secure,
it's going to run that way every single time.
So, this is going to allow you
to get a lot of those configurations done
and the provisioning done in a much more secure manner.
Now, when we talk about infrastructure as code,
it really comes down to three key areas.
Part of this is going to be those scripts I just talked about.
Part of it is going to be security templates,
and part of it is going to be policies.
And by applying these three against your infrastructure
using this approach,
you're going to have much more secure infrastructure.
Now, when we talk about this,
we are going to have to think about our orchestration.
And if you have robust orchestration
where you've tested it and you know it works well,
then you can lower your overall IT costs,
speed up your deployments, and you can increase security.
So, this is really a win-win-win.
It's all goodness here.
Now, one of the things you have to be careful of, though,
when you're doing this infrastructure as code,
because we're using templates
and standardization for everything,
is people who want to have their special snowflakes.
Now, when I talk about special snowflakes,
you have people who think they just have the best idea
and therefore, they have to be able to go
and create their own infrastructure
the way they want to do it.
And they don't care about your standardization
and your scripting and all the efficiencies you've gained.
And so, they create something that is a one-off system.
Now, when you're a big advocate for using orchestration
and using scripts and using standardization,
sometimes, you're going to face some friction at work
because somebody thinks they have a better idea
and they have this special snowflake system
that they just have to have,
and they can't use your standard templates.
Now, when that happens,
you end up with a special snowflake system
and these snowflake systems are any system
that is different from the configuration
that's compared to the standard template
within the infrastructure as code architecture.
Now, the problem with this is it adds to security problems.
It adds to configuration problems
and supportability problems.
This lack of consistency is going to lead
to a lot of issues for you,
especially in terms of security
and inefficiencies in supporting it.
This is because once you have a one-off system,
it's unique and it doesn't apply to everything else.
Think about it if you're in a large environment
that's operating in the cloud
and you have thousands of virtual machines.
And out of those thousands of virtual machines,
one is different.
When somebody calls up and says something isn't working,
you have to figure out is it that one exception
or is it the thousands of others that are all working?
And that becomes more of a support issue for you
and it leads to a lot of security headaches.
Now, the last thing we need to talk about
in terms of infrastructure as code is idempotence.
Now, this is a property of infrastructure as code
that an automation or orchestration action
is always going to produce the same result
regardless of the component's previous state.
Essentially, every time you give this input,
you should expect this output.
Anytime you call up this script,
it should be doing these functions
and it should do it every single time.
That's why we want to eliminate those special snowflakes,
because we want everything to be consistent.
Now, by doing this and using carefully-developed
and tested scripts,
we can end up doing orchestration really consistently.
We create these runbooks
that are going to do all the steps for us.
That's what we call a script inside of orchestration.
And it's going to generate these very consistent builds
that have a good security posture,
and they're within compliance for us.
So, really, what I'm trying to say here is
eliminate the special snowflakes.
Don't allow them to happen.
If somebody wants to have a special snowflake system,
there should be a really, really good reason for it.
And it should go really high up
in your organization for approval.
The default answer should be no special snowflakes.
We're all going to use the same templates,
the same security, and the same orchestration,
because we know it works and it's easier for us to support
and it gives us much better security.