1
00:00:06,875 --> 00:00:10,717
- Now let's review some
application management services.

2
00:00:10,717 --> 00:00:13,525
The first service here
that we wanna talk about

3
00:00:13,525 --> 00:00:16,194
is AWS Elastic Beanstalk.

4
00:00:16,194 --> 00:00:20,011
Now, we talked about
earlier CloudFormation.

5
00:00:20,011 --> 00:00:22,507
If you think of these services

6
00:00:22,507 --> 00:00:26,174
on a scale of absolute
control, on one hand,

7
00:00:28,752 --> 00:00:32,379
and absolute convenience on another,

8
00:00:32,379 --> 00:00:37,333
CloudFormation would be
near the far end of control

9
00:00:37,333 --> 00:00:39,700
and Elastic Beanstalk would be

10
00:00:39,700 --> 00:00:43,167
on the very far end of convenience.

11
00:00:43,167 --> 00:00:47,479
So, we get a lot of convenience
with Elastic Beanstalk,

12
00:00:47,479 --> 00:00:50,363
but certainly nowhere
near the amount of control

13
00:00:50,363 --> 00:00:53,438
that we get with AWS CloudFormation.

14
00:00:53,438 --> 00:00:57,394
So Elastic Beanstalk is
what we would consider

15
00:00:57,394 --> 00:00:59,741
an application management platform,

16
00:00:59,741 --> 00:01:04,367
it provides very easy entry
into Amazon Web Services.

17
00:01:04,367 --> 00:01:05,312
There's a couple of ways

18
00:01:05,312 --> 00:01:08,367
that we could think
about Elastic Beanstalk.

19
00:01:08,367 --> 00:01:11,953
One way is that, you know,
it's ideal for developers,

20
00:01:11,953 --> 00:01:13,415
there are plenty of folks out there

21
00:01:13,415 --> 00:01:17,473
that all they wanna do is
write their application

22
00:01:17,473 --> 00:01:20,847
and see it run, they don't want to bother

23
00:01:20,847 --> 00:01:23,932
with managing servers or resources,

24
00:01:23,932 --> 00:01:26,524
they don't want to install Engine ACS

25
00:01:26,524 --> 00:01:30,659
or Apache or PHP, they just
want to write their application

26
00:01:30,659 --> 00:01:33,653
and hand it off and
allow some other service

27
00:01:33,653 --> 00:01:36,937
to manage the underlying
infrastructure for them.

28
00:01:36,937 --> 00:01:41,104
So in that case developers
simply upload their application,

29
00:01:45,154 --> 00:01:48,136
they can choose from a number
of different platforms,

30
00:01:48,136 --> 00:01:51,969
like Java, .NET, Node.js,
Docker among others,

31
00:01:53,219 --> 00:01:55,342
and by uploading their application

32
00:01:55,342 --> 00:01:58,238
to the Elastic Beanstalk service,

33
00:01:58,238 --> 00:02:02,807
the Beanstalk service
will handle the creation

34
00:02:02,807 --> 00:02:05,254
of resources and the ongoing management

35
00:02:05,254 --> 00:02:07,701
of those resources automatically.

36
00:02:07,701 --> 00:02:10,639
So, when we upload our application

37
00:02:10,639 --> 00:02:13,637
we can choose to have it load balanced,

38
00:02:13,637 --> 00:02:15,482
in which case Elastic Beanstalk

39
00:02:15,482 --> 00:02:19,065
will create the ELB
and manage that for us.

40
00:02:19,974 --> 00:02:23,282
If we want our application
to be auto scaled,

41
00:02:23,282 --> 00:02:24,942
which we'll talk more about later,

42
00:02:24,942 --> 00:02:26,800
we can choose that as well.

43
00:02:26,800 --> 00:02:30,821
Elastic Beanstalk handles
capacity provisioning

44
00:02:30,821 --> 00:02:34,568
and monitoring, all automatically
in the background for us,

45
00:02:34,568 --> 00:02:38,622
there is really no degree
of infrastructure management

46
00:02:38,622 --> 00:02:40,432
that we have to worry about.

47
00:02:40,432 --> 00:02:44,454
So, another way to think
about AWS Elastic Beanstalk

48
00:02:44,454 --> 00:02:48,479
is for IT teams that just have a lot to do

49
00:02:48,479 --> 00:02:50,682
and we don't necessarily have time

50
00:02:50,682 --> 00:02:54,849
to design, deploy and manage
these resources independently.

51
00:02:56,726 --> 00:02:59,520
Perhaps we have more
important things to do

52
00:02:59,520 --> 00:03:03,142
with other systems and
we just want to take

53
00:03:03,142 --> 00:03:06,114
a particular application
that was handed to us

54
00:03:06,114 --> 00:03:09,175
and use Elastic Beanstalk
as a way to save time,

55
00:03:09,175 --> 00:03:11,735
just get it into Amazon and trust

56
00:03:11,735 --> 00:03:13,958
that the Elastic Beanstalk service

57
00:03:13,958 --> 00:03:16,988
will keep that application
highly available

58
00:03:16,988 --> 00:03:18,941
and fault-tolerant.

59
00:03:18,941 --> 00:03:23,280
The next service that I wanna
talk about is AWS OpsWorks.

60
00:03:23,280 --> 00:03:26,163
So again, if we go back to that scale

61
00:03:26,163 --> 00:03:28,890
of convenience versus control

62
00:03:28,890 --> 00:03:32,563
where on the very far side of convenience

63
00:03:32,563 --> 00:03:35,014
we have Elastic Beanstalk

64
00:03:35,014 --> 00:03:38,622
and on the very far side of
control we have custom scripts

65
00:03:38,622 --> 00:03:41,817
that we write, somewhere in the middle,

66
00:03:41,817 --> 00:03:43,998
you know, giving us a
little more convenience,

67
00:03:43,998 --> 00:03:47,584
but still absolute
control is CloudFormation

68
00:03:47,584 --> 00:03:50,355
and then giving us more convenience

69
00:03:50,355 --> 00:03:54,521
but slightly less control is AWS OpsWorks.

70
00:03:54,521 --> 00:03:58,271
Now OpsWorks is somewhat
similar to Beanstalk

71
00:03:59,484 --> 00:04:01,319
in that it is an application

72
00:04:01,319 --> 00:04:05,741
or what we might call a
configuration management platform,

73
00:04:05,741 --> 00:04:08,783
it's still going to give us
a high degree of convenience,

74
00:04:08,783 --> 00:04:10,067
but a whole lot more control

75
00:04:10,067 --> 00:04:12,780
than we get with Elastic Beanstalk.

76
00:04:12,780 --> 00:04:16,570
Now, when we talked
about AWS CloudFormation

77
00:04:16,570 --> 00:04:19,942
one point that I made there
was that CloudFormation

78
00:04:19,942 --> 00:04:23,942
does not impose any
specific model of deployment

79
00:04:25,172 --> 00:04:27,140
or operations, it's wide open,

80
00:04:27,140 --> 00:04:28,740
we can do what we want.

81
00:04:28,740 --> 00:04:31,323
But OpsWorks does have a model,

82
00:04:32,225 --> 00:04:34,819
it's based on these ideas

83
00:04:34,819 --> 00:04:37,736
of stacks, layers and applications.

84
00:04:40,168 --> 00:04:43,177
These are based on Chef recipes,

85
00:04:43,177 --> 00:04:46,896
so for those of us that
might be familiar with Chef,

86
00:04:46,896 --> 00:04:49,655
we have access to running Chef recipes,

87
00:04:49,655 --> 00:04:52,662
which we might call configuration as code.

88
00:04:52,662 --> 00:04:55,705
We're gonna get more control
than Elastic Beanstalk,

89
00:04:55,705 --> 00:04:58,487
but we're going to get a
narrower range of resources

90
00:04:58,487 --> 00:05:03,120
than we would have access
to with AWS CloudFormation.

91
00:05:03,120 --> 00:05:06,863
But we still get to say
that, within our stacks,

92
00:05:06,863 --> 00:05:11,513
we're going to have control
over all of the infrastructure

93
00:05:11,513 --> 00:05:13,490
that is being managed, the infrastructure

94
00:05:13,490 --> 00:05:16,194
and the applications
that are being managed.

95
00:05:16,194 --> 00:05:18,754
Within a stack we have layers,

96
00:05:18,754 --> 00:05:23,001
so each layer represents the
particular types of instances

97
00:05:23,001 --> 00:05:24,744
and related resources.

98
00:05:24,744 --> 00:05:29,616
So one architecture might be
classic three tier architecture

99
00:05:29,616 --> 00:05:32,790
where you have load balancers out front,

100
00:05:32,790 --> 00:05:34,912
you have application servers,

101
00:05:34,912 --> 00:05:37,535
and then in the back you
have database servers,

102
00:05:37,535 --> 00:05:40,607
so perhaps each one of
those is its own layer,

103
00:05:40,607 --> 00:05:44,142
where one layer describes
your load balancer,

104
00:05:44,142 --> 00:05:48,197
another layer describes the
particular types of instances

105
00:05:48,197 --> 00:05:50,979
you want being used for your application

106
00:05:50,979 --> 00:05:53,885
and then yet a third layer
is describing the types

107
00:05:53,885 --> 00:05:56,522
of database resources that you want.

108
00:05:56,522 --> 00:05:59,651
And again, the all of
those layers together

109
00:05:59,651 --> 00:06:03,296
would be represented by one stack.

110
00:06:03,296 --> 00:06:06,000
And then of course we
have our applications.

111
00:06:06,000 --> 00:06:09,167
So in that example, that second layer,

112
00:06:10,300 --> 00:06:13,944
we would deploy an
application to that layer

113
00:06:13,944 --> 00:06:16,626
or to the instances in that layer

114
00:06:16,626 --> 00:06:20,793
by leveraging Chef recipes
that can control exactly how

115
00:06:21,856 --> 00:06:25,106
and when our application gets deployed.

116
00:06:26,057 --> 00:06:28,841
And then of course once
we deploy our applications

117
00:06:28,841 --> 00:06:31,387
into these layers and into these stacks

118
00:06:31,387 --> 00:06:35,224
the OpsWorks service
will continue to maintain

119
00:06:35,224 --> 00:06:39,724
our application health by
replacing instances that fail.

120
00:06:39,724 --> 00:06:43,053
It can also help us to
automate the management

121
00:06:43,053 --> 00:06:46,070
around scaling and capacity
provisioning as well.

122
00:06:46,070 --> 00:06:49,310
So, OpsWorks is ideal for, you know,

123
00:06:49,310 --> 00:06:52,395
IT admins, DevOps engineers,

124
00:06:52,395 --> 00:06:56,360
those who want convenience
in their infrastructures,

125
00:06:56,360 --> 00:06:59,131
but want more control than what we get

126
00:06:59,131 --> 00:07:01,944
with AWS Elastic Beanstalk.

127
00:07:01,944 --> 00:07:06,027
So those are our application
management services.