DIY — Build yourself a Serverless Framework with 152 lines of code

CuongQuay

Follow

Aug 23, 2020 · 5 min read

Have you ever asked yourself how a framework has been built to do a magic job for you? In this article, we will be together in 3 minutes to learn HOWTO to build a framework. This framework will deploy your function code into AWS Lambda or GCloud Functions service as you choose.

According to “Framework” definition, a Serverless Framework will be a supporting structure around which a Serverless can be built.

In software development, this is about how to construct a project using infrastructure or service that you don’t have to manage any Server to run your whole project code (Monolithic) or a set of functions (FaaS).

All that is, something will help you construct your projects, manage its deployment and tests will be called as a Serverless Framework.

Basic features of a Serverless Framework

There are THREE essential features and SIX following steps you must provide for any serverless tool or framework:

1. Init project information with Cloud Service Provider authentication method that allows your framework upload files, manage essential services such as S3, Lambda, IAM Role and Policy.
2. Upload your source code as a zip file onto a specifically designated location such as S3.
3. Request to create a serverless function such as Lambda that will use your zip file.
4. Notify developers when the function is created and ready to use.
5. Change your code, then deploy it again, again and again…
6. Destroy everything you have created to cost you nothing.

Most of the frameworks having problems in Step 5. When the code logic is changed, your infrastructure design will change accordingly to its resource accesses. Your deployment probably will fail.

Step 5 requires a good framework to be able to perform:

• Source code is updated only if it has been modified. Otherwise, just keeps it no change to upload.
• A configuration is always up-to-date accordingly for every deployment. This design will always ensure the configuration consistent with the current code.
• Your function metadata must be collected and saved locally or in a centralized place. You always need this metadata to orchestrate your infrastructure as code.

Why don’t we upload everything when performing a deployment? A configuration data is very small in bytes or kilobytes but your code is not usually smaller than megabytes.

In order to avoid consuming too many bandwidths, the best way is using a hashing algorithm. AWS Lambda has its own CodeHash field but it is hashed with a timestamp along with its code. It means whenever you hash your code, it will be different from the last time. You need to overcome this point when building your toolkit to avoid uploading the same thing every time.

A resilience, graceful operation for deploying and destroying a function should be put in mind when designing every software. Resilience operation means it fails when it needs to be failed.

When you deploy your code, if there is something wrong with user input parameters, it must be failed and wait for user correction. If there is an error from a reason likes “You cannot create your function because it exists.” It must be resilient by continuing to the next operation.

Important: a good framework must support to manage multiple deployment environments without impacting to the others when switching between them.

A deployment environment should cover the following properties:

• A name as a shortcode (eg: demo, staging, prod)
• A service account (eg: 01234566622 or gc-project-id)
• A location or region (eg: us-east-1, eu-central-1)
• A project code name (eg: starwars or bookstore)

In software development, a “so-called” project has several stages in its lifecycle. Best practice tell you to separate development, testing and production environment into different spaces for security.

Sharing these environments also are needed for everyone in your team. You should make it easily with git pull and run deploy command.

To generalize your project with multiple environments. You must use a template or variable parsing technique. A ${FOO} must be “bar-demo” or “bar-staging” according to the current environment.

simplify-cli — A pre-built Serverless Framework

Simplify SDK offers you a basic set of operations for building this framework-like. An optimistic, minimalist framework code with 152 lines can be found in https://github.com/simplify-framework/serverless/blob/master/cli.js

simplify-framework/serverless

A minimalist serverless CLI for AWS Lambda. Contribute to simplify-framework/serverless development by creating an…

github.com

Let’s install simplify-cli package then generate a skeleton code to play with:

• npm install -g simplify-cli
• mkdir ./starwars && cd ./starwars
• simplify-cli init

Looking into the .env file was generated. You will see a block to declare a deployment configuration, the application and the information for your function:

Figure — 1. Project environment variables.

All parameters are put in a .env file so that the framework can read easily and combine with the config.json will generate a final environment base setup. To deploy your function above, you can try to write this sample code:

var fw = require(‘simplify-cli’)

fw.deployFunction(“config.json”, “.env”, “role.json”, “policy.json”, “src”)

Or just run through the simplify-cli command-line interface:

• simplify-cli deploy
• simplify-cli destroy

An example application is provided to demonstrate the way to use your function in a web project:

• cd examples
• npm i simplify-sdk
• node deployment.js
• node destroy.js (for your work)

This application will deploy an API Gateway that triggers your Lambda function in .src folder. It also deploys the html folder into an S3 published as a static WebSite.

Try to visit the Website URL: https://starwars-website.s3.amazonaws.com/index.html to see the CloudWatch Logs printed on your website. You must refresh several times to generate function logs: