Continuous Delivery for AWS Lambda Applications

By Nick Durkin
November 7, 2017

AWS Lambda is a web service you can use to build applications without having to worry about compute constraints or complexity. In order to use, simply upload your application code as Lambda functions and Lambda runs your code on high-availability compute infrastructure.

Lambda also performs all the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code and security patch deployment, and code monitoring and logging. All you need to do is supply your code in one of the languages that Lambda supports:

  • Node.js (JavaScript)
  • Python
  • Java (Java 8 compatible)
  • C# (.NET Core)

Serverless – A developers dream?

At the crux of it, Lambda is a developer’s dream. No longer is there a requirement to set up infrastructure or configure servers. All that has to be done is simply deploy new code. Beyond ease of deployment, there are also monetary benefits.

Why run a server 24×7 that is just waiting to be hit by an API call that may or may not get called in the next half hour, hour, or even day? Why not simply pay for compute when your code is actually doing something? In comes Lambda!

Challenges with Continuous Delivery For Lambda

Immutable objects (those that can’t be changed) have a few challenges when it comes to continuous delivery, thus so does Lambda. Lambda functions are versioned with the latest always being published to $LATEST. These versions are made up of both code as well as configuration (variables). Once the code and configuration are published, the function becomes immutable.

The challenge with continuous delivery on Lambda actually lies in the versioning, tagging(aliases), and rollbacks. Each new version is immutably pushed to $LATEST; as a result, rolling back to a previous version becomes complicated. This stands true even if your applications are properly designed to use tags. Moving forward is easy–it’s reverting back that is complicated based on the previously successful tagged deployment.

At Harness, we solve that complexity by keeping track of the two pieces required to tag(alias) or recreate the function, the code, and the configuration. Harness not only works with the limitations of Lambda, but also implements the best practices for immutable infrastructure. Harness handles the burden of managing the code and config in order to properly version, tag, or recreate the previous version, thus allowing for fully automated rollbacks based on prescriptive failure strategies.

Deploying to AWS Lambda with Harness

Setting up Harness to manage the continuous delivery or continuous deployment of Lambda Functions was designed to not only be simple but also repeatable.

The process can be broken down into 5 easy steps:

1. Creating A New Lambda Service

a. Enter a Service name and select “AWS Lambda” as Artifact Type along with a brief description of the Service.

Creating Lambda Service

b. Next, add an Artifact Source. The example below shows Amazon S3 as the location.

Lambda Artifact Source

c. Finally, add your Lambda Function Specifications (configuration).

Lambda Specification

2. Set Up Your Lambda Environment

a. Add Environment(s) with a name and an environment type (non-production/production):

Lambda Infra

b. Add Your Service Infrastructure by selecting the appropriate AWS account, region, IAM role, VPC, Subnets and Security Groups:

Lambda infrastructure

3. Creating Your Lambda Deployment Workflow

Workflows can be added individually for each Lambda Service deploying to each environment. You can also templatize these deployment workflows that can call Infrastructure, Service, and Environment as variables at runtime, removing the need for duplication across many Lambda services.

Creating Deployment Workflow

a. Harness will automatically populate the steps needed to deploy and rollback your Lambda Service:

Lambda Workflowb. You can also add workflow preparation, verification or wrap-up steps for your Lambda Service. In the example below, you can define simple test events for each of your Lambda functions using payload assertions.

Verification Steps

At this point, the Workflow is ready to execute a workflow.

4. Creating your Lambda Pipeline

With Harness, you can stitch together multiple deployment workflows as pipeline stages across your development, QA, and production environments. These pipeline workflows and stages can either execute sequentially or in parallel depending on your needs. You can also templatize pipelines and delegate them to individual teams or users.

5. Build your Lambda Pipeline Trigger

Finally, triggers can be used to automatically execute pipelines based on new versions of Lambda Functions.

a. Define triggers to execute either a deployment Workflow or an entire Pipeline.

Lambda Trigger

You’re all done and ready to deploy! Click the “Early Access” button at the top of this blog to get started with Harness today.

Here’s a quick two-minute video of deploying AWS Lambda using Harness:

 

Further links on AWS Lambda:

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of