1
00:00:01,140 --> 00:00:03,000
- [Alana] Hey everyone,
and welcome to the second

2
00:00:03,000 --> 00:00:04,960
and final week of the course.

3
00:00:04,960 --> 00:00:07,580
I know it's been a while,
but I want you to think back

4
00:00:07,580 --> 00:00:09,480
to the beginning of this course,

5
00:00:09,480 --> 00:00:11,730
where we started out
talking about a scenario

6
00:00:11,730 --> 00:00:13,860
of a team of engineers.

7
00:00:13,860 --> 00:00:15,750
The team wanted to use continuous delivery

8
00:00:15,750 --> 00:00:19,060
and automate the creation
of their deployments.

9
00:00:19,060 --> 00:00:21,490
We also talked about why
automation was a good practice

10
00:00:21,490 --> 00:00:24,030
in general, as it removes human error

11
00:00:24,030 --> 00:00:27,300
and increases speed and productivity.

12
00:00:27,300 --> 00:00:29,540
In the exercises you completed in Week 1,

13
00:00:29,540 --> 00:00:31,900
you manually created a test environment,

14
00:00:31,900 --> 00:00:36,520
in this case an EC2 instance,
to deploy your application to.

15
00:00:36,520 --> 00:00:39,380
In this week, we get to take
automation a step further,

16
00:00:39,380 --> 00:00:41,260
and consider how to automate the creation

17
00:00:41,260 --> 00:00:44,380
of those test environments,
like our EC2 instance,

18
00:00:44,380 --> 00:00:46,510
and any infrastructure that supports that,

19
00:00:46,510 --> 00:00:49,203
such as IAM roles and a network.

20
00:00:50,090 --> 00:00:52,880
In a real production system,
we might also have other

21
00:00:52,880 --> 00:00:56,250
environments we want to automate
the creation of, as well.

22
00:00:56,250 --> 00:00:58,620
Let's take the same scenario
of a team of engineers

23
00:00:58,620 --> 00:01:01,420
that are working on their
pipeline and releasing code,

24
00:01:01,420 --> 00:01:04,793
and they want to automate
everything as much as possible.

25
00:01:06,550 --> 00:01:09,330
Let's say that team hired
a bunch of new developers

26
00:01:09,330 --> 00:01:12,110
to work on their application,
and now those developers

27
00:01:12,110 --> 00:01:14,570
need development environments.

28
00:01:14,570 --> 00:01:17,740
How do we get each new hire
a development environment?

29
00:01:17,740 --> 00:01:21,630
Do we: A. Hand the developer
a document with requirements

30
00:01:21,630 --> 00:01:24,500
and let the developers
create it themselves?

31
00:01:24,500 --> 00:01:27,990
Or B. Hand them a
template of code to create

32
00:01:27,990 --> 00:01:30,833
the environments with all
configurations already set?

33
00:01:32,576 --> 00:01:35,140
Well, the problem with
answer A is that it's

34
00:01:35,140 --> 00:01:38,980
a very manual process and we
really need all development

35
00:01:38,980 --> 00:01:41,310
environments to look the same.

36
00:01:41,310 --> 00:01:42,830
It's possible, with human error,

37
00:01:42,830 --> 00:01:45,070
the developer might
misconfigure something,

38
00:01:45,070 --> 00:01:48,130
which might lead to their
environment being out of sync,

39
00:01:48,130 --> 00:01:50,480
or even if they were to do everything

40
00:01:50,480 --> 00:01:53,770
the document says correctly,
it's possible that the document

41
00:01:53,770 --> 00:01:56,540
itself is out of date or wrong.

42
00:01:56,540 --> 00:01:58,830
There's too many issues with this option,

43
00:01:58,830 --> 00:02:01,483
so let's talk about option B.

44
00:02:02,850 --> 00:02:05,300
Handing over a template of code to build

45
00:02:05,300 --> 00:02:07,300
the dev environments enables the team

46
00:02:07,300 --> 00:02:09,490
to treat this environment like code,

47
00:02:09,490 --> 00:02:11,840
meaning you can store
it in version control.

48
00:02:11,840 --> 00:02:14,500
You can do code reviews, and even ship

49
00:02:14,500 --> 00:02:17,380
it through a pipeline,
and that same template,

50
00:02:17,380 --> 00:02:19,970
with some changes, can be used to create

51
00:02:19,970 --> 00:02:22,690
your test environments
and prod environments

52
00:02:22,690 --> 00:02:26,023
so that every environment
looks as similar as possible.

53
00:02:26,890 --> 00:02:29,700
This idea of treating our
infrastructure as code

54
00:02:29,700 --> 00:02:33,200
is a fundamental principle of DevOps.

55
00:02:33,200 --> 00:02:35,760
It enables your team
to apply the same rigor

56
00:02:35,760 --> 00:02:38,883
of application development to
provisioning infrastructure.

57
00:02:39,810 --> 00:02:41,210
During this week, we'll talk about some

58
00:02:41,210 --> 00:02:44,350
of the key services AWS
offers that enable you

59
00:02:44,350 --> 00:02:46,660
to properly use infrastructure as code,

60
00:02:46,660 --> 00:02:49,400
which is also known as IaC.

61
00:02:49,400 --> 00:02:52,040
These services will not only
help your team provision

62
00:02:52,040 --> 00:02:55,750
dev test and prod environments,
but they can also enable you

63
00:02:55,750 --> 00:02:58,960
to provision the entire pipeline itself,

64
00:02:58,960 --> 00:03:02,300
and even think about
your pipeline as code.

65
00:03:02,300 --> 00:03:05,810
I know that's a little
meta, but pretty soon,

66
00:03:05,810 --> 00:03:08,110
every time you look at a
piece of infrastructure

67
00:03:08,110 --> 00:03:12,290
in the AWS Management Console,
you'll think this can just be

68
00:03:12,290 --> 00:03:15,530
a piece of code in a template,
and thinking like that

69
00:03:15,530 --> 00:03:17,803
will help you build your DevOps culture.

70
00:03:18,650 --> 00:03:20,460
Get ready for Week 2, where we talk

71
00:03:20,460 --> 00:03:21,743
infrastructure as code.