Serverless Design Patterns and Best Practices: Build, secure, and deploy enterprise ready serverless applications with AWS to improve developer productivity

Since this is the very first chapter that has application code and working examples, it's important to talk through some of the tooling and systems to set the stage for this and subsequent chapters. In this and the following chapters on web applications, our toolchain will consist of services from AWS:

While AWS is the dominant player in the Platform as a service (PaaS) ecosystem, it is by no means the only choice. While reading this chapter and others in this book, remember that the patterns presented should apply to any cloud provider, albeit sometimes with a certain degree of adaptation.

You may be questioning the reasoning behind discussing other services such as S3 and RDS. Very often, perhaps usually, when people say serverless they are talking about functions as a service...

At first glance, a three-tier web application using a REST API can be an easy topic and pattern. After all, there are only three layers, which are responsible for very discrete tasks, and the final result is just a web application after all. However, there are many nuances and areas for tweaking with any web application. Serverless web applications are no different. This chapter will attempt to cover as many areas as possible, but it's impossible to include every possible configuration or design option.

Seeing as we are responsible software designers, let's sketch out our architecture at a high level and drill down into more detail as we work through the different layers:

This diagram should look familiar as it's the backbone of many client-server web applications out there today. Let's walk through the different layers, going from the top down. After discussing these layers at a high level, we'll get into the implementation details with a real-world example.

You can find...

Application code is likely the area of most interest and the layer that has the most changes from a traditional web application hosted on a managed server, so let's start with that.

Presentation layers are not necessarily the most exciting area but, in reality, they are the entry point for your entire web application, and you should think through the details carefully. Naive deployments of HTML, CSS, and JavaScript files may result in slow load times, which has a noticeable impact on user experience.

When building serverless systems on top of AWS, there are a few different services that enable us to host static assets quite easily. Other PaaS systems have similar offerings, although there may not be a one-to-one comparison with all of the AWS services.

It's safe to say that most web applications today have some data store, whether it's a relational database (PostgreSQL, MySQL, SQLServer, and so on), a non-relational database (MongoDB, Redis, Cassandra, and so on), or even static file storage (S3, OS filesystem, and so on).

AWS RDS service will manage aPostgreSQL database for our coffee cupping application. RDS offers different RDBMS choices, most notably PostgreSQL, MySQL, Oracle, and SQLServer. There are other choices, and I encourage you to take a look at the various offerings. For this exercise, we'll be using a standard PostgreSQL database hosted on RDS. Many configuration options come with RDS, which we won't cover. Just know that it's possible and quite simple to run, configure, and manage a high-availability RDBMS instance using RDS. Other PaaS providers offer similar services for relational databases.

Since we've covered the overall design and different layers, let's get down to the implementation of our application code.

import sys

from pathlib import Path

# Munge our sys path so libs can be found
CWD = Path(__file__).resolve().cwd() / 'lib'
sys.path.insert(0, str(CWD))

import simplejson as json

from cupping.handlers.session import (
        handle_session,
        handle_session_detail,
)

from cupping.exceptions import Http404

CORS_HEADERS = {
        'Access-Control-Allow-Origin': '*',
        'Access...

Now the fun part, we'll deploy our REST API using the Serverless Framework. At this point, we have not discussed the various configuration options when implementing serverless architectures on AWS. I'll cover different possibilities, and our particular configuration, later on in this chapter.

My pattern of using Docker as a build and deployment tool makes this process a bit easier. You are not required to do this, and there are likely other ways to make the process even simpler.

We will do all package building and deployment from inside a running Docker container, which I start and enter with the following Makefile target:

brianz@gold(master=)$ ENV=dev make shell

This equates to the following Docker command:

docker run --rm -it \
        -v `pwd`:/code \
        --env ENV=$(ENV) \
        --env-file envs/$2 \
        --name=coffee-cupping-$(ENV) \
        verypossible/serverless:1.20.0-python3 bash

There is nothing magical here. We're starting up a Docker container from...

Many frameworks for working with AWS serverless architectures expose access to CloudFormation, AWS's tool for managing multiple related resources as a single entity. The Serverless Framework is no different and, in fact, the CloudFormation interface is verbatim CloudFormation templating with a few nice add-ons specifically for variables, environment variables included. A common theme here is that this is a huge topic and the details are out of the scope of this book.

CloudFormation creates the RDS instance on our behalf with several lines of setup in serverless.yml. Details aside, note how there are multiple references to ${env:VPC_ID} and other calls to ${env:}. The ${env} syntax is a method for pulling variables from the environment that exists in the Docker container from our process of starting up the container. You may accomplish the same thing on your host system provided you have a way of managing environment variables.

Much of the complexity of this...

Setting up an S3 bucket and CloudFront distribution to host static media isn't complicated and, in theory, we could add this to the Resources section of our serverless.yml file. The ability of Serverless to manage so many resources via CloudFormation is a slippery slope, since setting up systems can quickly become an exercise in learning and debugging CloudFormation. Another downside of a growing Resources section in the serverless.yml file is that deployments will take longer and longer. It's possible to only deploy application code during development, which results in single-digit second deployments; but when some system resource is updated, including environment variables, the entire CloudFormation stack needs to updated.

Rather than creating the S3 bucket and CloudFront distribution via serverless.yml, we can use a separate CloudFormation template designed just for this purpose. Another reason for splitting this out into a separate step is that this layer rarely...

With everything in place, we can now upload our frontend assets to S3. We won't review the actual frontend React code, but if you're curious, you can take a look at that UI code in the GitHub repository at https://github.com/brianz/serverless-design-patterns/tree/master/ch2/ui.

Using the preceding aws s3 cp command, a final production build of the frontend code is uploaded to S3 and ultimately serves the content as requested by the CloudFront CDN. When the first page is rendered, a request is made to our serverless backend to get a listing of all coffee cupping sessions:

Since we're responsible developers, we have written a full suite of unit tests for our application. For now, tests are run manually inside our Docker container. The Docker image used has py.test installed, as well as some coverage tools.

The only dependency to running tests is PostgreSQL. Docker again makes it very simple to run a PostgreSQL container and hook it up to our application container. Multiple strategies exist for this, from running Docker Compose to merely starting up a container with docker run and linking the containers manually. For simplicity, I use the latter option. See the targets in the repository Makefile for details.

To run tests, inside the container, we execute make tests. I have trimmed much of the output for brevity and clarity:

root@d8dd5cc4bb86:/code# make tests
py.test --cov=serverless/ --cov-report=html tests/
Connected to: postgresql://postgres:@cupping-rltest-postgres:5432/test_cupping_log
........
==== test session starts ====
platform linux -...

Inevitably, there will be multiple deployments when developing an application such as this, and even once the first production version has shipped. Serverless speeds up this process dramatically, and once you experience the increased velocity, you may have a hard time going back to your old ways.

A deployment with the Serverless Framework consists of one command with a couple of variations.

# serverless deploy -s $ENV

In this chapter, we walked through the entire process of creating a three-tier web application with a serverless architecture consisting of a view layer, data layer, and application layer and which is powered by AWS Lambda. All services employed in the example web application are from AWS, and none require managing a virtual machine or operating system directly.

Readers should have a good understanding of the advantages of such a system and how to start the process of structuring their application using this pattern. I presented several helpers and shortcuts that should aid readers in speeding up their development.

In Chapter 3, A Three-Tier Web Application Pattern with GraphQL, we will work through a similar pattern by porting the example application from a RESTful interface to a GraphQL interface.