1 00:00:00,690 --> 00:00:05,250 In this video, we are going to see how to recruit our lambda functions. 2 00:00:05,280 --> 00:00:09,150 That means you will see a Lambda Invocation types. 3 00:00:10,470 --> 00:00:15,000 So this lambda function is using a river for various use cases. 4 00:00:15,030 --> 00:00:23,130 Sometimes we want to invoke lambda function over HTTP and other times trigger a function based on different 5 00:00:23,130 --> 00:00:23,820 events. 6 00:00:24,730 --> 00:00:30,550 It is extremely useful to understand the different ways that we can invoke lambda function. 7 00:00:31,270 --> 00:00:35,170 Here are three different ways we can invoke lambda functions. 8 00:00:35,830 --> 00:00:39,730 You can see in here a double is Lambda has three invocation types. 9 00:00:40,180 --> 00:00:42,310 Lambda Synchronous Invocation. 10 00:00:42,310 --> 00:00:44,530 Lambda Asynchronous Invocation. 11 00:00:44,620 --> 00:00:48,400 Lambda Event Source Mapping with Pulling Invocation. 12 00:00:50,130 --> 00:00:53,760 So you can all see in location types in one image. 13 00:00:53,910 --> 00:01:00,100 Synchronous invocation is triggered by push model and execute immediately and wait response. 14 00:01:00,120 --> 00:01:02,730 We can say request response model. 15 00:01:03,640 --> 00:01:08,210 Asynchronous invocation is triggered by event model and executes. 16 00:01:08,230 --> 00:01:09,130 Asynchronous. 17 00:01:09,160 --> 00:01:09,930 Don't wait. 18 00:01:09,940 --> 00:01:11,260 Immediate response. 19 00:01:11,890 --> 00:01:15,400 Event source mapping invocation is triggered by pol based. 20 00:01:15,430 --> 00:01:19,030 That means lambda function receive multiple items. 21 00:01:20,660 --> 00:01:24,950 So let's see one by one and explain these types. 22 00:01:25,610 --> 00:01:27,890 Lambda Synchronous invocation. 23 00:01:28,070 --> 00:01:32,630 This is one of the simple Lambda Invocation model in this communication type. 24 00:01:32,660 --> 00:01:38,720 Lambda functions execute immediately when you perform the Lambda Invoke by API call. 25 00:01:38,930 --> 00:01:46,130 So when we perform a Lambda Invoke an API call, we wait for the function to process the function and 26 00:01:46,130 --> 00:01:47,750 return back to the response. 27 00:01:48,200 --> 00:01:53,720 The response data includes the function response and additional data which can be retrieved from the 28 00:01:53,720 --> 00:01:56,660 Dynamo DB or some other resources. 29 00:01:56,840 --> 00:01:59,030 But the idea is we should wait. 30 00:01:59,060 --> 00:02:01,580 A response from the synchronous invocation. 31 00:02:03,220 --> 00:02:10,240 A common scenario for synchronous invocation is the API gateway, Lambda and Dynamo DB integration. 32 00:02:10,360 --> 00:02:16,030 You can see in the Image API, Gateway, Lambda and Dynamo DB that we can perform CRUD operation for 33 00:02:16,030 --> 00:02:21,040 a particular Dynamo DB table with exposing APIs from the API gateway. 34 00:02:22,010 --> 00:02:27,890 The important thing is in here, the invocation type flag should be request response. 35 00:02:28,610 --> 00:02:35,150 This instructs a place to execute our lambda function and wait for the response of function to complete. 36 00:02:35,780 --> 00:02:42,710 When we perform the synchronous invocation, we are responsible for inspecting the response and determining 37 00:02:42,710 --> 00:02:47,540 if there was an error lifetime of execution and decide to retry invocation. 38 00:02:48,460 --> 00:02:55,570 We can perform synchronous requests most in location using a double CLI SDK and many other options. 39 00:02:56,530 --> 00:03:00,610 You can see an example of synchronous invocation using a double click. 40 00:03:01,120 --> 00:03:06,550 See that we are running the lambda invoke comments on CLI. 41 00:03:06,940 --> 00:03:13,360 As you can see that when we specify the invocation type LIC is request response, that means it will 42 00:03:13,600 --> 00:03:19,900 execute our function and wait for the function response in order to complete and return response. 43 00:03:20,320 --> 00:03:26,530 The important part is we are responsible for checking the request, checking the response and determining 44 00:03:26,530 --> 00:03:29,410 whether it is an error or we should try the invoke. 45 00:03:29,680 --> 00:03:35,560 So in this synchronous invocation, we are waiting response and according to this response, we are 46 00:03:35,560 --> 00:03:40,450 checking the response data and it is looking for it is getting error or not. 47 00:03:40,450 --> 00:03:44,410 If it is getting error, we are going to retry the invoke again. 48 00:03:46,150 --> 00:03:51,400 There are many services that can trigger lambda function synchronously here. 49 00:03:51,400 --> 00:03:52,690 Some of them in here. 50 00:03:52,690 --> 00:03:59,170 You can see that application load will answer Amazon Incognito, Amazon, lakes, Alexa API, Gateway 51 00:03:59,170 --> 00:04:03,040 Cloud, Front Kinesis Data streams and so on. 52 00:04:05,510 --> 00:04:10,370 So now the second invocation type is Lambda Asynchronous invocation. 53 00:04:10,910 --> 00:04:17,060 In this communication type, Lambda function works with the events and invoke by events and not respond 54 00:04:17,060 --> 00:04:17,990 immediately. 55 00:04:18,650 --> 00:04:22,430 Basically, we can invoke a lot of function asynchronously. 56 00:04:22,580 --> 00:04:30,530 After that, Lambda sends the event an internal queue and returns a success response without any additional 57 00:04:30,530 --> 00:04:31,400 information. 58 00:04:31,970 --> 00:04:38,660 After that, a separate process reads the events from the queue and runs our lambda function. 59 00:04:39,610 --> 00:04:46,510 So you can see a common scenario for asynchronous invocation is the S3 Lambda and Dynamo. 60 00:04:46,520 --> 00:04:58,060 DB You can see in the Image HD or Amazon sense a sense trigger an event and this will be triggered the 61 00:04:58,600 --> 00:05:01,900 lambda asynchronously and it will extend to interact with the dynamo. 62 00:05:01,900 --> 00:05:09,790 DB In the diagram, Amazon S3 will call the Lambda Asynchronous when a new object is written into the 63 00:05:09,790 --> 00:05:10,450 bucket. 64 00:05:11,080 --> 00:05:15,400 Amazon S3 has several events that can trigger to a lambda. 65 00:05:15,520 --> 00:05:21,340 For example, we can set that a new object is uploading to the bucket. 66 00:05:21,340 --> 00:05:26,710 We can trigger an event today lambda that is execute lambda function asynchronously. 67 00:05:28,240 --> 00:05:33,760 In order to invoke a function asynchronously, we should set the invocation type parameter to event. 68 00:05:34,090 --> 00:05:41,710 So it is very important you can see an example of the asynchronous invokes using the SLA. 69 00:05:42,160 --> 00:05:48,310 We can see that we are running a double lambda invoke comment and the invocation type is event one. 70 00:05:48,310 --> 00:05:52,270 We specify the invocation type parameter value as event. 71 00:05:52,510 --> 00:05:58,360 If the function failed, the bullets will automatically retry the invoke device because in asynchronous 72 00:05:58,360 --> 00:06:06,760 communication the lambda is automatically triggered by the triggered invoke by twice when there is an 73 00:06:06,760 --> 00:06:08,920 error by default. 74 00:06:08,920 --> 00:06:12,700 A double is lambda sets a retry policy for asynchronous invocations. 75 00:06:12,700 --> 00:06:18,790 Your function will be invoked twice if there is an error in order to avoid event losses. 76 00:06:18,790 --> 00:06:25,930 When using asynchronous lambda, always attach a dead letter Q on the function in order to save events 77 00:06:25,930 --> 00:06:28,000 that weren't successfully processed. 78 00:06:28,970 --> 00:06:35,810 Here you can list of the services that invoke Lambda function asynchronously as you set that Amazon 79 00:06:35,810 --> 00:06:43,820 S3, Evan SAS is cloud formation, cloud watch logs and events called cosmic pull based invokes and 80 00:06:43,820 --> 00:06:44,360 so on. 81 00:06:46,580 --> 00:06:52,610 So if you come to the last location type, which is the event source mapping with polling location, 82 00:06:53,210 --> 00:06:59,810 this is the poll based location model allows us to integrate with the bullets, streams and queue based 83 00:06:59,810 --> 00:07:00,680 services. 84 00:07:01,370 --> 00:07:05,330 These services don't invoke a lambda function directly. 85 00:07:05,960 --> 00:07:14,660 Lambda will pull from the ASCs or kinesis streams, retrieve records and invoke the functions. 86 00:07:15,650 --> 00:07:22,130 A.W. Islam the event source mapping manage the polar and performs the synchronous inverse of our function. 87 00:07:22,880 --> 00:07:26,600 Data streams or cues are read in the batch. 88 00:07:26,900 --> 00:07:33,410 The function receives multiple items when executing to function, so a batch size can configure according 89 00:07:33,410 --> 00:07:34,610 to the service type. 90 00:07:34,610 --> 00:07:39,200 And after that, the event source mapping will send data according to batch size. 91 00:07:39,680 --> 00:07:47,120 If the batch size is too large to send in one event, it has to be split up, resulting in events with 92 00:07:47,120 --> 00:07:49,910 smaller number of items than the batch size. 93 00:07:51,090 --> 00:07:57,240 So you can see in the image a common scenario for event source mapping with polling location is the 94 00:07:57,570 --> 00:08:04,920 squares and a place lambda you can see in the image almost on squares and lambda using the event source 95 00:08:04,920 --> 00:08:11,460 mapping basically lambda function pulling events from the a base case. 96 00:08:11,550 --> 00:08:15,450 Let me explain more clearly in this diagram. 97 00:08:15,450 --> 00:08:18,170 Amazon has some key records. 98 00:08:18,180 --> 00:08:23,760 These records can be added from other services like event, SMS and so on. 99 00:08:23,760 --> 00:08:29,640 So the idea is that we have some queue message in the Amazon queue. 100 00:08:30,270 --> 00:08:39,030 After that, a lambda function, pull the events from the Amazon case and receive Q records with event 101 00:08:39,030 --> 00:08:40,590 source mapping invocation. 102 00:08:40,920 --> 00:08:47,580 So lambda function retrieve queue records according to the batch size property of polling configuration. 103 00:08:48,380 --> 00:08:54,440 Another common scenario for my source mapping with polling location is stream based processing. 104 00:08:54,800 --> 00:09:01,610 These are the Kinesis and Dynamo DB streams that can lambda pull the stream records with one source 105 00:09:01,610 --> 00:09:03,020 mapping in locations. 106 00:09:04,010 --> 00:09:06,500 So the base size property is very important. 107 00:09:06,500 --> 00:09:13,310 We give the example of the x and lambda and we said that the stream based processing dynamo DB streams 108 00:09:13,310 --> 00:09:18,560 and kindnesses streams using the event based event source mapping location. 109 00:09:18,770 --> 00:09:24,770 And here is the list of the services that invoke Lambda functions as an event source mapping. 110 00:09:24,800 --> 00:09:30,740 These are the Amazon Kinesis, Amazon Dynamo, DB, and Amazon simple queue services. 111 00:09:32,630 --> 00:09:37,400 As you can see that we have seen several ADA Lambda Invocation types.