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 <template> --path <project_name>

Python:

There is official template support for python 2.7 and python 3.x.

• Python 2.7 — aws-python
• Python 3.x — aws-python3

NodeJS:

There is official template support for NodeJS 8.x, NodeJS + TypeScript and NodeJS + ECMA Script.

• NodeJS 8.x — aws-nodejs
• NodeJS + TypeScript — aws-nodejs-typescript
• NodeJS + ECMA Script — aws-nodejs-ecma-script

Java:

There is official template support for Java with Maven and Java with Gradle.

• Java with Maven — aws-java-maven
• Java with Gradle — aws-java-gradle

Kotlin:

There is official template support for Kotlin with Maven, Kotlin with Gradle, and Kotlin with Gradle + NodeJS 🤯 🤯.

• Kotlin with Maven — aws-kotlin-jvm-maven
• Kotlin with Gradle — aws-kotlin-jvm-gradle
• Kotlin with Gradle + NodeJS — aws-kotlin-nodejs-gradle

More:

There is official template support for Groovy, Scala, CSharp, and FSharp.

• Groovy with Gradle — aws-groovy-gradle
• Scala — aws-scala-sbt
• CSharp — aws-csharp
• FSharp — aws-fsharp

But, wait there's even more.

You can also easily spin up the foundation for Serverless Plugins, Alexa skills, and even your custom templates!

Custom templates allow you to create reusable Serverless Templates which you can reference via the publicly hosted URL (e.g., GitHub).

We wrote an article showing how to deploy static web applications to AWS using a custom Serverless template which makes the entire process feel way to easy.

Additional Reading:

• Guide, First Serverless Project
• Automate Static Web App Deployment on AWS in Minutes, Serverless Custom Templates

Leveraging fully managed services

Fully managed services, give us the ability to accelerate application development while abstracting away the details which are not needed. For example, when you buy a car, you drive around without needing to know the internal workings of a combustion engine. Fully managed services are the mantra of Serverless development.

At Serverless Guru, we always look for a fully managed solution before rolling our own. To avoid “re-inventing the wheel” and to keep the focus on the product. We lower the complexity and move faster.

Below are some of the fully managed services we leverage on Amazon and Google to help clients build Serverless/Cloud Native applications.

On the Amazon front:

• Cognito — Authentication service supporting OAuth and OpenID
• DynamoDB — NoSQL database
• Aurora Serverless — Relational database for MySQL/PostgreSQL
• Lambda — Cloud functions, a.k.a. glue code
• API Gateway — Simple REST APIs
• AppSync — GraphQL serverless back-end
• S3 (Simple Storage Solution)— Blob storage and static website hosting
• SES (Simple Email Service) — Sending emails
• SNS (Simple Notification Service) — Pub/Sub messaging, send SMS
• SQS (Simple Queue Service) — Decouple and scale Serverless applications
• CloudFront — Caching and faster content delivery
• ACM (Certificate Manager) — SSL certificates for HTTPS

On the Google front:

• Google Cloud Build — create build triggers on GitHub/BitBucket to power the frontend and backend CI/CD pipelines

Additional Content:

• Industry Predictions for 2019
• Best Practices for Serverless Development
• Serverless CI/CD
• Serverless Web Applications — AWS v GCP

What does Serverless Guru do?

Serverless Guru helps companies build scalable and cost-effective applications on the cloud. We help train companies on how to leverage IAC, serverless, and cloud-native services. We help migrate existing applications to the cloud and optimize existing applications on the cloud to be more cost-effective. We are a Serverless development partner and an AWS Consulting partner.

What did we miss?

When you leave your answer make sure to either comment below or tweet your answer to @serverlessgurux on Twitter.

Ryan Jones

Founder — Serverless Guru

LinkedIn — @ryanjonesirl

Twitter — @ryanjonesirl

Thanks for reading 😃

If you would like to learn more about Serverless Guru, please follow us on Medium, Twitter, Instagram, Facebook, or LinkedIn!