1
00:00:00,640 --> 00:00:02,390
- [Alana] Hello, and welcome back.

2
00:00:02,390 --> 00:00:05,580
It's time to talk about
deploying our application.

3
00:00:05,580 --> 00:00:08,340
How often do you think a
deployment should be happening?

4
00:00:08,340 --> 00:00:12,970
Quarterly? Weekly? Daily?
Multiple times a day?

5
00:00:12,970 --> 00:00:16,270
The answer to this is going
to be different for everyone.

6
00:00:16,270 --> 00:00:18,250
One thing I think we can agree on is that

7
00:00:18,250 --> 00:00:21,150
a deployment shouldn't be a scary event.

8
00:00:21,150 --> 00:00:22,720
If we automate our deployments,

9
00:00:22,720 --> 00:00:25,340
and are doing this with
some regular cadence,

10
00:00:25,340 --> 00:00:27,380
deployment becomes an
event that we have more

11
00:00:27,380 --> 00:00:28,793
and more confidence in.

12
00:00:30,070 --> 00:00:32,630
Now, deployment doesn't
just go to production.

13
00:00:32,630 --> 00:00:36,480
We have multiple stages,
like dev, staging, testing,

14
00:00:36,480 --> 00:00:40,030
and multiple branches of
developments getting deployed.

15
00:00:40,030 --> 00:00:44,400
We can easily see this won't
scale to any manual process.

16
00:00:44,400 --> 00:00:46,310
We are all going to have
different requirements

17
00:00:46,310 --> 00:00:48,980
for our deployments,
and there are many ways

18
00:00:48,980 --> 00:00:51,110
to deploy our applications, each with

19
00:00:51,110 --> 00:00:54,640
their own advantages and disadvantages.

20
00:00:54,640 --> 00:00:55,760
Here's Russ to run you through

21
00:00:55,760 --> 00:00:57,380
some different deployment scenarios,

22
00:00:57,380 --> 00:01:00,130
starting with something very simple.

23
00:01:00,130 --> 00:01:02,970
- [Russ] Let's go over
some deployment options.

24
00:01:02,970 --> 00:01:05,763
The simplest deployment
is just three steps.

25
00:01:06,690 --> 00:01:09,710
First, we terminate the
existing application on each

26
00:01:09,710 --> 00:01:11,650
of the hosts where it's running.

27
00:01:11,650 --> 00:01:16,160
Next, we deploy a new
version to the same hosts.

28
00:01:16,160 --> 00:01:18,090
The disadvantage to this approach would be

29
00:01:18,090 --> 00:01:20,670
the downtime between
terminating the application

30
00:01:20,670 --> 00:01:22,120
and the deployment.

31
00:01:22,120 --> 00:01:24,950
The advantage would be how
simple this approach is.

32
00:01:24,950 --> 00:01:27,580
You could have an application
where this isn't an issue.

33
00:01:27,580 --> 00:01:29,650
Maybe the users of your application

34
00:01:29,650 --> 00:01:31,460
are only online during business hours

35
00:01:31,460 --> 00:01:33,210
for a single time zone.

36
00:01:33,210 --> 00:01:34,900
Bringing the application down at 10:00 PM

37
00:01:34,900 --> 00:01:38,480
would have minimal impact, nice and easy.

38
00:01:38,480 --> 00:01:41,320
How would you roll back
this simple deployment?

39
00:01:41,320 --> 00:01:44,160
It's 10:00 PM, we've
rolled out the new version,

40
00:01:44,160 --> 00:01:46,540
some testing has been
performed on the new version

41
00:01:46,540 --> 00:01:49,160
of the application, and
we've encountered an error.

42
00:01:49,160 --> 00:01:50,010
Not great.

43
00:01:50,010 --> 00:01:53,300
We can roll back by returning
to the original version

44
00:01:53,300 --> 00:01:54,620
of the application.

45
00:01:54,620 --> 00:01:57,820
This is effectively the same
steps as initial deployment

46
00:01:57,820 --> 00:02:00,490
using the previous version
of the application.

47
00:02:00,490 --> 00:02:02,770
You might've kept a copy
of the previous version

48
00:02:02,770 --> 00:02:06,350
on the hosts, so we can
terminate our new version

49
00:02:06,350 --> 00:02:08,200
and reinstate the old version.

50
00:02:08,200 --> 00:02:10,990
Remember, it's important to
have a plan for rollback.

51
00:02:10,990 --> 00:02:13,410
Deployments may not go according to plan.

52
00:02:13,410 --> 00:02:15,430
We don't want to come
up with a rollback plan

53
00:02:15,430 --> 00:02:16,570
in the middle of the deployment,

54
00:02:16,570 --> 00:02:19,740
especially not at the
10:00 PM outage window.

55
00:02:21,170 --> 00:02:24,630
What if zero downtime is a
requirement for our deployment?

56
00:02:24,630 --> 00:02:26,730
Let's take an application
that has been deployed

57
00:02:26,730 --> 00:02:29,140
to four hosts behind a load balancer.

58
00:02:29,140 --> 00:02:31,710
We can look at metrics, like CPU usage,

59
00:02:31,710 --> 00:02:34,460
and see that we have enough
resources to remove one

60
00:02:34,460 --> 00:02:38,500
or two hosts from the load
balancer during deployment.

61
00:02:38,500 --> 00:02:41,930
So, I deregister one host
from my load balancer.

62
00:02:41,930 --> 00:02:44,360
The goal here is to stop the traffic going

63
00:02:44,360 --> 00:02:46,310
to the application on the host.

64
00:02:46,310 --> 00:02:49,130
My application continues to work happily

65
00:02:49,130 --> 00:02:51,470
on the remaining hosts, while I deploy

66
00:02:51,470 --> 00:02:53,660
to the deregistered host.

67
00:02:53,660 --> 00:02:57,140
I can do exactly the same
steps on the deregistered host

68
00:02:57,140 --> 00:02:59,170
as my replacement deployment.

69
00:02:59,170 --> 00:03:02,020
Stop the application,
install the new version,

70
00:03:02,020 --> 00:03:04,630
start the application,
and now register with

71
00:03:04,630 --> 00:03:06,290
the load balancer.

72
00:03:06,290 --> 00:03:07,730
My deployment looks good.

73
00:03:07,730 --> 00:03:10,870
I can move onto the remaining hosts.

74
00:03:10,870 --> 00:03:13,520
Let's call this a ramped deployment,

75
00:03:13,520 --> 00:03:15,890
as we're slowly ramping
up the hosts that serve

76
00:03:15,890 --> 00:03:18,230
the new version of the application.

77
00:03:18,230 --> 00:03:19,890
We have zero downtime.

78
00:03:19,890 --> 00:03:21,340
It's a little bit more complex

79
00:03:21,340 --> 00:03:23,620
than the replacement
deployment, as we need

80
00:03:23,620 --> 00:03:25,520
to coordinate with the load balancer,

81
00:03:25,520 --> 00:03:27,150
but it's the same steps that we're using

82
00:03:27,150 --> 00:03:28,500
for our replacement deployment,

83
00:03:28,500 --> 00:03:30,683
so it's not that much more complex.

84
00:03:31,700 --> 00:03:33,760
When the first host is serving version 2

85
00:03:33,760 --> 00:03:36,880
of the application, we can
start gathering metrics on

86
00:03:36,880 --> 00:03:39,360
how the application is performing.

87
00:03:39,360 --> 00:03:43,140
Are we seeing fatal exceptions
coming from the application?

88
00:03:43,140 --> 00:03:45,560
There is a variation on
this type of deployment,

89
00:03:45,560 --> 00:03:48,810
called a canary deployment,
where we stop at a small number

90
00:03:48,810 --> 00:03:52,300
of hosts and gather the
results running version 2

91
00:03:52,300 --> 00:03:54,780
with a percentage of production traffic.

92
00:03:54,780 --> 00:03:57,002
We might discover an
issue with the deployment.

93
00:03:57,002 --> 00:03:58,776
We don't go ahead with the deployment

94
00:03:58,776 --> 00:04:00,901
on our remaining hosts.

95
00:04:00,901 --> 00:04:04,160
Rollback will be similar to
our replacement deployment.

96
00:04:04,160 --> 00:04:06,230
We need to reinstate the previous version

97
00:04:06,230 --> 00:04:09,450
of the application on the
hosts running version 2.

98
00:04:09,450 --> 00:04:13,260
This is going to take time, and
potentially impact our users

99
00:04:13,260 --> 00:04:17,000
while we are removing hosts to
redeploy the previous version

100
00:04:17,000 --> 00:04:18,500
of the application.

101
00:04:18,500 --> 00:04:20,953
We can roll back, it'll just take time.

102
00:04:22,220 --> 00:04:24,830
The deployment options we have covered,

103
00:04:24,830 --> 00:04:26,810
where you use the application hosts,

104
00:04:26,810 --> 00:04:30,120
they are a type of in-place deployment,

105
00:04:30,120 --> 00:04:33,150
but we are working in the cloud,
where we don't really need

106
00:04:33,150 --> 00:04:35,010
to have long-lived hosts.

107
00:04:35,010 --> 00:04:38,940
We can turn on instances and
have them ready super quick.

108
00:04:38,940 --> 00:04:42,163
Let's take advantage of this
with a blue/green deployment.

109
00:04:43,120 --> 00:04:47,210
With a blue/green deployment,
we turn on a new environment

110
00:04:47,210 --> 00:04:49,180
that can handle production load.

111
00:04:49,180 --> 00:04:52,620
We refer to this as the green environment.

112
00:04:52,620 --> 00:04:54,470
The existing production
environment is called

113
00:04:54,470 --> 00:04:55,948
the blue environment.

114
00:04:56,920 --> 00:05:00,110
We deploy the application
to the green hosts.

115
00:05:00,110 --> 00:05:03,570
No production traffic is going
to the green host just yet.

116
00:05:03,570 --> 00:05:06,840
This gives us a chance to
perform some acceptance tests

117
00:05:06,840 --> 00:05:10,590
or smoke tests on the
newly deployed version 2.

118
00:05:10,590 --> 00:05:13,010
We decide we're happy with the deployment.

119
00:05:13,010 --> 00:05:17,480
We can start sending production
traffic to the green hosts.

120
00:05:17,480 --> 00:05:20,410
This can be done with a
DNS switch or registering

121
00:05:20,410 --> 00:05:23,530
and deregistering hosts
from a load balancer.

122
00:05:23,530 --> 00:05:26,880
You control the batch size of
hosts in the green environment

123
00:05:26,880 --> 00:05:28,690
that start receiving production traffic.

124
00:05:28,690 --> 00:05:32,110
Maybe we want to add traffic
to hosts one at a time,

125
00:05:32,110 --> 00:05:35,513
or two at a time, or all
of the hosts at once.

126
00:05:37,440 --> 00:05:41,720
Once we have deployed, what
do we do with the blue hosts

127
00:05:41,720 --> 00:05:44,630
that still have version
1 of the application?

128
00:05:44,630 --> 00:05:46,730
Now is a good time to talk about rollback.

129
00:05:46,730 --> 00:05:48,360
With the blue/green deployment,

130
00:05:48,360 --> 00:05:51,330
we can roll back very quickly
by sending traffic back

131
00:05:51,330 --> 00:05:53,740
to the blue hosts.

132
00:05:53,740 --> 00:05:56,560
We can keep those hosts
available until we are confident

133
00:05:56,560 --> 00:05:58,903
they won't be needed for a rollback.

134
00:06:00,090 --> 00:06:02,610
Before we wrap up, let's
go over some considerations

135
00:06:02,610 --> 00:06:04,070
for your deployments.

136
00:06:04,070 --> 00:06:06,070
Sometimes, your application
may not lend itself

137
00:06:06,070 --> 00:06:07,810
to all forms of deployment.

138
00:06:07,810 --> 00:06:10,500
Blue/green deployments mean
newly provisioned hosts.

139
00:06:10,500 --> 00:06:12,970
What if your application
needs to store state

140
00:06:12,970 --> 00:06:15,880
or data on the same
host as the application?

141
00:06:15,880 --> 00:06:17,310
This isn't a good practice.

142
00:06:17,310 --> 00:06:19,840
Ideally, all applications
should store state external

143
00:06:19,840 --> 00:06:22,100
to the hosts, but some of us are working

144
00:06:22,100 --> 00:06:24,680
with legacy applications
that may not lend themselves

145
00:06:24,680 --> 00:06:26,350
to this type of deployment.

146
00:06:26,350 --> 00:06:30,110
In this case, we would need to
look at in-place deployment.

147
00:06:30,110 --> 00:06:32,740
Zero downtime sounds great,
and something we want

148
00:06:32,740 --> 00:06:34,850
for all of our applications.

149
00:06:34,850 --> 00:06:37,290
Keep in mind during the
zero-downtime deployment,

150
00:06:37,290 --> 00:06:40,730
we're going to have version
1 and 2 running in parallel.

151
00:06:40,730 --> 00:06:44,140
Maybe just for a short time,
but we need to consider this.

152
00:06:44,140 --> 00:06:47,340
We need to make sure
changes remain compatible

153
00:06:47,340 --> 00:06:49,010
with other systems we're talking to,

154
00:06:49,010 --> 00:06:52,010
like a database or an API.

155
00:06:52,010 --> 00:06:54,953
So, good luck with all of
your future deployments.