1

00:00:09,000  -->  00:00:13,930
Welcome back to BackSpace Academy.
Elastic Beanstalk it's one of AWS

2

00:00:13,930  -->  00:00:19,720
deployment services and it allows you to
deploy your applications to complex

3

00:00:19,720  -->  00:00:24,849
architectures on AWS and it does this
without you having to worry about the

4

00:00:24,849  -->  00:00:29,380
underlying architecture that is behind
that. Elastic Beanstalk it looks after

5

00:00:29,380  -->  00:00:34,239
everything for you and you just need to
worry about writing your code. We'll also

6

00:00:34,239  -->  00:00:38,710
talk about how Elastic Beanstalk can
create highly available and fault

7

00:00:38,710  -->  00:00:42,969
tolerant architectures and what that
actually means, and then finally we'll

8

00:00:42,969  -->  00:00:48,719
look at the different deployment options
that are available on Elastic Beanstalk.

9

00:00:48,719  -->  00:00:53,050
Elastic Beanstalk it's been around for
quite some time. It was first launched in 2011

10

00:00:53,050  -->  00:00:59,350
it allows you to quickly deploy and
manage applications on environments and

11

00:00:59,350  -->  00:01:03,999
those environments are launched for you
without you having to worry about how it

12

00:01:03,999  -->  00:01:09,010
all works, it'll automatically handle
capacity provisioning, it'll launch a

13

00:01:09,010  -->  00:01:13,840
load balancer for you if you need that,
it'll Auto scale for you and it can also

14

00:01:13,840  -->  00:01:18,700
implement health monitoring so that if
one of these instances that are launched

15

00:01:18,700  -->  00:01:23,860
becomes unhealthy it can replace those
automatically for you. If you need to change

16

00:01:23,860  -->  00:01:28,299
your code after you have deployed
it it's quite easy to upload new versions

17

00:01:28,299  -->  00:01:31,990
of that code and that can be
done through the console or the

18

00:01:31,990  -->  00:01:36,670
command-line interface and also
complete environments can also be

19

00:01:36,670  -->  00:01:41,829
redeployed if need be. Your application
that you're deploying could be a Docker

20

00:01:41,829  -->  00:01:45,450
container
it could be raw code it could be nodejs

21

00:01:45,450  -->  00:01:52,960
java, .net. PHP, Ruby, Python, or GO you just
supply your code and Elastic Beanstalk

22

00:01:52,960  -->  00:01:56,409
will deploy that for you and it will
provision that nodejs or whatever

23

00:01:56,409  -->  00:02:01,119
environment for you automatically or it
could be a service such as apache, nginx

24

00:02:01,119  -->  00:02:08,080
passenger or IIS the elastic Beanstalk
process it starts with us going through

25

00:02:08,080  -->  00:02:13,990
an application creation process where
we will first off upload a version of

26

00:02:13,990  -->  00:02:19,330
our software or our code or whatever it
is and then elastic Beanstalk will

27

00:02:19,330  -->  00:02:22,540
launch an environment and that will
consist of a EC2 instances

28

00:02:22,540  -->  00:02:28,060
or it could be a single
EC2 instance it could be a multi AZ

29

00:02:28,060  -->  00:02:31,930
environment but we define that for
Elastic Beanstalk and it will do that

30

00:02:31,930  -->  00:02:37,480
automatically for us, from there we will
have our environment launched and our

31

00:02:37,480  -->  00:02:42,370
code will be running on that environment,
now if we find that we need to deploy a

32

00:02:42,370  -->  00:02:46,659
new version of that code we can deploy
that to that existing environment or we

33

00:02:46,659  -->  00:02:50,470
can create a whole new environment it
doesn't really matter, so if we deployed

34

00:02:50,470  -->  00:02:55,989
it to our existing environment then when
that environment has gone through that

35

00:02:55,989  -->  00:03:00,609
update process and the new version is
deployed and running then the

36

00:03:00,609  -->  00:03:04,750
environment will feed back to the
application to notify that that new

37

00:03:04,750  -->  00:03:09,930
version of your application is actually
running

38

00:03:10,360  -->  00:03:14,680
one of the big advantages of elastic
beanstalk is it can create a highly

39

00:03:14,680  -->  00:03:18,520
available and fault tolerant
architecture without us having to worry

40

00:03:18,520  -->  00:03:25,150
about how to actually do that, so what is
a highly available and fault tolerant

41

00:03:25,150  -->  00:03:30,400
architecture so here we've got the AWS
cloud and as we know it's divided up

42

00:03:30,400  -->  00:03:35,770
into regions and those regions are
divided up into availability zones so

43

00:03:35,770  -->  00:03:40,660
we've if we have our architecture
distributed across multiple availability

44

00:03:40,660  -->  00:03:46,120
zones if one of those availability zones
goes down our infrastructure will still

45

00:03:46,120  -->  00:03:52,090
continue to operate and serve requests
now our virtual private cloud that will

46

00:03:52,090  -->  00:03:58,720
span the entire region so it will span
multiple availability zones and so what

47

00:03:58,720  -->  00:04:02,770
we can do is that we can launch
instances into both of those

48

00:04:02,770  -->  00:04:06,580
availability zones and that's going to
give us high availability if one of

49

00:04:06,580  -->  00:04:13,120
those availability zones goes down, now
in order for our architecture to respond

50

00:04:13,120  -->  00:04:17,830
to spikes in demand or increases in
demand because an availability zone goes

51

00:04:17,830  -->  00:04:23,680
down what we can do is we can launch our
instances using an auto scaling group

52

00:04:23,680  -->  00:04:28,990
so if demand on one of those or a group of
instances increases the auto scaling

53

00:04:28,990  -->  00:04:32,800
group will add instances to accommodate
that and vice versa

54

00:04:32,800  -->  00:04:37,570
if the demand goes down we will reduce
our number of ec2 instances and that

55

00:04:37,570  -->  00:04:44,530
allows for elasticity in our design and
finally to receive requests from the

56

00:04:44,530  -->  00:04:49,390
outside world and to distribute those
requests to those multiple instances

57

00:04:49,390  -->  00:04:54,100
we're going to need an elastic load
balancer to do that and that will also

58

00:04:54,100  -->  00:04:58,690
have the advantage of conducting health
checks on our instances so that if

59

00:04:58,690  -->  00:05:03,160
communication breaks down between the
elastic load balancer and our ec2

60

00:05:03,160  -->  00:05:08,229
instance then our auto scaling group
will automatically add additional

61

00:05:08,229  -->  00:05:15,040
instances and that creates fault
tolerance in our architecture

62

00:05:15,040  -->  00:05:19,000
just the same as you've got a number of options
available for architecture that you're

63

00:05:19,000  -->  00:05:23,689
deploying to such as a single ec2
instance or a highly

64

00:05:23,689  -->  00:05:26,869
available and fault-tolerant
architecture across multiple

65

00:05:26,869  -->  00:05:31,429
availability zones you've also got a
number of different deployment options

66

00:05:31,429  -->  00:05:37,159
that you can use so for example if
you've got 20 ec2 instances and all at

67

00:05:37,159  -->  00:05:42,889
once deployment will deploy that across
all of those 20 ec2 instances all at

68

00:05:42,889  -->  00:05:47,599
once the downside of that is going to be
that while that is occurring your

69

00:05:47,599  -->  00:05:52,129
architecture won't be able to respond to
requests so that's obviously not a good thing

70

00:05:52,129  -->  00:05:58,309
so another option there is to do a
rolling deployment and that will deploy

71

00:05:58,309  -->  00:06:03,139
your application to a single batch at a
time, so what that means is if you've got

72

00:06:03,139  -->  00:06:09,919
20 ec2 instances it can deploy that to
say two at a time so you're not going to

73

00:06:09,919  -->  00:06:15,019
be down by much you're just going to be
down from 20 instances down to 18

74

00:06:15,019  -->  00:06:20,360
instances but your architecture will
still be responding to requests

75

00:06:20,360  -->  00:06:24,259
you can also do a rolling with an additional
batch so what that will do is if you've

76

00:06:24,259  -->  00:06:30,979
got again 20 ez 2 instances it will
temporarily increase to 22 while you're

77

00:06:30,979  -->  00:06:36,289
doing those two deployments across those
two ec2 instances and that way you're

78

00:06:36,289  -->  00:06:41,409
still going to have your capacity at 20
is which is what you have designed for

79

00:06:41,409  -->  00:06:46,969
the other option there is an immutable
deployment and that is a bit of a

80

00:06:46,969  -->  00:06:50,719
variation of the all at once so it's
still doing an all at once deployment

81

00:06:50,719  -->  00:06:55,849
across your 20 ec2 instances but while
that's going on it's going to deploy

82

00:06:55,849  -->  00:07:04,189
another 20 ec2 instances so temporarily
you're going to have 40 ec2 instances so

83

00:07:04,189  -->  00:07:09,829
it's going to double up a lot on your
capacity but through that period where

84

00:07:09,829  -->  00:07:14,209
your environment is being deployed or
your new version or whatever has being

85

00:07:14,209  -->  00:07:19,029
deployed to that environment you're not
going to be suffering any downtime and

86

00:07:19,029  -->  00:07:24,559
finally we've got blue green deployments
and they will have two environments a

87

00:07:24,559  -->  00:07:30,529
tree running your application under the
one elastic Beanstalk application and so

88

00:07:30,529  -->  00:07:33,589
what that is is you will have a blue
environment and in green environment one

89

00:07:33,589  -->  00:07:36,500
of those could be a development
environment and the other one

90

00:07:36,500  -->  00:07:40,820
your production environment so when you
get to the stage where your development

91

00:07:40,820  -->  00:07:45,200
environment is ready to go to be
deployed to deploy that all you simply

92

00:07:45,200  -->  00:07:49,730
need to do is to switch over from one
environment to the other environment and

93

00:07:49,730  -->  00:07:54,140
then your old environment will then
become your new development environment

94

00:07:54,140  -->  00:07:58,280
and so that is very straightforward with
elastic Beanstalk because what it does

95

00:07:58,280  -->  00:08:04,190
it will simply allow you to switch the
domain names for those two environments

96

00:08:04,190  -->  00:08:09,680
automatically for you and so that makes
sure that your changeover doesn't read

97

00:08:09,680  -->  00:08:15,650
or doesn't involve any downtime for
returning of requests later on in the

98

00:08:15,650  -->  00:08:19,640
course we're going to learn a lot more
about Bluegreen deployments and how to

99

00:08:19,640  -->  00:08:25,669
deploy those across elastic Beanstalk so
but coming up next we're going to use

100

00:08:25,669  -->  00:08:30,110
elastic Beanstalk to deploy a highly
available and fault tolerant

101

00:08:30,110  -->  00:08:33,919
architecture so make sure that you
download the lab notes for this one and

102

00:08:33,919  -->  00:08:37,479
I'll see you in the lab