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
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
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.
.svg)
.png)
