Continuous Engineering with the Serverless Framework
Tags: awslambda, softwaredevelopment, softwareengineering, serverless
Published: 2017-10-05 13:32:39

---
title: "Continuous Engineering with the Serverless Framework"
published: true
tags: aws-lambda,software-development,software-engineering,serverless
canonical_url: 
---

![](https://cdn-images-1.medium.com/max/1024/1*mESgrjzutfFUg2dhEZBEsw.jpeg)

We are working with microservices, and I’m enjoying it. Our implementation is based on [AWS Lambda](https://aws.amazon.com/lambda/) serverless compute. This technology launched in 2014, now in 2017 there are still no well-established engineering best practices for&nbsp;it.

We always follow best practices when we develop a product. In this post, I describe how we apply our workflow to the function as a service paradigm.

### Workflow

We use feature branches. Each story gets its branch. When the code is ready, we create a [_Pull Request_](https://help.github.com/articles/about-pull-requests/) (PR) to have changes merged to&nbsp;develop.

The team _peer-reviews_ the code and we suggest changes when needed. We require at least two approvals before merging&nbsp;changes.

Before changes get merged, CI/CD runs. It checks that we stick to our coding [standard](https://standardjs.com/) and runs our tests. If everything passes, you can merge your&nbsp;branch.

When it is merged to develop it gets auto-deployed to our development environment on&nbsp;AWS.

### Code Structure

Working with _Functions as a Service_ _(FaaS)_ means coding simpler, easy to understand modules.

Each microservice has its own repository. Inside it we structured our code around the [_subdomain_](http://blog.jonathanoliver.com/ddd-strategic-design-core-supporting-and-generic-subdomains/) it belongs to. Clustering all related functions of a _service_ together in the same&nbsp;folder.

We are using the [Serverless Framework](https://serverless.com/framework/docs/providers/aws/guide/quick-start/) to manage, build and deploy our functions as a service microservices.

We create one [_service_](https://serverless.com/framework/docs/providers/aws/guide/services/) per subdomain, with its own _serverless.yml_ config file, external packages it needs (_package.json_) and several JavaScript files that implement its functionality.

### Events Definitions

_Function as a Service_ is an event driven paradigm. Functions get spawned in response to an&nbsp;event.

The event definition goes in the _serverless.yml_ config file for each service. It can be an HTTP request through API Gateway, a file uploaded to S3, a record updated in Aurora DB, a document inserted in DynamoDB, etc.

We are currently only using HTTP, Kinesis streams and SNS events for our project. The framework has support for more [event&nbsp;sources](https://serverless.com/framework/docs/providers/aws/).

### Environment Variables

We use environment variables as much as we can. ARNs, Endpoints, AWS Credentials, AWS Region, etc. Serverless lets you define resources from environment variables. It will let you know if any of the variables are not defined in your environment before it tries to deploy your&nbsp;lambdas.

![](https://cdn-images-1.medium.com/max/1024/1*lx0zENu-ZsIg-zWGsVhHCA.png)<figcaption>Serverless Framework complaining about missing environment variables</figcaption>

The team shares environment variables with the help of [Torus](https://www.torus.sh/). Our CI/CD tool reads these environment variables to deploy our lambdas automatically when we approve a&nbsp;PR.

### Release /&nbsp;Deploy

We use _Continuous Integration_ and _Deployment_. Code Linting and Tests runs before a PR can be merged. Deployments to _dev_ and _staging_ are automated.

![](https://cdn-images-1.medium.com/max/1024/1*ClvMVSJxCklXjg8BwVKyTg.png)<figcaption>Deploying with CI/CD + Bash + Serverless (staging)</figcaption>

Our CI/CD pipeline runs a basic NodeJS docker image, finds all our services, goes into each folder, runs [_yarn_](https://yarnpkg.com/lang/en/) to install all dependencies and deploys to AWS. Nothing particularly sophisticated.

A few bash get run commands, _et voilÃ !_ A fully functional set of lambdas&nbsp;running.

![](https://cdn-images-1.medium.com/max/1024/1*l5MSQ4f0xIeW8jb31T6K_A.png)<figcaption>Result of our CI/CD <strong><em>yarn</em></strong><em> + </em><strong><em>sls</em></strong>Â run.</figcaption>

> Everything’s been taken care of&nbsp;ðŸŽ‰.

If everything goes well, we will get a message on Slack that everything’s been taken care of. All services are up to&nbsp;date.

At this point we are ready to work on the next feature and continue the development cycle.

### More resources ðŸ“š

- The [Serverless Framework](https://serverless.com/) and many [examples](https://github.com/serverless/examples).
- [Micro](https://github.com/zeit/micro) async http node microservices. Great first approach to self-hosted simple functions to build services.
- [Apex](http://apex.run/) another framework for managing FaaS. It has runtimes for Go, Clojure, and Rust, so you can write functions on those languages that are not supported by AWS&nbsp;Lambda.
- [WebTasks](https://webtask.io/) FaaS by the Auth0 team. Integrates really well with Slack and GitHub. Has Cron-like support for scheduled tasks.
- [stdlib](https://stdlib.com/) a slightly different approach. They strive to become a Standard Library for FaaS. Has a Service Directory and functions can be invoked from regular NodeJS, Python or Ruby projects.