Best practices for building interactive applications with AWS Lambda - AWS Online Tech Talks

Key Takeaways

foreign [Music] this is best practices for building interactive applications with AWS Lambda my name is Ben Smith and I'm a principal developer advocate for serverless here at AWS and before joining AWS I was a web developer for about 15 years working mostly with PHP so that'll give you a little bit of an insight into some of the types of applications I'm going to talk about over the next 30 minutes or so I want to cover I want to talk about what do I mean when I say an interactive application on Lambda and in order to understand that I'm going to talk a little bit about the difference between synchronous and asynchronous and what happens when you invoke Lambda synchronously and asynchronously I'll spend a lot of time talking about accessing business logic within your serverless applications that means really accessing your Lambda function code and we'll talk a little bit about how you can optimize that as well so today's focus is lambda-based applications but more specifically interactive Lambda applications so for the purposes of this talk that is anything where you'll Lambda function is invoked using an HTTP request and send back an HTTP response and so this is a synchronous Lambda invocation what do I mean by synchronous and asynchronous okay so here's an example of a synchronous command where a client sends out a kind of invoking command to service a service a will receive that it might invoke something else Downstream to service B and wait to hear back from service B and then when it's received that information back from service b or finish processing and send the result back to the client whereas the same workload run in an asynchronous mode will look more like this right the client will send a request to service a service a will send back an acknowledgment that it's got the request and then the process will continue on Downstream asynchronously and the key difference here is represented by this pink line this is uh blocking time right this is how long the client is waiting to hear back from that service a before it can move on to the next procedure so that in a nutshell is kind of the difference between synchronous and asynchronous now you can invoke a Lambda function synchronously or asynchronously there's also other types of invocations such as Event Source mapping but I won't go into them and in any detail in this particular talk so when you invoke a Lambda function synchronously it's basically when you expect a response from your Lambda function okay and when you invoke it asynchronously you're not expecting a response you're just expecting to get an acknowledgment that your Lambda function has received that invocation request and you can understand why that happens and how that works by taking a little peek under the hood inside your Lambda function execution environment right here's a really high level representation of what that looks like so when you invoke a Lambda function synchronously using something like API Gateway what actually happens is that request gets proxy done to something called the Lambda front end API now this is completely obfuscated to you the user okay it's all happening within the Lambda environment so that front end API will then find an available execution environment or send a request on to the service to find that execution environment and spin one up if there's not one available it will then run your code and return you back the response now this is useful if you need an immediate response from your Lambda function code and it's also useful if you need to see what the errors are from your Lambda function code right and it also throttles when you hit a concurrency limit now in contrast to that if I vote Lambda asynchronously using something like eventbridge for example it still goes through that front end API but that request is then actually put onto an internal cue and it will stay onto that internal queue for up to six hours and Lander takes that invocation off the queue when it's ready to process that for you now if Lambda for some reason if your function isn't able to run it will put that message back onto the Q and it will retry up to two times so that's three invokes in total and then you can forward that error off to a dead letter queue if you so wish but that's the difference is actually a whole other component called this internal cue that sits inside the Lambda service and that's how we are able to do this asynchronous invocation for you so how do you choose between running your Lambda function or invoking your Lambda function synchronously or asynchronously well I think there's one simple rule to follow really is that do you want to have to wait for a result and in many applications you will need to wait for that result and in many applications you actually won't so if you do need that response or that result from your Lambda function then that's your synchronous invocation if you don't that's your asynchronous invocation now it's probably worth mentioning that asynchronous Lambda invocation can still kick off multiple other asynchronous backend uh workloads so for example I can invoke my Lambda function synchronously using something like API Gateway and that Lambda function might then send a message on to an external service such as slack or it might invoke a step functions workflow and not hang around to hear the response back from that workflow it might put something on an S3 bucket without waiting to see the result so you can mix and merge these different workload types of course now interactive Lambda functions can fall an interactive Lambda function application can be many different types of application right some of which are listed here these are various use cases that we see customers building out interactive Lambda applications connecting different applications together using Lambda as kind of blue code between two external Services extending an exit an existing on-premise application may be you can use Lambda as I mentioned to kick off asynchronous workloads it's great for machine learning inferencing for backend applications data processing chat Bots it automation Alexa skills the list is almost endless to be honest I'm going to focus on this first example because I think this is a really nice simple straightforward way of using a Lambda for an interactive application so here's a little application that I've built that allows you to Ping a slack Channel when there is a new like on a GitHub repository and it's actually a whole blog post around this that takes you through walks you through how to build this yourself from start to finish the link is available here so what this does is whenever someone puts a star on a GitHub repository that I've applied this application to that will then create this message in a slack channel for me that looks something like this and it says hey there's a new GitHub star on your repository and this now has 10 stars and it tells me who made the star in GitHub here is that application in motion just really quickly so on the left hand side here is my slack Channel and on the right is my GitHub repository and you can see I click here on the star in my GitHub repository and but a couple seconds later that shot a message straight in to my slack channel to let me know that someone's interacting with my GitHub repo okay what happened there let's have a look at it so first of all there is some business logic business logic is Loosely termed as doing something to some data some input to produce some kind of a valuable result so where's the business logic in this little example here well GitHub is sending an input to my process which is my Lambda function which is sending an output on to slack right so the business logic is my Lambda function the input payload is sent by the web hook mechanism of GitHub okay and here's a subset of that it contains things like the name of the repository the number of people that are currently uh clicked on the star icon and who did the actual action and this is all sent in from GitHub using the GitHub webhook mechanism to access that event object in my actual business logic so I'm zooming into my Lambda function code here I have something called the event object so in the inside the event object I can access all those different variables by using a key value pair right so I am constructing my business logic using that event object and I'm making a new Json object called message which contains information that I'm going to post to my slack Channel and I'm pulling out of that input payload that event object useful information from GitHub so I still have my input my process and my output these things don't change when you're building with Lambda finally I return the response so I return a 200 status code and the result of my response to GitHub now in the middle of that I'm using axios which is a JavaScript library for sending out HTTP requests to post out of my Lambda function environment into the slack API to send a message to slack to say that there's a new item a new star on my GitHub repository now here's the missing piece in all of that how did the input payload get from GitHub to my Lambda function I had to open up my Lambda function code to GitHub in some way right and I used API Gateway in this initial example so I simply provided the GitHub webhook mechanism API Gateway generated UL URL to access my function code and this is a common thing common way we see people building out interactive Lambda applications now customers were looking for other ways to kind of access that business logic inside their Lambda function maybe you don't need some of the additional features that API Gateway offers you you just want to invoke your function code as quickly and as simply as possible that's when we introduced something called AWS Lambda function URL so this is a fast simpler way of invoking your Lambda function code synchronously using an HTTP request and here's what a function URL looks like okay so it's https a uniquely generated URL ID dot Lambda Dash URL the region that you've created your function in dot on dot AWS and you can get more information about functioning URLs from this link available on the screen here now Lambda function URLs is part of the Lambda service and it's this new way of accessing your Lambda function code accessing that business logic it's its separate cloud formation resource and it generates this unique URL to invoke Lambda and you can even point it to the latest or to a user-defined Alias so because this is part of the Lambda service this simplifies my little application here I now no longer need to invoke Lambda using API Gateway in this particular simple instance I can go directly from GitHub via a function URL to my Lambda code and have my Lambda function code send out to Slack so let's have a little look about function URLs this is relatively new they've been out for about a year now you can create a function URL using the AWS Management console using the AWS CLI using an infrastructure as code template such as cdk Sam cloud formation terraformers multiple different ways now to invoke my Lambda function all I need to do is send an HTTP request to that function URL and of course I can do that from a browser window I can do that with a curl command or via Postman or even programmatically using the API now customers also want to make sure that their business code is not just out there on the Internet available to anyone to invoke so there are authentication options to secure your function code if you're using function urls now um they come secured as default with I am permission so you can use IAM to authorize requests to your function URL or you can optionally disable that completely and have that open if you want an open API URL and you can even roll your own authorization with code inside your Lambda function okay but you can also add cause configuration which I'll talk about in just a moment so if you want to apply I am authorization to your function URL you need to know about some of the new actions that are available so there's new actions for function URLs to be able to create a new function URL config to update your function URL to delete it to get information about it to list it and here's the key one here to invoke a function using function URLs this is what you have to Grant to an I am permission that you want to apply to enable to invoke Lambda user function URLs and here's an example of me using that in a in a real uh I am user now if you ever built web applications before you've almost certainly seen this error and if you've built applications using Lambda and API Gateway I'm sure you've seen this error at some point it's the dreaded cores error and um my friend Eric Johnson my good friend who's talking uh today I think uh he's once been quoted as saying if cores had a face I'd punch it in the nose and I'd be right behind him holding the holding it down Eric Johnson is a fantastic principal developer advocate for serverless he's built a lot of applications using Lambda an API Gateway and so he knows this is a common problem or a common error message that people get Now function URLs goes a long way to helping to resolve this it enables you to configure chords very simply right so you can do this by just adding a it adds a header for you automatically to your response or you can manually roll your own foreign some other things that you need to know right is how do you access paths how do you access methods and query stream parameters are these things that you can still use when uh working with function URLs and the answer is yes you can so let's take this as an input payload this is an HTTP request to invoke my function URL and here's all the payload as part of that request so let's say I wanted to access the path of this HTTP request well that would be inside this object or this key called raw payload so let's say I invoke my function URL with Slash Mountain slash Japan slash Hokkaido and then I want to access that path well I can access that via the event object that we looked at earlier it's just event dot raw path and then I get Mountain slash Japan Hokkaido I want to access the method well that's inside the HTTP dot method key so I can access that in the same way by doing http.method if I want to access parameters then that's inside the query stream parameters dot mounting key okay and I can access that from my event object as well just like this another thing that Lambda function URLs does is it infers a response format for you so if your function returns Json or no status code then function URLs will refer the status code 200 it will refer the infer the content type as application Json and it will send that along with the function body response it'll look like this right so here's a typical response payload all I've returned from my function code here is the string hello world but what actually gets returned in the Lambda response is a status code hello worldstring gets put inside a body key and then it returns headers and base64 encoded files as well so it enables you to kind of nicely standardize those responses now if you want to make your own custom response you can do that quite simply by adding your own status code so here I add a status code of 201 and then it returns exactly the response that I've set it to return we also have new ways of monitoring your function URLs of course so you're able to monitor things like the 4X 5x and URL latency and you can also monitor the request count as well now here's some interesting points to bear in mind if you want to start building with function URLs there is a six megabyte response and request payload size limit it defaults to 1000 and goes all the way up to 10 000 TPS and it has a 15 minute timeout so what that means is you can now access your Lambda function code with no additional cost because function URLs has no additional cost associated with it no additional timeout limit because it can run function URLs have a limit of 15 minutes same as Lambda okay so it doesn't add any limits to you there and no additional payload limits because that's also in line with Lambda or this is because function URLs is part of the Lambda service itself it's not a separate service with its own limits so going back to my different use cases this was my favorite simple use case for an interactive Lambda function just as a kind of simple web hook mechanism to connect one application to another and now with function URLs I can do that without much complexity at all I can also use something like the fan out request response model where I can send in an invocation to Lambda using function URLs send an acknowledgment back of that request and then send that Downstream to an SNS topic which allows me to Fan out to multiple other Lambda functions so this would enable me to do something like resize an image concurrently to multiple different sizes I can do something like high volume data ingestion where again I invoke my Lambda function asynchronously using my function URL I can send errant responses to a dead letter queue and then send everything out on to Amazon Kinesis where I can use that as my data ingestion point I can use it for machine learning inferencing in a synchronous mode so I can invoke Lambda have Lambda grab down some ml models and Frameworks run that against my input payload and return the response because Lambda function URLs remember can run for up to 15 minutes also it's an ideal use case for web applications and web Frameworks right I can now invoke my Lambda function directly so what that means is I can root everything directly to Lambda and inside my Lambda function I can have my router.php or my router.js to root off to the correct script right and I can now do all of that inside of Lambda without an additional service I can even put it behind a cloudfront service a CDN so I can cache data static data at points nearer to my user for a more responsive experience and I can go further by adding rules in cloudfront that say if it's uh if the request is looking for a static asset such as images or css files then I can go directly to S3 and Object Store to attain that whereas if my request needing some computational logic then I can go ahead and invoke my Lambda function so thereby I'm kind of decreasing the amount of times that I need to invoke Lambda Lambda is optimized for running compute okay so if you need to access a resource that is static that doesn't require compute there's other services that are better kind of positioned to do that for you right and of course S3 is one of those services now I don't want to leave out other synchronous ways of invoking your Lambda functions they still absolutely have value so let's have a look at other ways that I can access that business logic synchronously to create interactive Lambda based applications so the first one I want to look at is Amazon API Gateway so this is using rest apis the next is application load balancer and I want to compare them a little bit to function urls so we have this service called application load balancer or ALB and this allows you to create groups which are essentially collections of resources now these resources could be ec2 instances or they could be Lambda functions and what you are then able to do is to create a listener to Define which of those groups are mapped to each request and you can also run health checks on each one of those groups to make sure that they are still serving your function code so here's what that looks like right you can set up listeners that will root those requests according to Port protocol and path so you can root anything coming in on HTTP 80 to go to your ec2 instances in group one you could root anything that is slash order for an additional micro service that you might be building out to go directly to a Lambda function in group two so what ALB allows you to do is to start kind of slicing Away part of your application that might be in a pre-existing ec2 instances and build out new kind of um micro services such as apis or small arts microservices in a Lambda function and you can root them effectively to both of those different group types using application load balancer okay then we have Amazon API Gateway now this is a huge service very mature service which has entire talks dedicated to it but I'm just going to touch on some of the key uh differentiators really with function URLs so this allows you to create both rest and websocket apis so there's already a point of difference there it supports something called vtl velocity template mapping which allows you to invoke or to access other services directly from API Gateway without any code in between okay it's just velocity template language in between which allows you to kind of remap the request as it comes into API Gateway before it gets passed on to the next service API Gateway also supports parameter and payload validation before invoking the next service and it has multiple different authorization options so it's not just limited to I am you have lots of other ways of authorizing your request using Amazon API Gateway so here's an example of a serverless application that uses API Gateway where you have API Gateway with Native Integrations to things like dynamodb and AWS step functions and then other requests going directly to a Lambda function for that synchronous response mode so here's a comparison of all of these together okay with API Gateway I can not run HTTP requests it's https only with load balancer I actually can run HTTP requests into that function URLs is also https only so there's an interesting point of difference for application load balancer in terms of authorization and authentication well function URLs gives me I am authorization and I can roll my own in code using the Sig V4 sign request whereas API Gateway I have multiple different ways of authenticating application load balancer I don't have those same options in terms of payload limit when used with Lambda they're all the same because the kind of defaults to the Lambda payload limit the maximum timeout is perhaps the most important point of difference here okay so with API Gateway requests will time out after 29 seconds whereas with application load balancer and with function URLs you have that 15 minutes okay so you can serve up data that takes more time to process stuff like machine learning inferencing there's also a really interesting mode in API Gateway that allows you to generate an SDK from your API now in terms of cost this is another big point of differentiation okay function URLs is free to use you still pay for the invocation of Lambda but you don't pay to access that Lambda function whereas application load balancer runs on an hourly plus capacity unit so it's not completely serverless if you're a real purist in that sense and API Gateway has its own billing model as well which is based on how many requests you use essentially uh final point of difference is the API Gateway and application load balance will work with AWS whereas function URLs does not so here's my kind of summary for you if you like I would say use API Gateway for the direct service Integrations to reduce code because you can add that routine logic into API Gateway and not in your function code you can build both rest and websocket apis and you have additional security that you're able to permit around accessing your business logic application load balancer on the other hand is ideal for hybrid applications that might use Lambda and ec2 and for migrating between those Services it's a really good option function URLs is great for getting started with serverless getting started with Lambda ideal for simple invocations of Lambda things like web applications and because of that different cost model and that 15 minute timeout it's great for longer running workloads so just to recap we talked about function URLs this new simple way of synchronously invoking Lambda functions from an HTTP request we've talked about the difference between asynchronous and synchronous invocation models now I would say as a default to use an asynchronous invocation if you don't need that that immediate response from your Lambda functions serverless seems to work fantastically well with asynchronous and an asynchronous mode where you will submit a request receive an acknowledgment and then grab the result of that request later on when it's ready um we didn't touch on this too much but when you want to optimize your Lambda function it's best to initialize any resources that you're going to use above the function Handler code and try and minimize the deployment package size of your overall Lambda function to help you get some sort of performance optimizations there as well thank you so much for listening to this talk please do go and dig into some of those further reading resources that I've posted throughout the talk and I thank you for your time [Music] [Music] thank you