Deep Dive Into Serverless

February 7, 2023
Ryan Jones
5 minutes to read

Cloudfront can be simply defined as a CDN (Content Delivery Network), caching your static assets in a datacenter nearer to your viewers. But Cloudfront is a lot more complex and versatile than this simple definition.
Cloudfront is a “pull” CDN, which means that you don’t push your content to the CDN. The content is pulled into the CDN Edge from the origin at the first request of any piece of content.

In addition to the traditional pull and cache usage, Cloudfront can also be used as:

  • A Networking Router
  • A Firewall
  • A Web Server
  • An Application Server

Why is using a CDN relevant?

The main reason is to improve the speed of delivery of static content. By caching the content on the CDN edge, you not only reduce the download time from a few seconds to a few milliseconds, but you also reduce the load and amount of requests on your backend (Network, IO, CPU, Memory, …).


Static content can be defined as content not changing between two identical requests done in the same time frame.

Identical can be as simple as the same URI, or as fine grained as down to the authentication header. The time frame can range between 1 second to 1 year.
The most common case is caching resources like Javascript or CSS and serving the same file to all users forever. But caching a JSON response tailored to a user (Authentication header) for a few seconds reduces the backend calls when the user has the well-known “frenetic browser reload syndrome”.

Edges, Mid-Tier Caches, and Origins

Cloudfront isn’t “just” some servers in datacenters around the world. The service is a layered network of Edge Locations and Regional Edge Caches (or Mid-Tier Caches).

Edge Locations are distributed around the globe with more than 400 points of presence in over 90 cities across 48 countries. Each Edge Location is connected to one of the 13 Regional Edge Caches.

Regional Edge Caches are transparent to you and your visitors, you can’t configure them or access them directly. Your visitors will interact with the nearest Edge Location, which will connect to the attached Regional Edge Cache and finally to your origin. Therefore, in this article, we will refer to Cloudfront as the combination of Edge Locations and Region Edge Caches.

What Have We Learned?

Cloudfront is more than just a simple “pull-cache-serve” service

  • You improve delivery speed to your visitors
  • You can increase resilience by always using a healthy backend
  • You improve overall speed to your backend by leveraging AWS’s backbone
  • You can modify any request to tailor the response to your visitor’s device or region
  • You don’t always need a backend
  • You protect your backend by reducing the number of calls reaching it

Access free book

More from Serverless Guru

Building Serverless REST APIs for a Meal Prep Service with CloudGTO

October 31, 2023
Learn More

How to build an AWS AppSync GraphQL API with multiple data sources

October 26, 2023
Learn More

Building a Secure Serverless API with Lambda Function URL and CloudFront — Part 1

October 17, 2023
Learn More

AWS CI/CD Pipeline to Deploy a Serverless Framework Project

Let's Talk

Introduction

In this article, we will set up an AWS CI/CD Pipeline to Deploy a Serverless Framework project using AWS CodeCommit, AWS CodeBuild, and AWS CodePipeline.

We will automate the release process so once developers commit code and push changes to a branch it will auto-trigger the AWS CI/CD pipeline which will then build & deploy the project changes to a specific stage.

While using AWS CI/CD services you don’t need to worry about creating custom build servers manually, that of course saves your engineering team time and money. There is no maintenance cost as you only pay when it’s running. Furthermore, there is no need to worry about scaling as it is easily configurable, secure, and highly available.

AWS Architecture

Above is an AWS CI/CD Architecture Diagram showing how AWS CodePipeline, AWS CodeCommit, and AWS CodeBuild are leveraged to deploy Serverless Framework project code changes automatically when they are committed.

What is a CI/CD?

CI/CD is the combined practice of continuous integration (CI) and continuous delivery (CD). [1]

CI/CD bridges the gaps between development and operation activities by enforcing automation in the building, testing, and deployment of applications. The aim is to increase early defect detection, increase productivity, and faster release cycles.

AWS provides a range of Developer Tools Services. AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy services are used to build a full CI/CD flow.

AWS CodePipeline

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates. CodePipeline automates the build, test, and deploy phases of your release process every time there is a code change, based on the release model you define. [2]

AWS CodeCommit

AWS CodeCommit is a secure, highly scalable, managed source control service that hosts private Git repositories. CodeCommit eliminates the need for you to manage your own source control system or worry about scaling its infrastructure. It supports the standard functionality of Git, so it works seamlessly with your existing Git-based tools. [3]

AWS CodeBuild

AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages that are ready to deploy. With CodeBuild, you don’t need to provision, manage, and scale your own build servers. CodeBuild scales continuously and processes multiple builds concurrently, so your builds are not left waiting in a queue. [4]

AWS CodeDeploy

AWS CodeDeploy is a fully managed deployment service that automates software deployments to a variety of computing services such as Amazon EC2, AWS Fargate, AWS Lambda, and your on-premises servers. AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during application deployment, and handles the complexity of updating your applications. [5]

Implement Basic Serverless Framework Project with Git initialized in local

serverless.yml

handler.js

.gitignore

Generate - package.json by running npm init

buildspec.yml

This buildspec.yml will be used in the AWS CodeBuild step for installing Serverless Framework, relevant dependencies, and deploying the Serverless Framework Project.

Deploy Serverless Framework Project Manually without CI/CD

Create AWS CodeCommit Repository

Developer Tools → CodeCommit → Repositories → Create Repository

Create IAM User and Generate Git Credentials for AWS CodeCommit

  1. IAM → Users → Create User
  2. Create IAM User with attached existing AWS IAM policy: AWSCodeCommitPowerUser
  3. IAM → User Details → Secret Credentials → HTTPS Git credentials for AWS CodeCommit

In local git repository add remote origin of AWS CodeCommit Repository

Verify pushed code in AWS CodeCommit Repository

Developer Tools → CodeCommit → Repositories → sls-aws-cicd

Create AWS CodeBuild Project

Developer Tools → CodeBuild → Build projects → Create build project

Created new build project: sls-aws-cicd-build

Source provider: AWS CodeCommit

Repository: sls-aws-cicd [Use the same repository which we created]

Environment variables Name: STAGE_NAME

Environment variables Value: staging

Build specifications

Build specifications: Use a buildspec file

Default Buildspec file name: buildspec.yml [This file we already added in our source code]

Give needful permission to AWS CodeBuild IAM role.

Create AWS CodePipeline using already created CodeCommit & CodeBuild

Developer Tools → CodePipeline → Pipelines → Create pipeline

Created new pipeline: sls-aws-cicd-staging-pipeline

Source Stage

Source provider: AWS CodeCommit

Repository name:  sls-aws-cicd

Branch name: master

Build Stage

Build provider: AWS CodeBuild

Build project name: sls-aws-cicd-build  [Use the same build project which we created]

Deploy Stage

We are skipping this stage.

We are using a Serverless Framework deploy command in buildspec.yml as part of the build step for deployment.

Verify CI/CD Pipeline Flow - On git commit push auto deploy changes

Updated handler.js

Commit recent changes and git push same into the master branch

Master branch pushed changes Auto Trigger Relevant Deployment Pipeline

Verify API in Postman - Updated changes auto get reflected in API response

Conclusion

Utilizing a CI/CD increases early defect detection, increases productivity, and faster release cycles.

AWS CodePipeline, AWS CodeCommit, AWS CodeBuild helps you implement CI/CD automation for Serverless Framework Projects which helps the development team follow standard continuous integration and delivery process.

While using AWS CI/CD Services you don’t need to worry about creating custom build servers manually, which saves your engineering team time and cost because it only charges you when it’s running, you no longer need to worry about scaling, it is easily configurable, secure, and highly available.

Sources

[1] https://en.wikipedia.org/wiki/CI/CD

[2] https://aws.amazon.com/codepipeline/

[3] https://aws.amazon.com/codecommit/

[4] https://aws.amazon.com/codebuild/

[5] https://aws.amazon.com/codedeploy/

More from Serverless Guru

Join the Community

Gather, share, and learn about AWS and serverless with enthusiasts worldwide in our open and free community.