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
- 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