1

00:00:02,899  -->  00:00:08,969
in this lecture on deployment I'm going
to look at the concept of infrastructure

2

00:00:08,969  -->  00:00:15,360
as code, continuous deployment and
continuous application deployment and

3

00:00:15,360  -->  00:00:19,619
application and infrastructure
deployment look at the options available

4

00:00:19,619  -->  00:00:24,270
for updating our applications and our
infrastructure and also look at the

5

00:00:24,270  -->  00:00:28,880
concept of blue/green deployments

6

00:00:29,330  -->  00:00:34,530
infrastructure as code and this is
something that you'll hear a lot in any

7

00:00:34,530  -->  00:00:39,659
conversation around AWS and that allows
our infrastructure to you managed in the

8

00:00:39,659  -->  00:00:45,149
same way as we would software code for
example we might have a cloud formation

9

00:00:45,149  -->  00:00:50,670
template and that is simply a JSON text
file and we can manage that we virtually

10

00:00:50,670  -->  00:00:56,519
try as we would any other code so
example of that of course a cloud

11

00:00:56,519  -->  00:01:00,959
formation template as I've said is a
good example of that but also the cloud

12

00:01:00,959  -->  00:01:05,400
formation designer and that's another
really good tool that not only has cloud

13

00:01:05,400  -->  00:01:11,219
formation templates but also has a
graphical user interface that allows for

14

00:01:11,219  -->  00:01:18,060
drag-and-drop creation of flowcharts
that define our cloud formation template

15

00:01:18,060  -->  00:01:27,869
we can also look at having a version
control around our am is so continuous

16

00:01:27,869  -->  00:01:33,840
deployment of our application now that
is around the automated delivery of

17

00:01:33,840  -->  00:01:39,450
production ready code and it allows
rapid deployment and rollback if

18

00:01:39,450  -->  00:01:44,700
necessary so examples of continuous
deployment include code commit which is

19

00:01:44,700  -->  00:01:51,240
AWS as a git repository or git
repository service we have code pipeline

20

00:01:51,240  -->  00:01:57,960
which is another very very good tool for
developers which allows you to define a

21

00:01:57,960  -->  00:02:05,759
pipeline of stages for releases and what
is required for a release to progress to

22

00:02:05,759  -->  00:02:10,590
the next stage through to a production
release we have elastic Beanstalk which

23

00:02:10,590  -->  00:02:15,569
allows for very rapid deployment of any
updated code

24

00:02:15,569  -->  00:02:20,219
you the infrastructure that is a find on
elastic Beanstalk

25

00:02:20,219  -->  00:02:26,549
we have opsworks which uses chef recipes
to define our application and we also

26

00:02:26,549  -->  00:02:35,189
have elastic container services which
use docker containers we can also have

27

00:02:35,189  -->  00:02:39,540
continuous deployment of both our
application and our infrastructure and

28

00:02:39,540  -->  00:02:44,669
examples of that again our code pipeline
kokum int elastic Beanstalk because we

29

00:02:44,669  -->  00:02:48,450
can actually make changes in elastic
Beanstalk to our infrastructure as well

30

00:02:48,450  -->  00:02:54,750
as changes to our application code and
chef recipes in opsworks can define our

31

00:02:54,750  -->  00:02:58,829
infrastructure as well as our
application and of course containers in

32

00:02:58,829  -->  00:03:04,469
the docker containers in the ECS
service we can also have hybrid

33

00:03:04,469  -->  00:03:08,790
deployments and that is quite
common where we would separate our

34

00:03:08,790  -->  00:03:13,379
database from our application layer or
parts of our application our

35

00:03:13,379  -->  00:03:18,120
infrastructure deployments and that will
create a hybrid deployment and would

36

00:03:18,120  -->  00:03:23,849
really focus on continuous deployment of
those areas that are changing and really

37

00:03:23,849  -->  00:03:27,870
keeping stable our areas that are not
necessarily changing that often such as

38

00:03:27,870  -->  00:03:35,069
our database so the options available
for us for updating our application so

39

00:03:35,069  -->  00:03:40,470
we can look at pre-baking AMIs and
that's that's certainly an option but

40

00:03:40,470  -->  00:03:43,829
not a great option where you would just
keep creating another ami every time

41

00:03:43,829  -->  00:03:49,500
your application code up updates it's a
slow way of doing that and the

42

00:03:49,500  -->  00:03:55,370
expensive way of doing that we can look
at an in-place up upgrades where we use

43

00:03:55,370  -->  00:04:02,250
live ec2 instances and we apply updated
code to those live ec2 instances and we

44

00:04:02,250  -->  00:04:06,540
could also look at disposable upgrades
and they're quite handy because we can

45

00:04:06,540  -->  00:04:12,900
roll out new ec2 instances with our new
code and then when that is up and

46

00:04:12,900  -->  00:04:17,250
running and stable then we can terminate
our older instances and that allows for

47

00:04:17,250  -->  00:04:22,590
a more staged deployment and allows us
to progress slowly across until we've

48

00:04:22,590  -->  00:04:29,400
got all of our ec2 instances upgraded to
our our new code

49

00:04:29,400  -->  00:04:34,660
another concept that we need to be aware
of is Bluegreen deployments and they are

50

00:04:34,660  -->  00:04:41,470
staged rollouts from an existing blue
environment while testing a new green

51

00:04:41,470  -->  00:04:48,880
environment it uses the main name
service it will use route 53 to entry to

52

00:04:48,880  -->  00:04:54,760
increase traffic to a green environment
from a blue environment in a staged

53

00:04:54,760  -->  00:05:01,150
process so what that means is if we look
at the diagram there we can start off

54

00:05:01,150  -->  00:05:06,340
with ninety percent of our traffic going
to the blue existing environment and

55

00:05:06,340  -->  00:05:09,880
then just put ten percent of our traffic
over to the new green environment and

56

00:05:09,880  -->  00:05:14,770
then slowly shift that over from you
know we might make it eighty then 20 and

57

00:05:14,770  -->  00:05:18,220
then seventy years thirty until such a
point that we've got all of our traffic

58

00:05:18,220  -->  00:05:23,470
going over to our green environment and
that is very good from a risk management

59

00:05:23,470  -->  00:05:29,500
perspective because we're not exposing
us 100% at our at our end-users to any

60

00:05:29,500  -->  00:05:35,590
problems but it does require doubling up
on our resources so it is expensive from

61

00:05:35,590  -->  00:05:39,490
expect from the point of that at a
certain point in time or for a certain

62

00:05:39,490  -->  00:05:46,750
period of time we need to have two
environments running at the same time so

63

00:05:46,750  -->  00:05:51,310
that brings us at the end of our lecture
on deployment I'll see you in the next

64

00:05:51,310  -->  00:05:54,000
lectures