This article describes how to deploy a basic serverless app using the Serverless Framework.
We will be covering a brief introduction of Serverless, a comparison with other frameworks/tools, and finally, the step-by-step to make the code to deploy a basic API GW-Function app in AWS using Serverless.
Serverless Framework is an open-source CLI that helps you manage the entire serverless application lifecycle, with way less overhead when developing your IaC (Infrastructure as Code).
It is built upon the CloudFormation stack, therefore it has been natively designed to work with AWS. But that doesn’t limit Serverless from being capable to deploy a serverless app to other clouds.
Its main purpose is to deploy Lambda Functions and all the infrastructure resources they require.
Because of this nature, Serverless manages both code and infrastructure, supporting multiple programming languages like Node.js and Python.
In the background, Serverless constructs two CloudFormation stack JSON files, one with the code to deploy an S3 bucket to upload the app code and another one with the code to deploy all the resources the app requires.
There is a set of common resources that are always deployed (unless specified) and they consist of:
The rest of the resources depend on the solution, usually consisting of a combination of API Gateways, Lambda Functions, and other serverless resources, like Amazon RDS or DynamoDB.
Another similar tool for the purpose of deploying serverless applications is SAM (Serverless Application Model).
SAM is an abstraction layer to simplify CloudFormation and also a set of CLI tools that help to test and deploy the applications. Although the purpose is very similar to what Serverless does, SAM is limited to working with AWS only, as it is basically a simplification of CloudFormation.
Let’s see a comparison table:
The following repository will be used as an example of how to deploy a basic serverless app to AWS using Serverless:
We will be creating a REST API that allows a Users CRUD (Create, Read, Update, Delete). Our Users will only have an id automatically generated by the app and a name.
For a more detailed description, prerequisites, and manual run, please refer to the repository README.
Now, let’s analyze the serverless.yml file a bit more in-depth:
This file is the main one that serverless will use to build and deploy the app.
This is the definition header of the serverless app. “service” is the Serverless’ unit of the organization, the project. It is possible to have more than one service defined for more complex applications.
“frameworkVersion” specifies which version of Serverless we will be using.
“provider” is the definition of the cloud provider we will be using. For every provider, there is a set of required parameters. In the case of AWS, it is required to specify the region. Also, it is required to specify the credentials, but both the ACCESS_KEY_ID and SECRET_ACCESS_KEY are exported and accessed via the environment variables.
The “runtime” is the stack that AWS Lambda Functions will use to run. In this case, we will choose Node.js.
“functions” are the actual Lambda functions that will be created, along with their “events”, which are any event able to trigger the function. In this example, we will be using HTTP API events, which are the HTTP API type in API Gateways.
This way, with only this YAML file, we can define an entire serverless application, including how the Lambda function will work and what will be the events associated with this function:
Serverless Framework is a great tool to have a short TTM (Time To Market) if your core business is serverless based and of a small/medium size.
It is worth mentioning that in big and complex scenarios, managing code and infrastructure with Serverless can be challenging, increasing the complexity of the serverless.yml files exponentially, instead, other tools like Terraform would be eventually more suitable.
2018, Cryptoland Theme by Artureanec - Ninetheme