1
00:00:06,750 --> 00:00:11,470
- Now let's review Amazon's
Simple Queue Service, or SQS.

2
00:00:11,470 --> 00:00:13,330
With Amazon Simple Queue Service,

3
00:00:13,330 --> 00:00:16,490
we gain a fully managed queue service

4
00:00:16,490 --> 00:00:21,030
and so there's no instance
of any kind of server

5
00:00:21,030 --> 00:00:22,510
that we need to provision,

6
00:00:22,510 --> 00:00:25,570
nothing is sitting there
idle that we're paying for,

7
00:00:25,570 --> 00:00:27,230
there's no software to install.

8
00:00:27,230 --> 00:00:30,820
We simply go to the Simple Queue
Service and create a queue.

9
00:00:30,820 --> 00:00:33,410
And then, all of the
underlying infrastructure

10
00:00:33,410 --> 00:00:35,801
necessary to maintain that queue,

11
00:00:35,801 --> 00:00:38,710
including high availability,
fault tolerance,

12
00:00:38,710 --> 00:00:42,437
durability of messages,
is all handled by AWS.

13
00:00:43,956 --> 00:00:47,130
The system itself scales automatically.

14
00:00:47,130 --> 00:00:51,640
With the standard queue, we
can scale almost limitlessly

15
00:00:51,640 --> 00:00:54,695
and we can control authorization

16
00:00:54,695 --> 00:00:57,710
using the identity and access management

17
00:00:57,710 --> 00:01:00,920
specifically for users groups or roles.

18
00:01:00,920 --> 00:01:03,580
We can also use a resource policy,

19
00:01:03,580 --> 00:01:08,580
so we can control usage of
the queue at the queue itself

20
00:01:08,690 --> 00:01:12,140
and by doing that, we
can use a resource policy

21
00:01:12,140 --> 00:01:15,070
to share that queue with another account,

22
00:01:15,070 --> 00:01:17,620
being it an account that we own

23
00:01:17,620 --> 00:01:21,500
or an account owned by a third party.

24
00:01:21,500 --> 00:01:24,470
We can also share the
queue to anonymous users,

25
00:01:24,470 --> 00:01:25,813
if we needed to.

26
00:01:28,040 --> 00:01:30,690
SQS also supports server side encryption,

27
00:01:30,690 --> 00:01:33,690
so if you are dealing with messages

28
00:01:33,690 --> 00:01:37,466
and data, such as personally
identifiable information

29
00:01:37,466 --> 00:01:39,972
or protected health information

30
00:01:39,972 --> 00:01:42,630
then we can leverage
server side encryption

31
00:01:42,630 --> 00:01:46,600
using AES256 to ensure that those messages

32
00:01:46,600 --> 00:01:50,090
are encrypted at rest.

33
00:01:50,090 --> 00:01:52,010
Now, with the Simple Queue Service,

34
00:01:52,010 --> 00:01:55,290
we have two different types of queues.

35
00:01:55,290 --> 00:01:58,540
We have a standard queue and a FIFO queue.

36
00:01:58,540 --> 00:02:00,355
With the standard queue,

37
00:02:00,355 --> 00:02:04,540
keep in mind that the
order is not guaranteed

38
00:02:07,132 --> 00:02:10,660
and it does make a best
effort to deliver it in order,

39
00:02:10,660 --> 00:02:12,940
but it's not guaranteed.

40
00:02:12,940 --> 00:02:16,560
It's also an at-least-once delivery model,

41
00:02:16,560 --> 00:02:20,760
meaning that it's possible for a message

42
00:02:20,760 --> 00:02:23,330
to be delivered more than once.

43
00:02:23,330 --> 00:02:26,010
So, your application would be responsible

44
00:02:26,010 --> 00:02:29,900
for any kind of either D duplication

45
00:02:29,900 --> 00:02:33,670
or ensuring that your
operations are item potent,

46
00:02:33,670 --> 00:02:38,660
meaning that if you end up
performing the same process

47
00:02:38,660 --> 00:02:40,130
on the same message twice,

48
00:02:40,130 --> 00:02:41,980
then you end up with the same result.

49
00:02:43,270 --> 00:02:45,030
Now, with the standard queue,

50
00:02:45,030 --> 00:02:48,060
we get nearly unlimited throughput.

51
00:02:48,060 --> 00:02:49,900
There's really nothing for us to do

52
00:02:49,900 --> 00:02:53,840
to ensure that the
standard queue can scale

53
00:02:53,840 --> 00:02:56,490
to just about any throughput level.

54
00:02:56,490 --> 00:02:59,350
We can send millions
and millions of messages

55
00:02:59,350 --> 00:03:01,090
through the standard queue,

56
00:03:01,090 --> 00:03:04,960
and again, AWS is responsible for ensuring

57
00:03:06,400 --> 00:03:08,030
that it scales.

58
00:03:08,030 --> 00:03:10,170
AWS handles all of the infrastructure

59
00:03:10,170 --> 00:03:12,013
necessary to make that happen.

60
00:03:13,028 --> 00:03:16,796
Now we also have First
In First Out queues.

61
00:03:16,796 --> 00:03:21,080
With FIFO queues, the order is guaranteed

62
00:03:21,080 --> 00:03:24,890
and it also follows an
exactly-once delivery

63
00:03:24,890 --> 00:03:26,770
so there are plenty of applications

64
00:03:26,770 --> 00:03:31,770
where you rely on the order absolutely

65
00:03:32,023 --> 00:03:36,180
and many applications
where you can't afford

66
00:03:36,180 --> 00:03:38,120
to do things twice

67
00:03:38,120 --> 00:03:40,340
so you need an exactly-once delivery.

68
00:03:40,340 --> 00:03:43,850
So if you need order, if you
need exactly once delivery,

69
00:03:43,850 --> 00:03:46,830
then take a look at the FIFO queue.

70
00:03:46,830 --> 00:03:50,540
And so the difference in
throughput between these two

71
00:03:50,540 --> 00:03:51,580
is fairly significant.

72
00:03:51,580 --> 00:03:53,470
Again, with standard queue,

73
00:03:53,470 --> 00:03:55,650
we get nearly unlimited throughput,

74
00:03:55,650 --> 00:03:57,400
but with the FIFO queue,

75
00:03:57,400 --> 00:04:01,830
we do have an upper limit of
about 3000 messages per second

76
00:04:01,830 --> 00:04:04,863
if we are using a batch type of operation.

77
00:04:06,460 --> 00:04:08,993
So let's take a look at a diagram here.

78
00:04:09,960 --> 00:04:11,470
The idea with the queue,

79
00:04:11,470 --> 00:04:13,540
I'm sure many of us are
familiar with queues,

80
00:04:13,540 --> 00:04:15,050
some of us may not be,

81
00:04:15,050 --> 00:04:16,950
but in terms of queues

82
00:04:16,950 --> 00:04:20,270
and how they can benefit our applications,

83
00:04:20,270 --> 00:04:24,540
with this diagram, you can see here that

84
00:04:27,100 --> 00:04:32,100
we have some type of an application
running on EC2 instances

85
00:04:32,970 --> 00:04:35,130
and those are behind a load balancer.

86
00:04:35,130 --> 00:04:38,134
So, it could be that users

87
00:04:38,134 --> 00:04:43,134
are asking for some
kind of work to be done.

88
00:04:45,040 --> 00:04:47,010
They could be uploading documents

89
00:04:47,010 --> 00:04:50,880
and our application on EC2 is responsible

90
00:04:50,880 --> 00:04:53,157
for ingesting those documents

91
00:04:53,157 --> 00:04:57,630
or it could be that they are
asking for some kind of report

92
00:04:57,630 --> 00:05:00,210
and then willing to wait for that report

93
00:05:00,210 --> 00:05:02,120
to be delivered to them later.

94
00:05:02,120 --> 00:05:04,100
Either way, what we're looking at here

95
00:05:04,100 --> 00:05:08,203
is the first stage of
an asynchronous process.

96
00:05:09,970 --> 00:05:14,550
The idea here is that we
don't really want to rely

97
00:05:14,550 --> 00:05:19,100
on our backend instances
here to perform everything.

98
00:05:19,100 --> 00:05:21,320
We want to decouple, for example,

99
00:05:21,320 --> 00:05:22,905
if we're ingesting images,

100
00:05:22,905 --> 00:05:27,905
we want to decouple image
ingestion from image processing.

101
00:05:28,820 --> 00:05:32,530
We want to decouple a
user requesting a report

102
00:05:32,530 --> 00:05:35,750
from the report actually being generated.

103
00:05:35,750 --> 00:05:39,220
And so, the way that we could use this

104
00:05:39,220 --> 00:05:44,220
is that within Amazon
SQS, within the service,

105
00:05:44,300 --> 00:05:49,030
we simply create a queue and
that's all we have to do.

106
00:05:49,030 --> 00:05:50,580
We create a queue, we give it a name

107
00:05:50,580 --> 00:05:55,090
and we get a particular
DNS endpoint for that queue

108
00:05:55,090 --> 00:06:00,090
and then our instances
sends messages to the queue

109
00:06:01,990 --> 00:06:05,760
and those messages will buffer,

110
00:06:05,760 --> 00:06:07,350
they will stack up in the queue

111
00:06:08,590 --> 00:06:11,363
and then our back end instances,

112
00:06:13,040 --> 00:06:18,040
here we have back end
instances that are responsible

113
00:06:19,420 --> 00:06:22,820
for doing the work, whatever that work is.

114
00:06:22,820 --> 00:06:26,670
It could be doing some type
of an image processing,

115
00:06:26,670 --> 00:06:28,700
it could be video transcoding,

116
00:06:28,700 --> 00:06:31,510
it could be executing some type of report

117
00:06:31,510 --> 00:06:35,660
on a large data set that's
going to take some time.

118
00:06:35,660 --> 00:06:37,160
Our user has requested it,

119
00:06:37,160 --> 00:06:38,890
now they're off doing something else

120
00:06:38,890 --> 00:06:41,123
while the report is being generated.

121
00:06:43,760 --> 00:06:46,403
These systems back here, whatever this is,

122
00:06:47,720 --> 00:06:49,370
all it has to do now

123
00:06:50,350 --> 00:06:52,163
is pull the queue.

124
00:06:53,240 --> 00:06:58,060
By pulling the queue, it can
then receive these messages.

125
00:06:58,060 --> 00:07:01,010
Once it receives the message,
it can then do the work.

126
00:07:01,010 --> 00:07:02,360
Once that work is completed,

127
00:07:02,360 --> 00:07:04,533
it then deletes the
message from the queue.

128
00:07:05,730 --> 00:07:10,730
Now, these back end instances
here could be anything.

129
00:07:12,540 --> 00:07:14,313
Doesn't have to be EC2.

130
00:07:16,670 --> 00:07:20,670
Those could be Lambda Functions.

131
00:07:20,670 --> 00:07:22,970
They could be containers

132
00:07:22,970 --> 00:07:25,930
running within ECS or EKS.

133
00:07:25,930 --> 00:07:29,637
In fact, it doesn't even
have to be anything on

134
00:07:29,637 --> 00:07:31,530
or within AWS.

135
00:07:31,530 --> 00:07:34,410
It could very well be servers,

136
00:07:34,410 --> 00:07:37,070
traditional servers running on premises.

137
00:07:37,070 --> 00:07:41,540
But the idea here is again,
that we are looking to decouple

138
00:07:42,435 --> 00:07:46,590
whatever work is being done back here

139
00:07:46,590 --> 00:07:48,990
from whatever work is being done up here

140
00:07:48,990 --> 00:07:51,570
so that if either one is down,

141
00:07:51,570 --> 00:07:54,830
if our back end is down then messages

142
00:07:54,830 --> 00:07:56,620
can simply continue to buffer

143
00:07:56,620 --> 00:07:58,090
and stack up in the queue

144
00:07:58,090 --> 00:08:02,944
and the back end being
down should not bring down

145
00:08:02,944 --> 00:08:05,340
our file ingestion.

146
00:08:05,340 --> 00:08:07,200
We should still be able to ingest

147
00:08:07,200 --> 00:08:09,240
or do the front end work

148
00:08:09,240 --> 00:08:12,420
until we're able to get
the back end back online.

149
00:08:12,420 --> 00:08:14,940
And the converse is true as well.

150
00:08:14,940 --> 00:08:18,830
If image ingestion is offline temporarily,

151
00:08:18,830 --> 00:08:22,840
then our back end can continue
to work through the messages

152
00:08:22,840 --> 00:08:24,343
that are already in the queue.

153
00:08:25,218 --> 00:08:28,350
If you have a need for a queue,

154
00:08:28,350 --> 00:08:31,374
if you need the ability to send messages

155
00:08:31,374 --> 00:08:33,490
between components like this,

156
00:08:33,490 --> 00:08:35,360
if you are looking to decouple

157
00:08:35,360 --> 00:08:39,110
different stages of
your larger application,

158
00:08:39,110 --> 00:08:42,743
then definitely take a look at
Amazon Simple Queue Service.