Serverless, Development & Deployment – Serverless Framework?

Are you still unfamiliar with Serverless? Then you can find everything you need to know about Serverless here.

In the third part of the Serverless Development & Deployment series, we venture into the open-source world and take a closer look at the Serverless Framework.

After getting to know two AWS-only frameworks, namely the AWS Cloud Development Kit (CDK) and the AWS Serverless Application Model (SAM), we are now leaving the safe AWS world! The good news is that we can finally create serverless resources with other cloud providers, as the Serverless Framework supports several cloud providers, including the following:

AWS
Azure
GCP
Knative
CloudFlare
Kubeless

Behind the Serverless Framework is a very active community that continuously develops and improves the framework. Legally, the company “Serverless” is behind it, which is based in San Francisco. Basically, their offering consists of two products, which we want to take a closer look at here.

Serverless Framework

The Serverless Framework is an open-source framework first released in 2015 that allows us to define and deploy serverless architectures.

As in the last TechUps, we will take a closer look at a Serverless Land Pattern, which we want to deploy with the Serverless Framework.

Goal: API Gateway REST API to Lambda Serverless Land Pattern: API Gateway REST API to Lambda IaC Tool: Serverless Framework Language: TypeScript Aws Services: API Gateway, Lambda

The pattern deploys a Lambda function that is bound to an arbitrary path and returns it in the response. The pattern is kept very simple, but it shows us how we can use the Serverless Framework to build an API Gateway REST API to a Lambda function.

Setup

First, we need to install our serverless CLI via npm:

1

npm install -g serverless

Fortunately, bootstrapping the cloud provider’s account is not necessary here either, so the setup is complete!

Development

As in the previous example, we clone the repository (the existing one can also be used) and switch to the correct folder:

1
2
3


git clone https://github.com/aws-samples/serverless-patterns/ 
cd serverless-patterns/apigw-lambda-sls
code .

Now let’s take a closer look at the project:

example-pattern.json: This is a configuration file for the pattern in Serverless Land, it has nothing to do with the Serverless Framework.
package.json: The classic package.json, which should be present in every Node.js project.
README.md: The classic Readme, which should be present in every project, but can also be omitted.
serverless.yml: The actual content of the project, this is where our serverless architecture is defined.
src: The source code of the project, this is a TypeScript project.
tsconfig.json: The configuration file for TypeScript.

The heart of the project is the serverless.yml file, which we will now take a closer look at:

At the beginning, we define what our service is called and which framework version we want to use.
Then we activate a plugin to be able to use TypeScript in a Lambda function.
Then we define which provider we want to use. In our case AWS.
We define the runtime, architecture, stage and memory of our Lambda function.
Last but not least, we create a function called logEvent, which we can call via different paths via our API Gateway.

Moment! Plugins?

The Serverless Framework offers a variety of plugins that we can use in our project. Currently, there are over 350 plugins, functionality such as offline testing, Webpack integration, API Gateway caching, REST support etc. is easily integrated into our project. Very cool! 🚀

Local Development

First of all, we need to install our dependencies with npm:

1

npm install

Then our project is ready for local development. With the following command we can call our Lambda function locally and pass it a JSON payload:

1

serverless invoke local --function logEvent --data '{"a":"bar","path":"hello"}'

And we get a result back! 🎉

Of course, it must be noted here that this is a very simple Lambda function that has no dependencies. The plugin serverless-dynamodb-local allows us to start a local DynamoDB instance, which we can then also use locally.

Besides the serverless-dynamodb-local plugin, there are other very valuable plugins like serverless-offline, which allows us to start a local API Gateway instance, which we can then also use locally.

The Serverless Framework follows the same path as the other frameworks and relies entirely on an isolated, local development environment where everything can be mocked or started locally.

Deployment

After we have installed our dependencies using npm install, we can deploy our project:

1

serverless deploy --region eu-central-1

With the region option we can specify the AWS region in which we want to deploy our serverless architecture. Of course, we could have also defined this directly in the serverless.yml file.

In the output we see that our TypeScript project was compiled and the serverless resources were created as a stack using CloudFormation. Fortunately, we also get our API Gateway URL back here, which we store as an environment variable:

1
2
3


export APIGW_REST_ENDPOINT=https://<api-id>.execute-api.eu-central-1.amazonaws.com/prod

# e.g. export APIGW_REST_ENDPOINT=https://ossjouvvx9.execute-api.eu-central-1.amazonaws.com/prod

And now we have successfully deployed our function. It is noticeable that there is no prompt to accept the creation of the resources (as is the case with SAM, CDK, Terraform).

Testing

Now we can use our API Gateway URL to call our Lambda function:

1
2
3
4
5
6
7
8


curl $APIGW_REST_ENDPOINT
# Hello Serverless Citizen, your happy path is: "/"

curl $APIGW_REST_ENDPOINT/a/b
# Hello Serverless Citizen, your happy path is: "/a/b"

curl $APIGW_REST_ENDPOINT/hello-from-tom/1
# Hello Serverless Citizen, your happy path is: "/hello-from-tom/1"

We see that our Lambda function works as expected. Nice! It is bound to an arbitrary path and returns it in the response. Now we have performed a complete development workflow including local testing, deployment and integration tests. 🔥

Serverless Console

Another useful feature from Serverless besides their framework is the Console. This offers live tracing, monitoring and error tracking for our serverless architecture.

The Serverless Console itself acts as SaaS and is not open-source. Currently, the console is in a beta version and only supports AWS as an integration.

The goal of this (and generally any) Serverless Console is that developers have all relevant information about their serverless architecture in one place. No more annoying searching for CloudWatch events or the like, the console deploys a CloudFormation stack in the respective AWS account and retrieves all relevant data, logs and information from there. Simple!

Source: https://www.serverless.com/blog/introducing-serverless-console

Unfortunately, there were problems with the deployment right away, we could not successfully deploy the stack to our eu-central-1 region. Therefore, we had to deploy our application to North Virginia on short notice, where the deployment of the Serverless Console then worked without any problems. We did this with the following command:

1

serverless deploy --region us-east-1

A very useful feature of the Serverless Console is the live streaming of our events, logs etc. which can be used in Dev Mode. This is especially useful for testing and debugging, as we can see directly in the console what is happening, going wrong or being logged.

Cleanup

Finally, we need to delete our serverless architecture again:

1
2


serverless remove --region eu-central-1
serverless remove --region us-east-1

TLDR

The open-source Serverless Framework is a tool that allows us to declaratively create, manage and deploy serverless architectures in the cloud. It is worth noting that the Serverless Framework not only supports AWS, but also other cloud providers such as Azure, Google Cloud, IBM Cloud, Cloudflare, Oracle Cloud etc. Currently, there are exactly 14 patterns on Serverless Land that are supported by the Serverless Framework. The high number of plugins, solutions, blogs and resources in general testifies to a very active community that actively supports the Serverless Framework.

Advantages

Simplicity: The Serverless Framework offers a simple and intuitive syntax to define and configure cloud resources.
Cloud-agnostic: It supports multiple cloud providers, not just AWS.
Templates & Plugins: There is a large community that provides plugins and templates to extend functionality.
Automation: Deployment processes can be easily automated.
Development environment: Provides a local development environment for testing functions.

Disadvantages

Complexity at large scale: For large applications, the configuration file can become complex and difficult to manage.
Dependency: You tie yourself to another tool, which can make potential future changes or migration tasks more difficult.
Potential delay: There may be a gap between the release date of new cloud features and their support by the Serverless Framework.
ServerlessLand: Unfortunately, there are very few predefined patterns on ServerlessLand.
AWS-centric: The Serverless Framework is very AWS-centric, which is also reflected in the number of patterns, plugins, examples.

CDK, SAM or Serverless Framework?

Below we want to make a brief comparison of the previously known IaC tools for the serverless use case.

AWS CDK: Imperative, appeals to developers who prefer a powerful, programmable and AWS-specific solution.
AWS SAM: Declarative, is ideal for those who want a specialized and simplified solution for serverless AWS applications.
Serverless Framework: Declarative, is for developers looking for a cloud-independent solution with many plugins and an active community.

In the next TechUp we will learn about another, very promising imperative IaC tool for serverless use, stay tuned! 😉

This techup has been translated automatically by Gemini