1 00:00:00,140 --> 00:00:02,570 Okay so let's discuss serverless architectures. 2 00:00:02,570 --> 00:00:03,860 Now, we're going to create 3 00:00:03,860 --> 00:00:06,590 a mobile application called MyTodoList. 4 00:00:06,590 --> 00:00:08,419 So what we want to do is have the following requirements, 5 00:00:08,419 --> 00:00:13,228 we want to expose a REST API that has HTTPS endpoints, 6 00:00:13,228 --> 00:00:15,514 we want to be serverless architecture 7 00:00:15,514 --> 00:00:18,311 and we want the users to be able to directly interact 8 00:00:18,311 --> 00:00:21,580 with their own folder in S3 to manage their data 9 00:00:21,580 --> 00:00:22,570 if they want to. 10 00:00:22,570 --> 00:00:24,860 And users should be able to also authenticate 11 00:00:24,860 --> 00:00:27,600 through a managed serverless service. 12 00:00:27,600 --> 00:00:30,880 And finally, users can write and read to-dos, 13 00:00:30,880 --> 00:00:32,170 but they mostly read them, 14 00:00:32,170 --> 00:00:34,640 so maybe there's something to do around performance here. 15 00:00:34,640 --> 00:00:36,300 The database layer should scale, 16 00:00:36,300 --> 00:00:39,600 and should have some really high read throughputs. 17 00:00:39,600 --> 00:00:40,960 So that's a pretty good requirement, 18 00:00:40,960 --> 00:00:42,900 now let's see how we can do it. 19 00:00:42,900 --> 00:00:45,862 Number one is to get started, we have a mobile client, 20 00:00:45,862 --> 00:00:49,740 and we talked about doing a rest HTTPS thing, 21 00:00:49,740 --> 00:00:52,180 so let's use Amazon API Gateway for this. 22 00:00:52,180 --> 00:00:53,373 This is a great way of doing it. 23 00:00:53,373 --> 00:00:56,404 Now in a classic serverless API fashion, 24 00:00:56,404 --> 00:00:59,179 API Gateway will invoke a lender function 25 00:00:59,179 --> 00:01:01,040 which basically allows us to scale 26 00:01:01,040 --> 00:01:03,670 and use serverless infrastructure. 27 00:01:03,670 --> 00:01:06,070 Okay, Amazon Lambda needs to be able to store 28 00:01:06,070 --> 00:01:08,690 and read to-do from a database. 29 00:01:08,690 --> 00:01:10,026 A database that scales really well 30 00:01:10,026 --> 00:01:13,100 that is serverless is DynamoDB. 31 00:01:13,100 --> 00:01:15,440 So here, we have DynamoDB as our backend. 32 00:01:15,440 --> 00:01:16,960 Now we said there was going to be also 33 00:01:16,960 --> 00:01:20,030 some kind of authentication layer going on so, 34 00:01:20,030 --> 00:01:21,830 for this we can use a serverless technology 35 00:01:21,830 --> 00:01:23,380 such as Amazon Cognito. 36 00:01:23,380 --> 00:01:25,600 So our mobile client can connect and authenticate 37 00:01:25,600 --> 00:01:28,900 to Cognito and then API Gateway along the way 38 00:01:28,900 --> 00:01:31,540 will verify the authentication with Cognito. 39 00:01:31,540 --> 00:01:35,200 So that gives us a very classic serverless API 40 00:01:35,200 --> 00:01:36,620 that we've just created here. 41 00:01:36,620 --> 00:01:39,360 Nothing new for you here, but it's good to see again. 42 00:01:39,360 --> 00:01:43,620 Now if you want to give a user's access to Amazon S3 Locate, 43 00:01:43,620 --> 00:01:44,720 how do we do this? 44 00:01:44,720 --> 00:01:46,920 Well, we have our mobile clients, 45 00:01:46,920 --> 00:01:49,030 that authenticates to Amazon Cognito, 46 00:01:49,030 --> 00:01:52,450 and Cognito that can generate temporary credentials for us 47 00:01:52,450 --> 00:01:55,184 using AWS STS and return these credentials 48 00:01:55,184 --> 00:01:57,010 to our mobile client. 49 00:01:57,010 --> 00:01:59,340 These credentials allow our mobile client 50 00:01:59,340 --> 00:02:01,820 to store and retrieve files in Amazon S3, 51 00:02:01,820 --> 00:02:06,630 and basically access their own little space in S3. 52 00:02:06,630 --> 00:02:08,960 So this is a very classic question as well, 53 00:02:08,960 --> 00:02:11,560 how to do this and the wrong answer is 54 00:02:11,560 --> 00:02:15,410 to store AWS user credentials on your mobile clients. 55 00:02:15,410 --> 00:02:17,320 You definitely do not want to do this. 56 00:02:17,320 --> 00:02:20,247 What you want to do is really use Amazon Cognito, STS, 57 00:02:20,247 --> 00:02:23,330 and then Amazon S3 with temporary credentials. 58 00:02:23,330 --> 00:02:25,900 Okay, so it's a very common question. 59 00:02:25,900 --> 00:02:27,650 So next our app is starting to scale. 60 00:02:27,650 --> 00:02:29,650 We're starting to get more users and it turns out 61 00:02:29,650 --> 00:02:31,380 that we, by looking at the patterns, 62 00:02:31,380 --> 00:02:34,290 figure out that we have a very high read throughput, 63 00:02:34,290 --> 00:02:36,140 so we have many RCUs 64 00:02:36,140 --> 00:02:37,850 and the to-dos don't really change much, 65 00:02:37,850 --> 00:02:39,790 they don't get edited very often. 66 00:02:39,790 --> 00:02:41,496 So how can we change this architecture, 67 00:02:41,496 --> 00:02:44,962 to basically improve the read throughput 68 00:02:44,962 --> 00:02:47,890 and decrease maybe the cost overall? 69 00:02:47,890 --> 00:02:50,220 What we can do is use DAX as a caching layer, 70 00:02:50,220 --> 00:02:52,821 so just before DynamoDB, we'll use DynamoDB DAX 71 00:02:52,821 --> 00:02:55,680 and this will basically have a caching layer 72 00:02:55,680 --> 00:02:56,943 and because we're doing so many reads, 73 00:02:56,943 --> 00:02:58,990 now the reads will be cached in DAX, 74 00:02:58,990 --> 00:03:02,900 and so DynamoDB won't need as much read capacity units, 75 00:03:02,900 --> 00:03:03,930 maybe will scale better, 76 00:03:03,930 --> 00:03:05,490 maybe will have less cause over all 77 00:03:05,490 --> 00:03:07,980 because so many reads are cached and this is a great way, 78 00:03:07,980 --> 00:03:09,974 overall, to keep on improving our architecture 79 00:03:09,974 --> 00:03:12,520 in a serverless fashion. 80 00:03:12,520 --> 00:03:14,182 Now there could be another way of doing caching, 81 00:03:14,182 --> 00:03:16,890 maybe you want to use DAX, but maybe also we want 82 00:03:16,890 --> 00:03:18,505 to start caching the responses 83 00:03:18,505 --> 00:03:20,750 at the Amazon API Gateway level. 84 00:03:20,750 --> 00:03:22,590 This is also something we can do. 85 00:03:22,590 --> 00:03:25,070 And this is also a very good one if you think 86 00:03:25,070 --> 00:03:26,517 that the answers never really change, 87 00:03:26,517 --> 00:03:28,664 and that you can start caching a few responses 88 00:03:28,664 --> 00:03:30,750 for some few API routes. 89 00:03:30,750 --> 00:03:32,870 So over all, really interesting to see this kind 90 00:03:32,870 --> 00:03:35,170 of architectures because they really show you 91 00:03:35,170 --> 00:03:38,310 how serverless is done, where the caching appears, 92 00:03:38,310 --> 00:03:41,380 and in this architecture nothing is managed by us, 93 00:03:41,380 --> 00:03:43,980 we really pay per usage and we really don't think 94 00:03:43,980 --> 00:03:45,820 about management of databases. 95 00:03:45,820 --> 00:03:48,020 All these things is done by AWS for us. 96 00:03:48,020 --> 00:03:49,040 So, in this lecture, 97 00:03:49,040 --> 00:03:52,100 we've seen the classic serverless REST API architecture, 98 00:03:52,100 --> 00:03:55,510 basically leveraging HTTPS, API Gateway, Lambda 99 00:03:55,510 --> 00:03:56,760 and DynamoDB. 100 00:03:56,760 --> 00:03:58,500 And then we've used Cognito 101 00:03:58,500 --> 00:04:01,062 to generate temporary credentials with STS 102 00:04:01,062 --> 00:04:03,114 which gives us access to an extra bucket 103 00:04:03,114 --> 00:04:04,660 with a restricted policy. 104 00:04:04,660 --> 00:04:08,492 We can use the exact same app pattern using Cognito, 105 00:04:08,492 --> 00:04:11,950 so our app can access maybe DynamoDB 106 00:04:11,950 --> 00:04:13,800 or Lambda directly or whatever. 107 00:04:13,800 --> 00:04:15,670 This is a very common pattern. 108 00:04:15,670 --> 00:04:18,802 Now caching the reads on DynamoDB can be done using DAX, 109 00:04:18,802 --> 00:04:21,519 its a very easy way to enable and you can bring 110 00:04:21,519 --> 00:04:24,930 not only performance improvement, but also cost reduction, 111 00:04:24,930 --> 00:04:27,350 and caching the REST request can be done at 112 00:04:27,350 --> 00:04:31,370 the API Gateway level, if we have very static responses. 113 00:04:31,370 --> 00:04:33,327 Security, finally, for the entire thing 114 00:04:33,327 --> 00:04:36,901 can be done with Cognito, and Cognito is directly integrated 115 00:04:36,901 --> 00:04:38,720 with the API Gateway. 116 00:04:38,720 --> 00:04:40,140 So this was a very basic example, 117 00:04:40,140 --> 00:04:42,110 but it gives us a start basically 118 00:04:42,110 --> 00:04:44,160 on serverless architectures and shows us 119 00:04:44,160 --> 00:04:45,912 all the different components we've seen in the past section. 120 00:04:45,912 --> 00:04:49,123 So I hope that helps and I will see you in the next lecture.