Best Practices for Serverless Development

In this article, we dive into some Serverless best practices. There are a couple of high-level sections. First, we kick off with selecting a cloud provider. Then move to select a deployment framework. We end with leveraging fully managed services. This article is not an exhaustive list of best practices, but a few high-level topics which provide the foundation to explore further.

Sections:

• Selecting a cloud provider or two
• Choosing a deployment framework
• Leveraging fully managed services

Selecting a cloud provider or two

When it comes to Serverless development, it is even more important to make sure we select the right cloud provider for the job. The primary reason the decision is important comes down to the long term maintainability and scalability of your application.

Below is an ordered list of significant cloud providers which we have experience using to build Serverless applications:

1. Amazon Web Services (AWS)
2. Google Cloud Platform (GCP)

Amazon is number one because they started this whole movement with the release of AWS Lambda back in 2014. Amazon has been the primary driver of Serverless innovation and ensuring that new services are composable and easy to automate.

Google is number two because their Serverless offerings are less mature than Amazon around FaaS (Functions as a Service) and don’t provide the same composability that we get with Amazon. However, Google has poured much energy into making their cloud platform easy to use and for new cloud developers Google has a lower bar of entry.

At Serverless Guru, we combine both Amazon and Google to get the best of both worlds. We keep our Serverless application development centered around Amazon services and leverage Google for our CI/CD (Continuous integration/Continuous delivery) pipelines. #multi-cloud

Choosing a deployment framework

Serverless development is all about bringing multiple roles such as operations and development together. Serverless development translates to the Serverless developer writing automation and application code at the same time.

At Serverless Guru, we are active users of the Serverless Framework. The Serverless Framework allows us to easily tie various AWS services together to automate entire applications through a single terminal command.

The benefits of this approach include:

• High levels of automation
• Multi-stage/multi-region environments for testing/production
• Developers have a deeper understanding of the entire application

Organizing projects

How you structure your projects has always been an important factor in software development. Serverless development is no different. Let’s take a look at a basic structure for a well broken apart project.

  
src/
  main.js              <-- Lambda entry point
  services/            <-- Business Logic
    api.js
  helpers/             <-- Reusable functions
    util.js
resources/             <-- Native CloudFormation
  general.yaml
  general-ouputs.yaml
scripts/               <-- CI/CD scripts
  test.bash
  deploy.bash
serverless.yaml        <-- Serverless Framework config
cloudbuild.yaml        <-- Google Cloud Build CI/CD steps
package.json
  

Key directories:

• src — Lambda code
• resources — Native CloudFormation files to keep the serverless.yaml clean
• scripts — CI/CD bash/python scripts

Key files:

• serverless.yaml — Connects the lambda code and AWS resources together into a deployable stack
• src/main.js — Entry point for our lambda functions
• cloudbuild.yaml — Google Cloud Build CI/CD pipeline

Creating reusable templates

Code reusability is a significant part of software development. Thanks to the Serverless Framework and Amazon our infrastructure is now code. Enabling “infrastructure reusability” through the use of shared Serverless Framework templates.

Most people who use the Serverless Framework are fully aware that you can run a command like this.

  
$~: sls create --template aws-nodejs --path nodejs-project
  

However, did you know that the Serverless Framework has A LOT of other templates? Let’s get into it.

How do you leverage a template to speed up new projects?

  
$~: sls create --template