1
00:00:07,090 --> 00:00:10,810
- When deciding upon a
three tier architecture

2
00:00:10,810 --> 00:00:14,853
using traditional mindsets
around infrastructure,

3
00:00:15,750 --> 00:00:20,300
there are only so many ways
you can achieve resilience

4
00:00:20,300 --> 00:00:23,713
or reliability in the AWS ecosystem.

5
00:00:25,110 --> 00:00:28,100
Let's take a look at an architecture

6
00:00:28,100 --> 00:00:29,850
that helps us move the needle

7
00:00:29,850 --> 00:00:33,290
a little bit closer to cloud native

8
00:00:34,370 --> 00:00:39,120
so that we can take advantage
of other offerings in AWS

9
00:00:39,120 --> 00:00:41,720
that are entirely serverless.

10
00:00:41,720 --> 00:00:44,740
And we can start all the
way out at the frontend

11
00:00:44,740 --> 00:00:47,910
with that initial DNS lookup.

12
00:00:47,910 --> 00:00:52,790
Route 53 uses edge locations
all around the world

13
00:00:52,790 --> 00:00:55,120
for extreme fault tolerance.

14
00:00:55,120 --> 00:00:59,530
And it is designed for 100% uptime

15
00:00:59,530 --> 00:01:02,343
to allow those DNS
lookups to always succeed.

16
00:01:05,020 --> 00:01:07,410
We can use CloudFront,

17
00:01:07,410 --> 00:01:11,980
also operating out at the edge locations

18
00:01:11,980 --> 00:01:16,953
to be able to serve and
cache all of our assets.

19
00:01:18,110 --> 00:01:21,453
And it operates at four
9's of availability.

20
00:01:23,120 --> 00:01:26,653
As we move into region infrastructure,

21
00:01:27,620 --> 00:01:31,233
we have to start defining
origins for CloudFront.

22
00:01:32,150 --> 00:01:34,103
One of these can be an S3 bucket.

23
00:01:34,980 --> 00:01:38,690
So this is where all of our
static content gets stored.

24
00:01:38,690 --> 00:01:42,123
And it's also designed
for four 9's availability.

25
00:01:43,260 --> 00:01:46,700
We could distribute our static content

26
00:01:46,700 --> 00:01:50,600
across multiple buckets
in multiple regions,

27
00:01:50,600 --> 00:01:52,870
and then set up an origin
group for CloudFront

28
00:01:52,870 --> 00:01:55,973
if we want even higher availability.

29
00:01:57,960 --> 00:02:02,630
For dynamic requests, let's
choose the API Gateway.

30
00:02:02,630 --> 00:02:04,743
This would be our dynamic frontend.

31
00:02:05,650 --> 00:02:09,430
As a service, it serves REST API endpoints

32
00:02:09,430 --> 00:02:12,743
and it is also designed for
four 9's of availability.

33
00:02:14,760 --> 00:02:18,570
What if we need to perform
some sort of authentication

34
00:02:18,570 --> 00:02:21,120
for a small number of requests?

35
00:02:21,120 --> 00:02:25,470
We can use Cognito for
that setting up user pools

36
00:02:25,470 --> 00:02:28,180
and then we can perform our authentication

37
00:02:28,180 --> 00:02:30,700
against a serverless offering

38
00:02:30,700 --> 00:02:33,203
that is designed for
three 9's of availability.

39
00:02:34,830 --> 00:02:39,730
Now, as we move to the backend
with our dynamic requests,

40
00:02:39,730 --> 00:02:43,180
we can serve these using Lambda functions.

41
00:02:43,180 --> 00:02:46,730
So this allows us to
implement our business logic.

42
00:02:46,730 --> 00:02:51,300
And as long as we're executing
less than 15 minutes,

43
00:02:51,300 --> 00:02:53,120
Lambda will support that just fine.

44
00:02:53,120 --> 00:02:57,633
And it's designed for three
and a half 9's of availability.

45
00:02:59,330 --> 00:03:02,980
And then finally, we have DynamoDB

46
00:03:02,980 --> 00:03:06,260
that we could use as a persistence tier.

47
00:03:06,260 --> 00:03:08,430
And we know that it's NoSQL,

48
00:03:08,430 --> 00:03:12,780
but we can actually issue SQL queries

49
00:03:12,780 --> 00:03:17,560
against the DynamoDB tables
using the particle engine

50
00:03:17,560 --> 00:03:19,950
that is provided by AWS.

51
00:03:19,950 --> 00:03:22,320
And DynamoDB itself is also designed

52
00:03:22,320 --> 00:03:23,993
for four 9's of availability.

53
00:03:25,180 --> 00:03:29,310
And so within all of this infrastructure,

54
00:03:29,310 --> 00:03:31,060
there's no single point of failure.

55
00:03:31,920 --> 00:03:34,390
There are no discrete resources

56
00:03:34,390 --> 00:03:37,130
with CPU and memory and disk space

57
00:03:37,130 --> 00:03:40,400
and network throughput that
we have to worry about.

58
00:03:40,400 --> 00:03:42,950
There are no user accounts.

59
00:03:42,950 --> 00:03:47,050
There's no individual disks that can fail.

60
00:03:47,050 --> 00:03:49,240
There are no OS updates.

61
00:03:49,240 --> 00:03:53,830
The entire thing is
going to have a very low

62
00:03:53,830 --> 00:03:56,620
total cost of ownership or TCO

63
00:03:56,620 --> 00:04:01,620
because we lose all of those
traditional manual operations

64
00:04:02,330 --> 00:04:06,430
that need to be performed
against a three tier architecture

65
00:04:06,430 --> 00:04:10,500
that's deployed as a
load balancer with EC2

66
00:04:10,500 --> 00:04:11,883
and a database backend.
