Serverless Implementation in AWS and the Serverless Framework

Learn the basics and structure of AWS Lambda functions and the Serverless Framework.

We'll cover the following

We'll use the Serverless Framework to assist in the deployment of our applications. It helps us quickly develop, deploy, and manage serverless applications with a range of serverless platforms (such as Azure Functions, Apache OpenWhisk, Google Cloud Functions, and Kubeless—to name a few).

Serverless is a popular and widely used open-source framework that offers multicloud deployment to package and deploy applications on multiple serverless services e.g., AWS, Azure and Google Cloud, etc. It supports multiple language options (for example, C#, F#, Go, Java, Kotlin, Node.js, PHP, Python, Ruby, Scala, and Swift), and it is extensible via plugins.

The basics

The Serverless Framework consists of an open-source CLI and a serverless dashboard. It helps us with end-to-end serverless application lifecycle management, which includes performance tracking, serverless CI/ CD configuration, and deployment. It uses AWS Lambda functions and AWS infrastructure resources.

The Serverless CLI provides structure and automation, letting us focus on building event-driven serverless architectures consisting of Functions and Events. It helps us manage our code as well as the infrastructure and supports multiple languages.

AWS Lambda function

A serverless application is deployed and executed using AWS Lambda functions. Each function is an independent unit of execution deployed in the cloud. It is written to perform a single job, such as saving a user’s data in the database or performing a scheduled task, etc.

AWS Lambda helps us deploy our web, mobile, or IoT application’s code to the cloud's independent individual functions. It is a pay-per-use pricing model because it only charges the users when their functions are executed. This means there is no resource underutilization when using AWS Lambda. Moreover, it can scale automatically when called concurrently without the need for us to concern ourselves about server-level scaling/management.

All Lambda functions in the serverless service are defined in the serverless.yml file under the functions property. The handler property refers to the file/module containing the function’s code, and we can add as many functions as we want under this property. Function properties can be defined either in the provider property or at the function level. AWS Lambda function needs permission to access AWS infrastructure resources in our account, which are set through the AWS IAM roleAn IAM role is an IAM identity that you can create in your account that has specific permissions. using the provider.iam.role.statements property. We can define HTTP endpoints with AWS Lambda functions using the url property in the function configuration in the serverless.yml.

Events

The functions we just discussed are triggered by events that may come from other AWS resources, such as an HTTP request arrival on a REST API Gateway URL or a CloudWatch schedule executing at regular intervals. A serverless framework automatically creates the required infrastructure for the event (e.g., an API Gateway endpoint) when we configure the event on a Lambda function and it configures the functions to listen to it.

Implementation details

At the bare minimum, a serverless (SLS) application consists of only two files:

  • handler.py
  • serverless.yml

The handler.py file contains our AWS Lambda function(s). It doesn’t need to be called handler. It’s just a convention for single file applications, but you can really call it anything as long as you indicate that in the serverless.yml file.

Press + to interact

Note: The .py extension of the file is typical for a Lambda function that will run some Python code. However, AWS Lambda also supports C#, Java, Go, Node.js, and Ruby code. It also provides a runtime API which allows the use of additional programming languages.

The serverless.yml file is our application configuration. That’s where we’ll define our function parameters, variables, roles, plugins, etc.

Let’s see how to generate these files:

The first example in this course is a slightly modified version of the AWS-Python-Starter option that SLS will generate for us after selecting it.

As we can see in the illustration, SLS comes with a lot of pre-configured applications that we can use and further modify according to our needs.

When we click through the AWS-Python-Starter option, SLS will ask us about the org. For now, select “Skip.”

SLS might not be able to detect our AWS credentials, depending on how and if we configured any profile. For the time being, select “Skip.”

The handler.py and serverless.yml files

Let’s dive a little bit deeper into the generated files.

Press + to interact
import json
def hello(event, context):
    body = {
        "message": "Go Serverless v3.0! Your function executed successfully!",
        "input": event,
    }
    return {"statusCode": 200, "body": json.dumps(body)}

handler.py is a small Python function that returns any body (tag) that was sent to the Lambda function with a short success message and a 200 status code. The handler.py function needs to follow minimal AWS Lambda standards:

  • The function’s arguments are event and context. The event object is any payload sent against the Lambda and context carries information about the invocation, function, and execution environment. In our practice, we’ll usually use the event object.

  • The function can (although it doesn’t need to) explicitly return any response. It can also save a file to Amazon S3Amazon Simple Storage Service without returning any object.

The serverless.yml requires at least three objects:

Press + to interact
org: educativeuser
app: serverless-101
service: sls-aws-python-starter
frameworkVersion: '3' # We would recommend to go directly for the latest major release, if you're not in a need of migrating
provider:
  name: aws
  region: eu-west-1 # Added this
  runtime: python3.9
functions:
  hello:
    handler: handler.hello
  • service: The name of the service that we’ll deploy.
  • provider: Indicates the cloud service provider and global runtime(s) for all our functions in this application (runtimes can be individual).
  • functions: The name(s) of the function(s) that we’ll deploy. For the current example, our function name will be hello, where the reference points to the handler.py file and the hello function within.

Although the frameworkVersion object is not required, because it is built into the SLS templates after the recent major release, it is better to assign it a suitable value.

Modifying a basic serverless.yml file

We have made some minimal changes to the template generated by SLS and added the following objects:

Press + to interact
org: ORG
app: serverless-101
service: sls-aws-python-starter
frameworkVersion: '3'
provider:
  name: aws
  region: eu-west-1
  runtime: python3.9
functions:
  hello:
    handler: handler.hello

  • org: Allows us to connect our service deployment with our account created on Serverless. We’ll briefly talk about the SLS dashboard later. You can replace ORG with a value of your own choice or remove the object altogether if you haven’t registered yet.

  • app: Application is a higher level concept than a service. An application can consist of multiple services that share common variables and parameters.

  • provider.region: Refers to the AWS region. It is usually better to clearly indicate the region where the service is to be deployed.