All-in-one serverless DevOps platform.
Full-stack visibility across the entire stack.
Detect and resolve incidents in record time.
Conform to industry best practices.
Welcome to the Serverless world. One of the first things you’ll hear about is AWS Lambda – and you’ll continue to keep hearing about it! While architecture can be serverless without Lambdas involved, it’s very often the key component within a serverless application. In the first post of this 3-part AWS Lambda Handbook series, we run through what is AWS Lambda, dialling back to basics with the various terminology, how to create a Lambda function and how to run it.
Read part 2 and part 3 of this handbook.
AWS Lambda is an event-driven serverless compute platform, spinning up the service in response to an event – find out more about Lambda triggers in part 1 and part 2 of our Complete Guide to Lambda Triggers series. Your code simply sits there as a file while AWS keeps a lookout for the trigger event you’ve set. When that event occurs, your code is executed and the required operations are carried out. It’s deemed ‘serverless’ because the server doesn’t exist until the user goes out to look for it – this is the epitome of Function-as-a-Service (FaaS).
Another bonus to Lambda is it’s auto-scalability managed by AWS, meaning you don’t need to think about infrastructure. The service will automatically accommodate growing needs and likewise, will scale down to conserve resources. All of this makes AWS Lambda a great solution to reduce waste of resources and budget.
Serverless Best Practices handbook
Before getting into how to set up and configure Lambda, below are definitions and terminology commonly used and spoken about.
Lambda Function: a group of related statements that perform a specific task in your application. It consists of code and any dependencies that are associated with it. Each Lambda function has its associated configuration information (name, description, entry point, and resource requirements).
The function itself has the following important aspects associated with it:
The triggers are shown to the left, and in this case, an API gateway trigger is active. The resources are shown on the right, which in this case, are CloudWatch Logs and DynamoDB.
Event Sources: an entity that publishes events. An event source can be an AWS service or developer-created application that produces events that trigger a function to run.
Invocation: an invocation is called up to execute a specific Lambda function. These are triggers for the code of the function to start running. Invocations can be either synchronous or asynchronous.
Event Source Mapping: a configuration of AWS services in which an event source is tied to a specific Lambda function. It enables automatic invocation of a Lambda function when specific events occur.
Lambda Execution Model: When you create a Lambda function, you can specify configuration information, such as the amount of memory and maximum execution time that you allow for your function. When that function is invoked, AWS Lambda launches an Execution Context based on the configuration settings you have provided.
Cold Starts: A cold start happens when a Lambda function is invoked after not being used for an extended period of time, which results in increased invocation latency (more on this later).
A Lambda function consists of the code and associated dependencies, and it also has configuration information within it. An API is also provided so you can update some of the configuration data. Lambda function configuration information comes with these critical elements:
Let’s create a simple Lambda function that is invoked by an API call, i.e. we generate a URL, which when entered in the browser would invoke the function. Our input would be passed into the function via this URL and the output would be returned and shown in the browser.
In the Lambda console panel, click on create function. Give your function a name, in our case, it is DemoFunction. Also select the runtime as Python3, as we will be using that particular language for this example. Lastly, give your function’s role a name and, from Policy Templates, select Simple Microservice permissions.
Click on Create Function and you will be taken to the next screen where you can provide the actual code. We are authoring this API from scratch, but there are tons of templates from Amazon repository that you can explore.
The next page will have an inline text editor with a simple python function in there. Replace that with the following content:
def lambda_handler(event, context):
firstName = event['first']
lastName = event['last']
return 'Greetings, ' + firstName + ' ' + lastName +'!'
The first line is for parsing the JSON using the JSON library in Python. The lambda_handler function gets the event as one of its parameters; this event brings along a set of data. The first and second line inside the function extracts whatever data is labelled first and second, and stores them into the respective variables.
The last line returns a message back and that’s what we will see in our browser.
We can add an API Gateway trigger right here, but for the sake of clarity, let’s do it separately. For now, we can click Save and move into the testing phase.
To test your function, just click on the top right corner where it says ‘TestEvent’, then click on Configure Test Event.
Here we will have our first encounter with a JSON payload. In the template TestEvent.
Replace the file’s content with the following lines:
Now that we have saved the test event. Click on Test in the previous menu. Upon successful execution you should see:
As mentioned before, our user would invoke the function by accessing a certain URL. To enable that go to the API Gateway Console under your AWS Services and click on Get Started or New API option.
Our API is named dashbird-api. After clicking on Create API. You will get the resources that the API has access to (listed in the next menu):
Since there are no resources, we just get a forward-slash. But you can create a new resource by using the Actions drop-down and picking Create Resource.
In the resource list, you can select this new resource (named greetings), click on Actions and select Create Method. Our HTTP request method is going to be a GET request since our aim is to get an appropriate response from invoking the function.
The method will have a Lambda integration option, select that and then enter the function name chosen by you earlier Step 2. Also, from Step 2’s screenshot, make note of the function’s ARN (top-right corner), it has the string eu-central-1 indicating the region it is in. Make sure that the same region is selected for the Lambda region also, as shown above. It would then ask permission for invoking the function; grant that and now we are ready for the final modification.
The GET method execution is explained in this diagram:
We still need to make sure that the input parameters are passed on correctly. For that, we need to modify the Integration Request stage from above. You can click on it to make modifications:
Leave everything as it is, except at the very bottom of the menu where you will find the Body Mapping Template here we get to describe our input template. The template is going to be of type application/json :
The dollar sign and the input.params() part act as a placeholder and helps us define the structure of a proper request. Now we can save our changes, and click on Actions and select Deploy API option. It will ask for a stage name; give it a suitable name (in our case it is called prod). All is set! We can now run this function in real-time.
The function can be invoked using a unique URL associated with it. In the API console, where we first selected Resources, select Stage submenu instead. Then drop down to greetings and then to the GET option.
It will give you an invoke URL, which you can click on for the function to run. However, on the first try, you might get an error message if you didn’t give any input. You can rectify this by modifying the URL like this:
Adding the last part to the URL would result in a successful execution of the function:
Of course, the above is just one example using one method, so when creating Lambda for your own application it’s important to remember the other options available.
In the next part of our AWS Lambda Handbook for Beginners series, we’ll be explaining AWS Lambda pricing, sharing some facts that you may not have known about and great use cases. Stay tuned!
Today we are excited to announce scheduled searches – a new feature on Dashbird that allows you to track any log event across your stack, turn it into time-series metric and also configure alert notifications based on it.
One of the most vital aspects to monitor is the metrics. You should know how your cluster performs and if it can keep up with the traffic. Learn more about monitoring Amazon OpenSearch Service.
Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.
End-to-end observability and real-time error tracking for AWS applications.