In this lesson,
we're going to talk about infrastructure
as code, which is used for automation and orchestration.
So let's talk about this IaC, or Infrastructure as Code.
Essentially, Infrastructure as Code is the ability to manage
and provision infrastructure through code instead
of through manual processes.
The term infrastructure here is also rather generic.
It can refer to virtual machines that contain servers
or clients, or virtual devices like switches, routers,
firewalls, and other security appliances.
To use Infrastructure as Code effectively, we need
to also use scripted automation and orchestration.
Now, scripted automation
and orchestration are used
in cloud computing all over the time.
This allows our development, security, and operations teams,
or the DevSecOps team
to rapidly deploy things like a new router switch
or even an entire network complete with servers
and security devices.
The best part of all this is that it is less error prone,
and it's a lot faster than having our network technicians
or system administrators building out these things manually.
The great thing here is that if we use scripted automation,
we're relying on a computer script to do most
of the hard work, and once you have a well-written script,
it can be reused over and over again
and it will never make a mistake.
So this allows us to get a lot
of our deployments done faster
and in a much more secure way.
Now, when we're talking about Infrastructure as Code
or IaC, it really comes down
to three key areas when you're doing your implementation.
This is scripting security templates and policies.
Now, scripting will let you perform a series
of actions in a particular order or sequence,
and it can even include some basic logic
to ensure the right things are being deployed
based on the current conditions.
Security templates and policies are then going to be deployed,
and these contain a series of configuration files
that are applied to the different devices being
deployed in your environment.
These might include network settings, access control lists,
group policies, or permissions.
Now, automation is great,
but where Infrastructure as Code really excels
is through the use of orchestration.
Orchestration is the process of arranging
or coordinating the installation
and configuration of multiple systems.
In most implementations, it really comes down
to running the same task on a bunch of different servers
or devices all at the same time,
but not always on every single server or device.
This is where machine learning
and logic are going to come into play.
If you're using some robust orchestration
that's been properly configured
and tested, you can lower your overall IT costs,
speed up your deployments and increase your security.
So it really becomes a win-win win for our organizations.
Now, as an aspiring network technician, you might be worried
that infrastructure as a code might put you at a job
someday, but really it's just being used
to automate the most boring
and tedious portions of your job.
It is designed to ease your burden
and allow you to focus on more higher level tasks instead
of just installing a hundred more virtual switches
or routers using some boring checklist.
So don't worry, have no fear.
There is nothing but goodness here when it comes
to Infrastructure as Code.
Also, Infrastructure as Code is the basis
of everything we do in horizontal scaling
or scaling out within our cloud environments
when we need to use elasticity.
So it is really important to embrace it.
Now, one of the things you have to be careful
of though is that when you're using Infrastructure as Code,
people in your organization
who believe they might have some kind of a special project,
I like to call these the special snowflakes.
Remember, with Infrastructure as Code, we are trying
to embrace standardization templates and scripts.
So when you have people
who think they have a special snowflake,
this can lead to trouble.
After all, if they have a special snowflake project,
they believe they have to be able to go
and create their own infrastructure
to support their project
instead of relying on the standard infrastructure
that you provide to everyone else through IaC.
These people don't really care about your standardization
and all of your scripting and all the efficiencies
that you've already gained by embracing infrastructure
as code, using orchestration.
Instead, they want to create something as a one-off system,
and when that happens, you end up
with this special snowflake.
And these special snowflake systems are any system
that is different from the standard configuration template
that's used within your organization's infrastructure
as code architecture.
Now, the problem with this is that it adds risk
to your overall security posture,
and it also adds a lot of configuration problems
and long-term supportability problems for you
because it's a one-off system, the lack of consistency
that you're going to find in a special snowflake system
is going to lead to a lot of issues for you down the road,
especially in terms of security
and your ability to support it
after it's moved into production.
This is because you have a one-off system
and it is by definition unique and it doesn't look
or act like every other system that you support.
Think about it this way.
Pretend you're in a large
environment that's operating in the cloud
and you have thousands upon thousands of virtual machines.
Now, out of all those virtual machines,
we have just one that's different.
When somebody calls up and says something
isn't working properly,
now you have to figure out is it something with
that special machine that's causing the problem,
or is this a bigger problem across your entire cloud?
This is now a really big support issue for you
and your team, and it can lead to a lot
of security headaches in the long run.
For this reason, I always want to eliminate these special
snowflakes because we want everything to be consistent.
By keeping things consistent and using carefully developed
and tested scripts, we can end up using orchestration
extremely efficiently
and securely, which maintains a good solid baseline
for our networks.