Jesse's Software Engineering Blog
AWS Serverless Application Model
AWS Serverless Application Model (AWS SAM) is an abstraction of AWS CloudFormation for templating serverless AWS applications. Using a templating tool to define serverless infrastructure can be extremely helpful as applications grow in size. Codifying infrastructure allows for more visibility and replicability of services. I am going to highlight to some of the benefits of using AWS SAM and have provided an infrastructure example.
Setting up a serverless stack is pretty straight forward. It’s important that before you start you make sure to have the newest version of the AWS cli to avoid any odd bugs. On *nix systems you can run:
pip install --upgrade awscli # aws-cli/1.15.4 Python/2.7.10 Darwin/16.7.0 botocore/1.10.4 aws --version
To set up an example serverless stack:
- Set up an S3 bucket in the region of the application
- Author your SAM templates. Here are some more examples from AWS
- Write a Swagger spec (either yaml or json) if you are using an API. This can be done in-line or in an existing file. I used an existing file in my example as, in my opinion, it’s easier to read when they are separate.
- Upload your Swagger spec to S3 so that it can be referenced in the SAM template
- Run the CloudFormation package command against the SAM template to upload the resources and generate the CloudFormation template
- Run the CloudFormation deploy command to create and deploy a change set.
In my infrastructure example I have included the following files
- app_spec.yml – This is the SAM template. After running the package command there will be the auto generated app_deploy.yml which will be used to deploy the stack.
- swagger.json/yml – There are two identical Swagger examples, one using json the other yaml
- commands.txt – These are the commands that need to be run to upload the Swagger spec to S3 and run the CloudFormation deployments
- src/* – Simple Lambda implementations for testing with
Using a templating tool such as SAM can be extremely valuable as applications grow. By defining infrastructure as code, we are able to incorporate our infrastructure into source control and get the benefits of continuous deployment, testing, versioning, etc. It also allows for centralization of infrastructure which can keep things manageable. As an example, by using Swagger the entire API is defined in a single location and can be ported over to different AWS region or even to another cloud provider rapidly. With codified infrastructure the need for manually logging into a dashboard becomes less of a necessity and we are able to streamline both our dev workflows as well as our ops rotations.