1

00:00:00,469  -->  00:00:09,300
welcome back to back space Academy so
what is AWS opsworks it's a

2

00:00:09,300  -->  00:00:14,009
configuration management platform so
what that means is that we have assets

3

00:00:14,009  -->  00:00:20,100
that we want to deploy our application
on and they will consist of instances

4

00:00:20,100  -->  00:00:25,350
maybe ec2 instances they could consist
of elastic load balancers a number of

5

00:00:25,350  -->  00:00:31,160
things and the way that those assets or
those resources and instances are

6

00:00:31,160  -->  00:00:38,460
configured we need to define and that is
done with op works in code so this

7

00:00:38,460  -->  00:00:42,030
provides us much more control over
infrastructure design and management

8

00:00:42,030  -->  00:00:49,010
that we would get with elastic beanstalk
and we use chef we use chef recipes and

9

00:00:49,010  -->  00:00:53,820
they enable us to have that
infrastructure designed as code and

10

00:00:53,820  -->  00:01:00,359
gives us very fine-grained control over
our infrastructure now opt works it

11

00:01:00,359  -->  00:01:05,339
consists as a configuration management
model and it's based upon stacks layers

12

00:01:05,339  -->  00:01:12,540
and recipes which we'll go through right
now so a stack that is the top level op

13

00:01:12,540  -->  00:01:17,820
works entity and it represents a set of
instances and applications that you want

14

00:01:17,820  -->  00:01:22,950
to manage collectively so that could be
a web server it could be an enterprise

15

00:01:22,950  -->  00:01:29,130
resource planning application so it's a
set of instances and applications for

16

00:01:29,130  -->  00:01:34,490
that that are managed collectively so
for example if we had a web server stack

17

00:01:34,490  -->  00:01:44,210
that may contain a load balancer server
instances and a database so within a

18

00:01:44,210  -->  00:01:50,930
stack we have layers and those layers
define how to set up and configure

19

00:01:50,930  -->  00:01:57,360
instances and resources and you can mix
and match these layers so a layer can be

20

00:01:57,360  -->  00:02:03,240
used in multiple stacks ok and a stack
can be made up of one layer or can be

21

00:02:03,240  -->  00:02:09,170
made up of multiple layers but a stack
must contain at least one layer and

22

00:02:09,170  -->  00:02:13,349
layers they must contain at least one
instance

23

00:02:13,349  -->  00:02:18,450
now these instances can also be a member
of multiple layers so you can reuse

24

00:02:18,450  -->  00:02:25,349
instances you can better utilize them
across multiple layers and the

25

00:02:25,349  -->  00:02:29,819
applications will there the code that
will run on your server so if it's a

26

00:02:29,819  -->  00:02:34,200
node.js server that will be your node.js
application code and that will run on

27

00:02:34,200  -->  00:02:42,780
your no junior server if that is what
you are setting up with ODS works so

28

00:02:42,780  -->  00:02:47,400
scaling so we have three different types
of scaling that we can use lies with

29

00:02:47,400  -->  00:02:55,469
opsworks so you can have 24/7 instances
and they can be added to a layer and you

30

00:02:55,469  -->  00:03:00,150
can mentally start or stop or reboot
those corresponding ec2 instances that

31

00:03:00,150  -->  00:03:05,129
have been defined and we also have
automatic scaling so that can be on a

32

00:03:05,129  -->  00:03:10,680
time-based or low base so it would be
time-based if it's based upon a schedule

33

00:03:10,680  -->  00:03:16,379
so between 7:00 and 8:00 o'clock at
night we're going to have X capacity we

34

00:03:16,379  -->  00:03:20,549
could be load based so that would be
based upon a load metrics a network

35

00:03:20,549  -->  00:03:26,549
traffic or CPU utilization so when
demand is high that would scale up so an

36

00:03:26,549  -->  00:03:30,659
effective strategy would be to use all
three different types of scaling so you

37

00:03:30,659  -->  00:03:37,139
would have for your baseline capacity
you would have a 24-7 instance and then

38

00:03:37,139  -->  00:03:41,489
for automatic scaling for your peak
periods you could have a time-based

39

00:03:41,489  -->  00:03:48,120
instance based upon a schedule and you
could also have a load based instances

40

00:03:48,120  -->  00:03:55,849
that would react to network traffic or
CPU utilization to take advantage that

41

00:03:55,849  -->  00:04:05,579
that you didn't expect and you need
excess capacity that you didn't have so

42

00:04:05,579  -->  00:04:09,560
then once we've got those layers we've
got our stack we can then look at

43

00:04:09,560  -->  00:04:15,719
deployment and customizations so our app
and its associated infrastructure that

44

00:04:15,719  -->  00:04:20,280
is needed for that app to run will be
deployed automatically through opsworks

45

00:04:20,280  -->  00:04:26,770
and our chef recipes they define our
infrastructure as

46

00:04:26,770  -->  00:04:32,379
so we can use a chef recipes to further
customize we can use those chef recipes

47

00:04:32,379  -->  00:04:39,039
to redeploy our environment again we can
also use those chef recipes under

48

00:04:39,039  -->  00:04:43,960
version control so we can not only have
our our infrastructure as code we can

49

00:04:43,960  -->  00:04:49,389
have it manage our infrastructure
managed under version control and we can

50

00:04:49,389  -->  00:04:55,780
also reuse a reuse our code so that's a
very big difference between what you

51

00:04:55,780  -->  00:05:00,550
would have with elastic Beanstalk okay
so less expense talk just looks after

52

00:05:00,550  -->  00:05:06,039
deploying your application to resources
so this looks but a lot more it's a lot

53

00:05:06,039  -->  00:05:12,039
more advanced and a lot more
fine-grained and far more integrated

54

00:05:12,039  -->  00:05:15,690
with with the infrastructure