6 Patterns for Continuous Delivery with Serverless Applications

Adoption of serverless technology is surely growing, with emerging product companies who built on top of it. CloudZero recently wrote a detailedarticle about their experience in achieving continuous integration and delivery (CI/CD) for their all-serverless system.

Serverless is a new paradigm in which we need to neither administer nor scale the servers that run our code. The promise is that much less operations work is needed to deliver value to customers.

The catch is that the unit of code deployment is now a function, not an application of arbitrary complexity. Besides code, deployment also includes configuring managed services and infrastructure to which the functions connect. This means that new tools and practices are needed to achieve optimal developer productivity, which, as always, revolves around being able to move fast. As Ben Peterson of CloudZero notes:

Our goal is to be less than five minutes away from shipping to production at all times.

Here’s how this is achieved:

1Replicate conditions on your serverless cloud provider in the development and test environments. For example, LocalStack uses Docker to provide AWS cloud APIs (DynamoDB, S3, Kinesis and others) onlocalhost.

2 Use a framework to manage code deployment. For example, the Serverless framework provides a single workflow for configuring and deploying applications on any cloud vendor. AWS customers can use SAM to define applications in code. Serverless applications don’t have separate “build” and “deploy” steps, since there’s no artifact that developers need to manage — this is handled by the framework, and your CI/CD tool should support this workflow natively.

3 Securely store cloud keys and other secrets. For example, an AWS key shouldn’t necessarily be accessible to everyone in the company, and certainly not to the whole internet. If you’re using Semaphore for continuous delivery, you can store and manage organization-wide secrets, which can be reused across projects and mixed with team permissions. If your project is open source, you make continuous integration available to the public, but keep the delivery private for the company.

4 Automated testing remains a key part of the workflow. Common JavaScript testing tools for front-end, and Python / Go / Java tools for backend functions apply. Serverless functions are small, and automated tests should run very quickly.

5 Embrace polyglot programming. For example, CloudZero developers’ language of choice is Python, but they also build data pipelines around AWS Kinesis using Kotlin and Gradle.

6 Keep validation of the codebase (CI) separate from delivery (CD). As Ben Peterson notes:

Like our technology stacks, the set of applications we manage is also diverse, and that includes the development workflow and requirements for deployment to our AWS accounts. Semaphore helps out by providing flexibility along these axes — support for private repos and the ability to manage public repositories and contributor forks, have different logic for deployment of different branches, keep deployment details private, and deploy manually from certain branches. Support for different deployment configurations for each branch is also very useful.

For more details about the experience of developing and deploying serverless applications, read the full article on the CloudZero blog.

What are your tips for effective CI/CD with serverless? Feel free to share in comments.

This post originally appeared on Semaphore blog.

6 Patterns for Continuous Delivery with Serverless Applications was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.