CloudDevOpsServerless Applications

Serverless Framework

Serverless Framework is one of the most popular frameworks for building serverless architectures. It is an open source CLI, with about 23,000 stars on GitHub.
There is also an enterprise edition that helps in setting up templates and providing support.
This framework has been used by many companies, such as EA, Coca Cola, Expedia, and Reuters.
It is a framework that supports lots of cloud service providers, such as AWS, Azure, Google, OpenWhisk, Kubeless, Oracle Fn, and many others.
It has a very well-documented user guide containing quite a large number of examples to help you start using it. It supports lots of languages, such as Node.js, Python, Java, Scala, C#, Go, F#, Groovy, Kotlin, PHP, and Swift.

It supports the life cycle of serverless architecture, which can build, deploy, update, and delete.
It supports function grouping for easy management of code, processes, and resources across large projects, and also provides fairly good support for CD/CI.
It has far better community support compared to other frameworks. It provides lots of plugins to support framework functionality.
There are a lot of blogs to help us build the best practices in using the framework.
It has a support forum and slack rooms for resolving issues and problems. It supports lots of features, such as deploying functions and events, invoking functions, tailing logs, integration testing, and packaging for future deployment.

Framework features:

There are many features available in Serverless Framework, although they vary with the cloud provider.
I will list and describe a few of the more important and more common ones.

Services and deployment:

A service is a project where we define the functions, the events that trigger them, and any infrastructure resources that are required for the function to perform. They are collected together into one file, which is called

serverless.yml:

eg.
myServerlessService/
serverless.yml

When we start using Serverless Framework for deployment, we will be using one single service.
But as the application grows, it is recommended that you have multiple services as shown in the following code:

users/
serverless.yml # Contains 4 functions
posts/
serverless.yml # Contains 4 functions

Having multiple services can isolate the infrastructure resources that are to be used. But it also has a drawback, as currently each service creates a separate REST API on API Gateway.
This is a limitation with API Gateway. But there is a workaround to resolve this, which we will look into in future chapters.

To create the service, we have to use the create command, and we must pass the runtime language in which you would like to write the service.
We can also provide the path, as shown in the following example:

$ serverless create --template <runtimes> --path myService 

The main purpose of Serverless Framework is to deploy functions, events, and infrastructure resources into the remote cloud without much hassle, and that is done through the deploy plugin.
There are various features that this deploy plugin provides.
Let us look at a few of them:

  • Deploy to different stages and regions:
$ serverless deploy --stage production --region us-east-1 
  • Deploying single function from the service:
$ serverless deploy function <function_name> 
  • Deploying package to cloud:
$ serverless deploy --package <path to package> 

This deploy plugin works in the following ways:

  • The framework packages up the targeted AWS Lambda function into a .zip file
    null
  • The framework fetches the hash of the already uploaded function .zip file and compares it to the local .zip file hash
  • The framework terminates if both hashes are the same
  • That .zip file is uploaded to your S3 bucket using the same name as the previous function, which is the CloudFormation stack it is pointing to

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

bpN fQ5Q yw

Please type the text above:

Check Also

Close
Close
Close