Serverless Design Pattern – DevOps

In my previous blog post, I talked about the evolution of how we got to the serverless design pattern. In this blog post, I’ll deep dive into the specifics of the design pattern.

“Never let a good crisis go to waste.”

Charles Doyle

When this COVID-19 pandemic started, I decided this was a good time to spend some time researching new technologies and not letting this crisis go to waste. I decided to challenge myself and create a full stack app during the pandemic, mind you I haven’t really programmed in 25 years! My goal was to create a dashboard that would allow a user to authenticate and then access an internal dashboard that used APIs to get data stored in a database.

One design pattern for serverless is called function as a service (FaaS). The problem with that name is it implies that only a specific part of an app can be made serverless, in reality an entire app can be made with FaaS. You might have also heard of something called JAMstack, that is another serverless design pattern and it stands for JavaScript, APIs and Markup.

With any serverless design pattern you need to think about three areas:

1. Frontend – the UI of the app
2. Backend – the business logic and database
3. DevOps – the intersection of the developers and operations team to keep the application up and running

Today, I’m going to discuss DevOps and building the infrastructure. Another feature of serverless is called Infrastructure as Code (IAC), which is the provisioning of resources using a script or definition file. By using a script you can quickly build/provision the resources you need and also quickly tear them down. Since I’m using AWS, the language they use is called CloudFormation. Simply put, it’s a language used to generate a YAML file that provisions the required AWS resources. Just like any other AWS product there are multiple ways to interact and create that YAML file:

1. Using the AWS Management Console – a good way to get started but the least recommended method
2. AWS CLI (command line interface)
3. AWS SAM (serverless application model) CLI
4. AWS Amplify CLI – a JavaScript library and CLI
5. AWS CDK (Cloud Development Kit) – the newest tool that uses familiar programming languages like TypeScript to build the CloudFormation file
6. Serverless.com Framework – not from Amazon but open-source and used by many folks

After reviewing many of the tools, I decided to use the Serverless Framework, it’s an open source tool that allows you to create a CloudFormation template. Although the Serverless Framework focuses on the backend resources it does allow you to also deploy the frontend app as well, so through this tool it does the backend and frontend.

Using the Serverless framework, I was able to provision 5 of the 6 services used in the dashboard app:

Frontend:
S3 – where the front end app is copied to. Then it gets deployed to CloudFront content delivery network
CloudFront – the static files that are accessed via the web browser

Backend
API Gateway – public facing APIs that connect to the Lambda function
Lambda – JavaScript functions that gets called via an API
DynamoDB – database where all the data resides

Although I initially focused my efforts on the Serverless Framework, I also started to dabble with AWS Amplify. It made sense since I was using AWS and the frontend was being built in JavaScript. And honestly, Nader Dabit of the AWS Amplify team is pretty much everywhere on the internet and giving demos on how easy it is to use Amplify…he is not wrong! I’ll most likely move everything to the AWS Amplify CLI before I go to production on the dashboard project.