- [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.