TLDR; - Skip to the conclusion
There are many tools and frameworks out there to help developers manage and deploy their serverless apps, but the value of these tools, or what they actually do, is not always clear.
This post compares three tools for deploying serverless apps on AWS:
I will have each tool deploy a Lambda function and an API gateway endpoint that can invoke this function. I want to compare the relative complexity of each approach and get a feel for the value each tool is adding. To do that, I will compare:
- Lines of configuration (YAML)
- Lines of code (bash scripts) for initial deployment, excluding non-functional lines (e.g.
echo) - Lines of code (bash scripts) for updating application code (i.e. the lambda code), excluding non-functional lines (e.g.
echo) - Testing capability (local and remote)
I appreciate that lines of code isn’t a metric that indicates quality or ease-of-use, but it does help one appriciate the heavy lifting that frameworks like SAM and Serverless are doing.
Each demonstration app will do the following:
- Validate the configuration template
- Package the app for deployment
- Deploy the app
- Echo back information to allow the user to call the deployed function
The code for each of these strategies can be found on GitHub
CloudFormation
CloudFormation is AWS’s infrastructure as code solution. It’s a first class citizen in AWS, allowing you to provision almost any resource.
It is by far the most verbose way I’ve looked at to deploy a simple serverless application. The other methods take care of a lot of the complexity of provisioning the various API Gateway resources and permissions.
| Lines of configuration | Lines of code for initial deployment | Lines of code for updating app code |
|---|---|---|
| 153 | 6 | 3 |
Testing capability - there is no build-in local testing capability with vanilla CloudFormation, although third party frameworks are available. Invoking the remote function can be done with one line of code, but you have to know the function name. You could write a script to get this automatically using the stack name.
Other notes - CloudFormation isn’t really modular - at least not in the way most developers would think of modularity. It does support nested stacks, which can help, but if you’re thinking about just breaking up a large file you can’t really do that out of the box.
CloudFormation represents the low-level configuration that requires you to define everything. It’s fantastic to fall back on, but it doesn’t provide a quick way to spin up a serverless app, or any additional tooling to help with the development lifecycle.
SAM
The AWS Serverless Application Model (SAM) provides developers with a way to define serverless applications using less verbose and more easily understood syntax. It is made up of two parts:
- Template specification - gives us some extra resource types to use in CloudFormation templates
- CLI - some very useful CLI commands to help package and deploy serverless applications
Essentially - SAM allows us to get rid of a lot of the boilerplate when defining serverless components like Lambda functions and API Gateway endpoints. It then goes further and provides tooling to help with packaging, deployment and testing - things we have to put together ourselves with pure CloudFormation.
| Lines of configuration | Lines of code for initial deployment | Lines of code for updating app code |
|---|---|---|
| 16 | 4 | 3 |
Local testing capability - SAM CLI provides tooling for testing lambda functions and other serverless components locally - see the the docs for more information. Invoking the remote function can be done with one line of code, but you have to know the function name.
Other notes - Like pure CloudFormation - SAM doesn’t offer anything in addition when it comes to modularity, although because there are fewer lines of configuration, it might not be such an issue initially.
The about of configuration to define is substantially less than writing vanilla CloudFormation. Additionally, the tooling for local development of serverless apps is pretty cool, allowing developers to stick to a more familiar workflow of developing and testing locally before deployment.
Serverless
The serverless framework is similar to SAM, in that it provides some aliases that allow the declaration of serverless resources to be simplified. Serverless allows us to fall back to full CloudFormation (like SAM) so we can still define whatever we need, but for our serverless components it can make things much easier. Additionally, it provides some shortcuts for invoking our deployed app and testing locally.
| Lines of configuration | Lines of code for initial deployment | Lines of code for updating app code |
|---|---|---|
| 12 | 1 | 1 |
Testing capability - Invoking the remote function can be done with one line of code, but you have to know the function name. There is also support for local testing.
Other notes - Serverless is the easiest way to get set up with a simple serverless application, and allows you to fall back on CloudFormation for anything else. It’s comparable to SAM in terms of complexity. Ultimately, your serverless template is deployed as CloudFormation, so you get the same guarantees in terms of deployment safety as SAM.
Conclusion
Overall there is a large difference in the amount of configuration required between the three methods. SAM and Serverless are comparable in the amount of configuration they require.
In terms of the amount of scripting required to deploy the app, Serverless provides very succinct commands for achieving this, whereas SAM and pure CloudFormation require some more effort.
| Method | Lines of configuration | Lines of code for initial deployment | Lines of code for updating app code |
|---|---|---|---|
| Serverless | 12 | 1 | 1 |
| SAM | 16 (+33%) | 4 (+400%) | 3 (+300%) |
| CloudFormation | 153 (+1,275%) | 6 (+600%) | 3 (+300%) |
Aside - what about Terraform?
Terraform is an alternative infrastructure-as-code solution that can be used across multiple cloud vendors. None of the tools in this post currently support Terraform (there has been some debate in the Serverless community as to whether Terraform support is a good idea, but it doesn’t look like it’ll be arriving anytime soon).
There’s nothing to stop you from using a mixture of CloudFormation-based technologies (like Serverless) alongside Terraform, but there is a complexity overhead to manage.