- [Alana] Hey everyone, and welcome to the second
and final week of the course.
I know it's been a while, but I want you to think back
to the beginning of this course,
where we started out talking about a scenario
of a team of engineers.
The team wanted to use continuous delivery
and automate the creation of their deployments.
We also talked about why automation was a good practice
in general, as it removes human error
and increases speed and productivity.
In the exercises you completed in Week 1,
you manually created a test environment,
in this case an EC2 instance, to deploy your application to.
In this week, we get to take automation a step further,
and consider how to automate the creation
of those test environments, like our EC2 instance,
and any infrastructure that supports that,
such as IAM roles and a network.
In a real production system, we might also have other
environments we want to automate the creation of, as well.
Let's take the same scenario of a team of engineers
that are working on their pipeline and releasing code,
and they want to automate everything as much as possible.
Let's say that team hired a bunch of new developers
to work on their application, and now those developers
need development environments.
How do we get each new hire a development environment?
Do we: A. Hand the developer a document with requirements
and let the developers create it themselves?
Or B. Hand them a template of code to create
the environments with all configurations already set?
Well, the problem with answer A is that it's
a very manual process and we really need all development
environments to look the same.
It's possible, with human error,
the developer might misconfigure something,
which might lead to their environment being out of sync,
or even if they were to do everything
the document says correctly, it's possible that the document
itself is out of date or wrong.
There's too many issues with this option,
so let's talk about option B.
Handing over a template of code to build
the dev environments enables the team
to treat this environment like code,
meaning you can store it in version control.
You can do code reviews, and even ship
it through a pipeline, and that same template,
with some changes, can be used to create
your test environments and prod environments
so that every environment looks as similar as possible.
This idea of treating our infrastructure as code
is a fundamental principle of DevOps.
It enables your team to apply the same rigor
of application development to provisioning infrastructure.
During this week, we'll talk about some
of the key services AWS offers that enable you
to properly use infrastructure as code,
which is also known as IaC.
These services will not only help your team provision
dev test and prod environments, but they can also enable you
to provision the entire pipeline itself,
and even think about your pipeline as code.
I know that's a little meta, but pretty soon,
every time you look at a piece of infrastructure
in the AWS Management Console, you'll think this can just be
a piece of code in a template, and thinking like that
will help you build your DevOps culture.
Get ready for Week 2, where we talk
infrastructure as code.