When starting to write software in serverless and Function-as-a-Service, the default cloud vendor’s console is the starting point. However, once the application gains some complexity, a proper deployment tool is necessary. This post covers the most popular deployment tools for serverless.
Each of the cloud vendors provides an easy way to deploy functions:
Serverless deployment platforms enable more than just deploying your code — their features vary from modeling the serverless application, code management, visualization, and multi-cloud support.
SAM — Serverless Application Model — is a way to describe and deploy serverless applications in a simple way. It extends the AWS CloudFormation to provide a simplified method of defining AWS Lambda functions, API Gateway, and DynamoDB tables. It supports the runtime of the Lambda functions. AWS SAM only supports applications deployed on AWS.
AWS SAM applications are described in the SAM format, which is JSON or YAML and deployed using the AWS SAM CLI. Get started using this guide. AWS SAM also has an active Slack channel.
Describing an application using AWS SAM (source: AWS)
Deploying a function using the AWS SAM CLI (source: AWS)
Aspiring to be the “Cloud Native Infrastructure as Code” framework, Pulumi aims to provide a cloud development model for serverless functions, container apps, and data infrastructure for any cloud. The Pulumi CLI tool is the primary way of using Pulumi, and it deploys to different providers: AWS, Azure, GCP, OpenStack, as well as Kubernetes. Pulumi also created the Pulumi Cloud Framework, which lets you program infrastructure and application logic, particularly suitable for serverless applications, and being cloud-agnostic. Pulumi has an active Slack community, and it is also available on GitHub.
Deploying and managing infrastructure using Pulumi (source: TechCrunch)
The Serverless Framework is an open-source tool for managing and deploying serverless functions. It supports multiple programming languages and cloud providers. Earlier this year, it introduced two additional tools — Event Gateway, which provides an abstraction layer to easily design complex serverless applications, and Serverless Dashboard, for better management of the application, as well as collaboration. Serverless Framework applications are written as YAML files (known as serverless.yml) which describe the functions, triggers, permissions, resources, and various plugins of the serverless application.
A comparison of Serverless Framework vs. other tools provides some insights into the differentiation of the framework. Serverless Framework has an active GitHub community. Many examples to get started can be found on the GitHub page.
Deploying an application using Serverless Framework (source: serverless.com)
Stackery’s promise is to be the best toolkit for serverless development for teams. Unlike AWS SAM and Serverless Framework, from day one Stackery introduced a dashboard for visually designing and building serverless applications. Also, it does provide a standard CLI as well, and also announced that it is now built on AWS SAM.
In addition to creating and deploying serverless applications, Stackery also provides strong collaboration tools for teams, including rollback protection, automatic build packaging, and a GitHub integration.
Building serverless applications visually using Stackery (source: Stackery)
Unlike platforms, tools are suitable for specific tasks and mostly provide automation around them.
Chalice is a framework by AWS for writing serverless applications in Python and allows to quickly create and deploy applications that use AWS Lambda. Chalice provides a command line tool for creating, deploying, and managing apps, integration with common AWS services, and automatic IAM policy generation. Chalice is available on GitHub.
Apex is a framework which aims to let you easily build, deploy, and manage AWS Lambda. One of the key features of Apex is the ability to use languages that are not natively supported by AWS Lambda through the use of a Node.js shim injected into the build. In addition to building and deploying the functions, other related tools provide testing, deployment roll-backs, and log tailing. Apex is available on GitHub.
If you are deploying AWS Lambda functions in Node.js, you should check out Architect. This framework uses a plaintext manifest to describe cloud infrastructure, including version control, fast deployment and working locally. Architect is available on GitHub.
A popular project among developers using AWS Lambda, Node.js, and API Gateway, is Claudia.js. It enables to deploy an AWS Lambda and API Gateway applications with a single command, using only standard NPM packages and makes it easy to manage multiple versions. Claudia.js is available on GitHub.
The Go programming language is becoming more and more popular, and together with the announcement of Go support for AWS Lambda earlier this year, Sparta is a framework that transforms a standard Go application into a self-deploying AWS Lambda powered service, while all configuration and infrastructure requirements are written as Go types as well. Sparta is available on GitHub.
The well-known Infrastructure as Code service, Terraform is used to manage and deploy cloud stacks across different providers. It also provides a way to deploy serverless applications, including AWS Lambda and API Gateway.
Probably the most popular tool for deploying serverless web services in Python, Zappa enables to easily deploy web applications, usually written in Flask or Django. Zappa wraps the standard application and deploys a Lambda function to enable a serverless, scalable experience. Zappa is available on GitHub.
As we can see, over the past two years, many tools for deploying and managing serverless applications have emerged. Each of these tools has a different focus, but in the end, they all have a common goal — to enable developers to iterate faster in serverless, without losing their heads.
Obviously, deployment is just one part of the serverless journey. Other aspects include performance, testing, security, debugging, and monitoring. Each of these has to be resolved to to enable a fully-serverless state of mind.
Originally published at blog.epsagon.com.