1
00:00:06,930 --> 00:00:10,080
- Now let's review some best practices.

2
00:00:10,080 --> 00:00:13,920
As you move forward, getting into AWS

3
00:00:13,920 --> 00:00:16,510
as you start thinking about architectures

4
00:00:16,510 --> 00:00:19,505
that will go to AWS and
be built within AWS,

5
00:00:19,505 --> 00:00:23,197
as you start to explore
in different services,

6
00:00:23,197 --> 00:00:27,620
there are a number of best
practices to keep in mind,

7
00:00:27,620 --> 00:00:31,140
to help you ensure that
you are building, you know,

8
00:00:31,140 --> 00:00:35,330
the most performant, reliable, secure,

9
00:00:35,330 --> 00:00:40,080
and cost effective
infrastructure within AWS.

10
00:00:40,080 --> 00:00:42,900
First would be, and these
are in no particular order,

11
00:00:42,900 --> 00:00:46,120
but first, enable scalability.

12
00:00:46,120 --> 00:00:47,670
And so,

13
00:00:47,670 --> 00:00:50,860
scalability allows you to meet demand

14
00:00:50,860 --> 00:00:51,950
when you have it.

15
00:00:51,950 --> 00:00:54,871
So there could come a time
when you have more demand

16
00:00:54,871 --> 00:00:59,150
or more work to do, than
what you did the day before.

17
00:00:59,150 --> 00:01:02,890
And so by enabling scalability
by building a system

18
00:01:02,890 --> 00:01:06,360
that is elastic, by building
a system that can respond

19
00:01:06,360 --> 00:01:09,480
to those kinds of changes and enabling you

20
00:01:09,480 --> 00:01:12,560
to scale to meet that rise in demand,

21
00:01:12,560 --> 00:01:15,720
then you can ensure that you
will be able to meet it, right?

22
00:01:15,720 --> 00:01:19,220
So you can imagine that if
you have no ability to scale

23
00:01:19,220 --> 00:01:21,633
and then at some point
you have more demand

24
00:01:21,633 --> 00:01:23,970
than you had previously,

25
00:01:23,970 --> 00:01:24,803
then

26
00:01:24,803 --> 00:01:27,390
at some point that system may very well

27
00:01:27,390 --> 00:01:28,693
experience down time.

28
00:01:30,610 --> 00:01:34,450
The next best practice is
to think of our resources

29
00:01:34,450 --> 00:01:35,850
as disposal, right?

30
00:01:35,850 --> 00:01:38,110
So we're leveraging disposable resources

31
00:01:38,110 --> 00:01:39,920
rather than fixed servers.

32
00:01:39,920 --> 00:01:42,310
So coming from traditional IT,

33
00:01:42,310 --> 00:01:45,820
we had fixed servers,
we spent a lot of money

34
00:01:45,820 --> 00:01:48,850
and a lot effort, getting
that server in that rack,

35
00:01:48,850 --> 00:01:52,590
and we had a particular budget
and we're not going to do

36
00:01:52,590 --> 00:01:54,870
anything more with it, we're
not going to replace it

37
00:01:54,870 --> 00:01:57,920
for another two to five
years, maybe longer, right?

38
00:01:57,920 --> 00:02:00,408
So in traditional IT we had fixed servers

39
00:02:00,408 --> 00:02:03,684
which meant that our
processes and our capabilities

40
00:02:03,684 --> 00:02:07,100
were also fixed to some degree.

41
00:02:07,100 --> 00:02:07,933
With AWS

42
00:02:09,070 --> 00:02:11,580
by leveraging just the nature

43
00:02:11,580 --> 00:02:14,738
of on demand resources
means that we can now

44
00:02:14,738 --> 00:02:17,900
treat those resources as disposable.

45
00:02:17,900 --> 00:02:22,560
And that give rise to a level
of flexibility and agility

46
00:02:22,560 --> 00:02:26,910
and efficiency that we never
really had with traditional IT.

47
00:02:26,910 --> 00:02:28,969
By treating them as disposable,

48
00:02:28,969 --> 00:02:31,090
then we have the ability now

49
00:02:31,090 --> 00:02:33,950
to create temporary environments, right?

50
00:02:33,950 --> 00:02:37,610
We no longer have to force
our teams to wait in line

51
00:02:37,610 --> 00:02:40,040
to test their applications.

52
00:02:40,040 --> 00:02:42,240
Each team can get a temporary environment

53
00:02:42,240 --> 00:02:46,750
for that application. When the
test is done, throw it away.

54
00:02:46,750 --> 00:02:48,580
Disposable resources

55
00:02:48,580 --> 00:02:50,240
now frees us

56
00:02:50,240 --> 00:02:53,220
to just replace the machine

57
00:02:53,220 --> 00:02:55,380
instead of triaging the machine, right?

58
00:02:55,380 --> 00:02:56,213
In traditional IT,

59
00:02:56,213 --> 00:02:59,420
we would have to remote into that machine,

60
00:02:59,420 --> 00:03:02,984
and spend a lot of time
and effort, you know,

61
00:03:02,984 --> 00:03:04,090
er, you know, er

62
00:03:04,090 --> 00:03:06,880
essentially babying, treating
that machine like our pet

63
00:03:06,880 --> 00:03:09,800
and ensuring that it stays alive.

64
00:03:09,800 --> 00:03:14,140
But in AWS, we simply, if there's
an issue, we terminate it,

65
00:03:14,140 --> 00:03:17,570
and allow automated processes
to bring that machine

66
00:03:17,570 --> 00:03:20,940
back to life, doing what
it's supposed to do.

67
00:03:20,940 --> 00:03:23,500
And if we need that machine
in a different state

68
00:03:23,500 --> 00:03:26,470
then we can go back to our machine images,

69
00:03:26,470 --> 00:03:28,510
we can go back to configuration management

70
00:03:28,510 --> 00:03:31,628
and define, and configure
that state there.

71
00:03:31,628 --> 00:03:33,060
And of course,

72
00:03:33,060 --> 00:03:35,550
another best practice is
to leverage automation.

73
00:03:35,550 --> 00:03:38,750
We want to avoid manual operations

74
00:03:38,750 --> 00:03:40,280
as much as possible, right?

75
00:03:40,280 --> 00:03:43,550
Remember that humans, we
make mistakes, you know,

76
00:03:43,550 --> 00:03:46,427
we come to work without
enough food, sleep,

77
00:03:46,427 --> 00:03:48,623
we come to work with, you know,

78
00:03:48,623 --> 00:03:51,650
maybe something going on in our lives

79
00:03:51,650 --> 00:03:54,380
that is distracting us from
the work that we're doing

80
00:03:54,380 --> 00:03:57,100
and as a result, we make mistakes

81
00:03:57,100 --> 00:04:00,050
and those mistakes cost
time, they cost money,

82
00:04:00,050 --> 00:04:05,050
or they potentially could cause
some time of security issue.

83
00:04:05,253 --> 00:04:08,580
So by leveraging
automation, we can do things

84
00:04:08,580 --> 00:04:12,100
more efficiently, we can do
things more cost effectively,

85
00:04:12,100 --> 00:04:14,143
we can do things more securely.

86
00:04:15,720 --> 00:04:19,140
Another best practice is
to leverage loose coupling.

87
00:04:19,140 --> 00:04:22,200
Loose coupling, one classic
example of loose coupling

88
00:04:22,200 --> 00:04:26,040
is, instead of two different
systems being inherently aware

89
00:04:26,040 --> 00:04:28,587
of one another and
dependent on one another,

90
00:04:28,587 --> 00:04:31,190
we can put a queue in the middle.

91
00:04:31,190 --> 00:04:33,400
Or a load balancer in the middle.

92
00:04:33,400 --> 00:04:34,542
That way,

93
00:04:34,542 --> 00:04:38,370
by removing the inherent
knowledge of those

94
00:04:38,370 --> 00:04:39,570
of each other

95
00:04:39,570 --> 00:04:42,220
those systems can then run independently.

96
00:04:42,220 --> 00:04:45,840
So ideally, if we have multiple systems

97
00:04:46,810 --> 00:04:50,120
we should be able to have an environment

98
00:04:50,120 --> 00:04:53,120
in which one system can be off line

99
00:04:53,120 --> 00:04:55,770
without affecting another systems, right?

100
00:04:55,770 --> 00:04:58,150
That's what loose coupling aims to do.

101
00:04:58,150 --> 00:05:01,690
Where, by leveraging a queue, for example,

102
00:05:01,690 --> 00:05:04,310
one system can publish
a message to the queue,

103
00:05:04,310 --> 00:05:06,000
another system reads from it.

104
00:05:06,000 --> 00:05:08,680
That way if either one system is down,

105
00:05:08,680 --> 00:05:10,900
the other system can continue to run.

106
00:05:10,900 --> 00:05:15,470
Another best practice is to
prefer services, not servers.

107
00:05:15,470 --> 00:05:18,250
And so, what this speaks to is the fact

108
00:05:18,250 --> 00:05:22,920
that AWS offers a number
of fully managed services.

109
00:05:22,920 --> 00:05:25,810
So, think about simple queue
service, simple email service,

110
00:05:25,810 --> 00:05:27,978
simple notification service,

111
00:05:27,978 --> 00:05:31,610
think about the relational
database service,

112
00:05:31,610 --> 00:05:34,184
Elasticashe, Redshift, and so on.

113
00:05:34,184 --> 00:05:36,310
All of these services

114
00:05:36,310 --> 00:05:37,750
are meant for us

115
00:05:37,750 --> 00:05:41,610
to offload the operational burdens to AWS.

116
00:05:41,610 --> 00:05:43,238
And so by doing that,

117
00:05:43,238 --> 00:05:46,887
we can lower our total costs of ownership,

118
00:05:46,887 --> 00:05:51,570
Because we can have one,
may perhaps a smaller team

119
00:05:51,570 --> 00:05:53,470
and then that team is focused

120
00:05:53,470 --> 00:05:58,470
on delivering actual differentiated
value to our application

121
00:05:58,760 --> 00:06:02,060
rather than being burdened
by managing servers.

122
00:06:02,060 --> 00:06:03,970
A few more best practices here

123
00:06:05,443 --> 00:06:06,430
first would be

124
00:06:06,430 --> 00:06:08,933
choose the right database, right?

125
00:06:10,805 --> 00:06:13,390
A number of applications these
days are actually making use

126
00:06:13,390 --> 00:06:16,050
of several different
types of databases, right?

127
00:06:16,050 --> 00:06:18,890
It's common for an application to make use

128
00:06:18,890 --> 00:06:21,630
of relational databases,
no sequel databases,

129
00:06:21,630 --> 00:06:24,070
in memory caches, and so on, right?

130
00:06:24,070 --> 00:06:27,753
So choosing the right
database for the right problem

131
00:06:27,753 --> 00:06:30,730
is key to ensuring that we're going to get

132
00:06:30,730 --> 00:06:34,380
a level of performance and
security and durability

133
00:06:34,380 --> 00:06:36,820
that we need in that data.

134
00:06:36,820 --> 00:06:40,470
Another best practice is to
avoid single points of failure.

135
00:06:40,470 --> 00:06:41,920
I think that goes without saying

136
00:06:41,920 --> 00:06:44,350
that something we've
probably been familiar with

137
00:06:44,350 --> 00:06:48,140
for a long time, but it's
important to remind ourselves

138
00:06:48,140 --> 00:06:50,508
that even within AWS,
it's possible to have

139
00:06:50,508 --> 00:06:53,180
single points of failure, right?

140
00:06:53,180 --> 00:06:55,140
So, like we talked about earlier,

141
00:06:55,140 --> 00:06:59,010
it's possible to run an
application one EC2 instant.

142
00:06:59,010 --> 00:07:01,080
But by doing so,

143
00:07:01,080 --> 00:07:05,050
we have no way of mitigating or tolerating

144
00:07:05,050 --> 00:07:06,160
a failure.

145
00:07:06,160 --> 00:07:10,060
If that one instance fails,
we will experience down time

146
00:07:10,060 --> 00:07:11,200
until it's replaced.

147
00:07:11,200 --> 00:07:14,820
And so instead of running an
application on one instance,

148
00:07:14,820 --> 00:07:17,960
we can run it on two, or
three, or twenty, right?

149
00:07:17,960 --> 00:07:19,820
And put them behind a load balancer

150
00:07:19,820 --> 00:07:22,390
so that if one fails, we
still have the others.

151
00:07:22,390 --> 00:07:25,880
And that same pattern applies
to a number of things,

152
00:07:25,880 --> 00:07:27,863
not just EC2 instances.

153
00:07:28,880 --> 00:07:32,670
And then of course we
want to optimize for cost.

154
00:07:32,670 --> 00:07:35,720
One of the main drivers for moving to AWS

155
00:07:35,720 --> 00:07:38,260
is to lower our cost.

156
00:07:38,260 --> 00:07:40,820
Believe it or not, it's
not the number one driver.

157
00:07:40,820 --> 00:07:44,410
The number one driver
for most organizations

158
00:07:44,410 --> 00:07:48,620
is to gain access to a level
flexibility and agility

159
00:07:48,620 --> 00:07:50,370
that we never had before.

160
00:07:50,370 --> 00:07:53,940
But who wants to spend more
money then we need to, right?

161
00:07:53,940 --> 00:07:55,960
So, as we've seen throughout this course,

162
00:07:55,960 --> 00:07:59,600
we have plenty of tools,
and plenty of options

163
00:07:59,600 --> 00:08:04,600
to choose in order to build
a system that is reliable

164
00:08:04,640 --> 00:08:07,703
performant, secure, and cost effective.

165
00:08:09,480 --> 00:08:12,170
And of course, when it comes to optimizing

166
00:08:13,200 --> 00:08:15,480
whatever we're optimizing for,

167
00:08:15,480 --> 00:08:19,840
this is not something, you
know, that we do every so often.

168
00:08:19,840 --> 00:08:23,310
Optimization for cost or for
security, or performance,

169
00:08:23,310 --> 00:08:26,600
or reliability is not
something we do, you know,

170
00:08:26,600 --> 00:08:28,680
every month, every six months,

171
00:08:28,680 --> 00:08:30,620
it's something that we do every day.

172
00:08:30,620 --> 00:08:33,890
And that's another philosophy

173
00:08:33,890 --> 00:08:36,460
to adopt when coming to AWS.

174
00:08:36,460 --> 00:08:39,810
And that's something that
is spoken to quite a bit

175
00:08:39,810 --> 00:08:42,050
in the operation excellence pillar

176
00:08:42,050 --> 00:08:44,030
of the well architected framework.

177
00:08:44,030 --> 00:08:48,690
That optimization is an
on-going, constant effort.

178
00:08:48,690 --> 00:08:51,570
And I can speak from personal experience,

179
00:08:51,570 --> 00:08:55,520
that in running many
different types of workloads

180
00:08:55,520 --> 00:08:57,660
in production from many organizations,

181
00:08:57,660 --> 00:09:00,403
and helping organizations to strategies

182
00:09:00,403 --> 00:09:02,740
and plan for the cloud,

183
00:09:02,740 --> 00:09:05,730
that this becomes something
that we do everyday.

184
00:09:05,730 --> 00:09:07,677
That everyday, you come to work and go:

185
00:09:07,677 --> 00:09:11,040
"how can I make this better
than it was yesterday?"

186
00:09:11,040 --> 00:09:13,760
And we have the ability,

187
00:09:13,760 --> 00:09:16,502
looking back on all the
things that we've talked about

188
00:09:16,502 --> 00:09:21,502
you can see that we have an
easy ability to change our minds

189
00:09:21,530 --> 00:09:22,363
at any time.

190
00:09:22,363 --> 00:09:25,467
If I come in today and I
look at the system and I ask

191
00:09:25,467 --> 00:09:27,350
"how can I improve this today,

192
00:09:27,350 --> 00:09:30,040
how can I make it better
than it was yesterday"

193
00:09:30,040 --> 00:09:33,930
I don't have to wait for
my next budget refresh.

194
00:09:33,930 --> 00:09:38,810
I don't have to wait for,
you know, hardware recycle.

195
00:09:38,810 --> 00:09:41,650
I can do it today, I
can make changes today.

196
00:09:41,650 --> 00:09:45,713
No decision that I've made
so far is set in stone.

197
00:09:46,940 --> 00:09:51,120
And then lastly here,
one more, a couple more,

198
00:09:51,120 --> 00:09:52,710
is leverage caching.

199
00:09:52,710 --> 00:09:56,790
We talked about caching
when we covered cloudfront.

200
00:09:56,790 --> 00:09:59,640
Remember that with cloudfront we can cache

201
00:09:59,640 --> 00:10:03,020
static and dynamic content
at the edge location.

202
00:10:03,020 --> 00:10:06,060
We also talked about
caching with elasticache.

203
00:10:06,060 --> 00:10:09,480
With elasticache, we can cache
different types of things,

204
00:10:09,480 --> 00:10:13,360
such as data-base result sets in memory.

205
00:10:13,360 --> 00:10:15,280
And the whole point of caching

206
00:10:15,280 --> 00:10:19,180
is to deliver things
to the end user faster.

207
00:10:19,180 --> 00:10:20,210
The whole point of caching

208
00:10:20,210 --> 00:10:22,910
is to improve the end user's

209
00:10:23,920 --> 00:10:26,350
experience by lowering latency,

210
00:10:26,350 --> 00:10:28,833
by getting them what
they're looking for faster.

211
00:10:30,270 --> 00:10:32,173
And then lastly,

212
00:10:33,050 --> 00:10:35,120
the last best practice
that I'll leave you with

213
00:10:35,120 --> 00:10:37,090
is security in layers.

214
00:10:37,090 --> 00:10:40,370
And remember that there are,
when you think about layers,

215
00:10:40,370 --> 00:10:43,540
we could imagine that
there are different layers,

216
00:10:43,540 --> 00:10:46,210
and I always imagine that there would be

217
00:10:46,210 --> 00:10:50,030
the account layer, there
would be the network layer,

218
00:10:50,030 --> 00:10:53,120
and then perhaps the
application layer, right?

219
00:10:53,120 --> 00:10:56,300
And so, remember that
we are operating within

220
00:10:56,300 --> 00:10:58,230
a shared responsibility model.

221
00:10:58,230 --> 00:11:01,320
The most important thing
in there is for you

222
00:11:01,320 --> 00:11:04,895
to be aware of what,
whatever you're using,

223
00:11:04,895 --> 00:11:07,789
whatever service you are making use of,

224
00:11:07,789 --> 00:11:10,770
it's important for you to be aware

225
00:11:10,770 --> 00:11:12,700
of what is your responsibility,

226
00:11:12,700 --> 00:11:15,380
versus what is Amazon's responsibility.

227
00:11:15,380 --> 00:11:17,350
And those things change.

228
00:11:17,350 --> 00:11:19,560
According to the service that you're using

229
00:11:19,560 --> 00:11:23,070
and according to the features
that you have opted into

230
00:11:23,070 --> 00:11:25,060
And so at the account layer

231
00:11:25,060 --> 00:11:28,440
we have users and groups and roles,

232
00:11:28,440 --> 00:11:32,500
we have policies that can
control authorisation.

233
00:11:32,500 --> 00:11:37,420
Within the network layer,
we have routing controls,

234
00:11:37,420 --> 00:11:40,800
to control the flow of traffic,
to and from the internet ,

235
00:11:40,800 --> 00:11:42,390
or not.

236
00:11:42,390 --> 00:11:44,810
We also have different
firewalls mechanisms

237
00:11:44,810 --> 00:11:46,860
like network access control lists,

238
00:11:46,860 --> 00:11:49,910
we have security groups
that can open and allow

239
00:11:49,910 --> 00:11:52,560
different types of traffic
on different ports.

240
00:11:52,560 --> 00:11:54,970
And then of course,
within your application,

241
00:11:54,970 --> 00:11:58,890
your application may make
use of temporary credentials

242
00:11:58,890 --> 00:12:02,520
in order to access
Amazon's services, right?

243
00:12:02,520 --> 00:12:05,570
So the bast practice here is to ensure

244
00:12:05,570 --> 00:12:07,740
that you are applying security,

245
00:12:07,740 --> 00:12:09,760
the appropriate security features

246
00:12:09,760 --> 00:12:12,130
in each of those layers, right?

247
00:12:12,130 --> 00:12:15,280
So again, as you move forward,

248
00:12:15,280 --> 00:12:18,350
getting to know Amazon web services more,

249
00:12:18,350 --> 00:12:20,610
as you start to explore these services,

250
00:12:20,610 --> 00:12:22,310
and build these services,

251
00:12:22,310 --> 00:12:24,423
keep these best practices in mind.