Executing code in response to specific event triggers is a common need. In fact, Event-Driven Programming has long been an important approach in Software Development. So if trigger response is useful within an operating system, why not for cloud-based web applications? To answer precisely that need, Amazon recently released Lambda. Lambda will launch AWS resources and execute snippets of code in response to predefined events, automating the management of all of necessary underlying infrastructure...and at a ridiculously low price.
In this course you'll get complete introduction to AWS Lambda. Lambda is not a particularly complex service, but setting IAM roles and security groups might be tricky. This tutorial, written by our expert Cloud Solutions Architect Kevin Felichko, will help you understand how to get started, and will also show you an interesting and practical use-case.
Who should take this course
If you want to learn more about the AWS services being discussed here, check out our other AWS courses. Also, our Lambda quiz questions can serve as a nice follow up. You will be tested on what you learnt in this video, but will also learn more at the same time thanks to the documentation associated with each question.
Do you have questions on this course? Contact our cloud experts in our community forum.
Welcome to the CloudAcademy course on AWS Lambda. Lambda was introduced at the 2014 re:Invent Conference, and made available in preview mode to customers upon request. This course with detail what Lambda is, when it makes sense to use it, how we can use it, and metrics around monitoring our functions. What exactly is Lambda? Simply put, Lambda is a compute service that executes code. Instead of needing to provision an EC2 instance and getting it configured to run a few functions, we can upload just the code we want to execute. We can tie the execution to various Events, such as S3 file creation and Kinesis streams. At the time of this recording, the service is still in preview mode, meaning it has limitations.
For example, it only supports Node.js, it only responds to a few Events. Knowing how quickly AWS rolls out functionality, we can expect newer languages and more Events in the future. There are many reasons to consider using Lambda: it is very easy to deploy and administer functions, we don't have to worry about selecting and configuring the proper EC2 instances to run our code. Lambda helps us achieve scalable, high-available workloads right out of the box. As with all AWS services, security is a shared responsibility. AWS does its part to ensure our code runs in its own sandbox, away from all other processes. We are responsible for protecting our keys that interact through the AWS STK. Best of all, Lambda helps keep costs down by charging us only for the execution of our workloads, and not for idle resources like we do when using EC2. Like most services, AWS has a free tier for Lambda that is applied to both new and existing accounts. The free tier covers the first million requests, and up to 3.2 million seconds per month. That is a lot of processing that can be done before we get charged anything.
The number of seconds per month is dependent on the amount of memory we allocate for our code to run. 3.2 million is on the high end, using the lowest memory setting of 128MB. At the max memory of 1GB, the free tier allows 400,000 seconds per month before charging us. Once we exceed the first million requests, we are charged $0.20 for each additional batch of 1,000,000 requests. If we exceed our execution time, we are charged per 100 milliseconds of execution, with the amount determined, again, by the memory allocation for our function. These are charged at fractions of fractions of pennies per 100 milliseconds, very compelling pricing for many workloads.
Lambda is not designed for all workloads, some are better suited than others. Code that does not require human interaction is a prime example. That does not mean we cannot use it as part of a larger system.
This is something we will demonstrate in lesson three with our sample application. Functions should be independent of other functions, meaning we don't want to have it sitting around waiting for other functions to complete. That will waste execution time, and most likely exceed mandatory time-out settings. Our functions cannot be dependent on the underlying physical resources, as there's no guarantee it will be consistent across all executions. That means we cannot rely on state between executions, unless we are storing that state with other services such as DynamoDB or S3. Lambda also makes sense when we have no desire to manage compute resources. Now that we understand what Lambda is, let's turn our attention to how Lambda works.
Kevin is a seasoned technologist with 15+ years experience mostly in software development.Recently, he has led several migrations from traditional data centers to AWS resulting in over $100K a year in savings. His new projects take advantage of cloud computing from the start which enables a faster time to market.
He enjoys sharing his experience and knowledge with others while constantly learning new things. He has been building elegant, high-performing software across many industries since high school. He currently writes apps in node.js and iOS apps in Objective C and designs complex architectures for AWS deployments.
Kevin currently serves as Chief Technology Officer for PropertyRoom.com, where he leads a small, agile team.