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

Tips for Adopting & Migrating to Serverless in 2022

Let's Talk

Serverless on AWS has been rapidly maturing over the past 5+ years. Working in the space nearly since its inception, I've picked up a few things around how to adopt or migrate to serverless and some areas you should keep an eye on.

Serverless Adoption/Migration

So your company has decided to adopt serverless and you're now logically thinking about how to approach the initiative. Let's talk about a few areas.

  1. New knowledge is required, training for your team around IAC, tools, dev workflow, etc is essential
  2. Bring everyone along for the ride, change makes people uncomfortable and this can cause people to quit if handled improperly
  3. Experiment in a small way, e.g. isolated non-critical workload first

How to Address these Areas

  1. Set up training sessions internally, amplify internal voices where possible, and pull in outside expertise to further help lay a strong foundation.
  2. Set up meetings with the entire team to talk about "why" this is the direction and "how" each person plays a role in creating that future to increase buy-in.
  3. Identify a service that represents 80-90% of most services that won't cause all-out panic if/when it breaks. By choosing an 80%-90% service it doubles as an early-win, something you can train others on, and use as a blueprint for similar services.

If you want to catch a full talk from me on "Enterprise Serverless Adoption", check out this video. If you want to read more about how I think about serverless adoption/migration, I wrote a series of articles:

  1. Review your existing application
  2. Break apart your application
  3. Lift and shift
  4. Choose a deployment framework
  5. Building a strong foundation

Also, check out this article from our team on Mistakes to Sidestep When Going For A Serverless Design!

Looking to become a skilled cloud developer with a focus on serverless development on AWS? Look no further: Zero-to-Paid Professional Course

Some Other Thoughts

  1. Trust the process, accept that you most likely will build non-optimized and need to re-work early architecture
  2. Hire a couple of ringers (experts), you can speed up almost every step by leveraging outside help that already has battle scars from building production serverless applications
  3. Think fresh, use this initiative as more than a technology shift and make changes to all aspects of your software delivery from task management to culture.
  4. Find resources you can trust and share these resources with your team, people like Yan Cui, Jeremy Daly, etc.

Every Company Adopting/Migrating to Serverless is Different

  1. Cloud adoption spectrum - where are you in your cloud journey (e.g. data center, VMs, containers, etc)?
  2. Team size - how many devs need to pick up serverless?
  3. Timelines - how aggressively do you need to shift to serverless?
  4. Quality - what level of quality do you need to hit early on?
  5. Internal Expertise - how many devs are familiar with building production serverless applications?

Based on these areas you may want to lean more towards hiring outside consultants, however, if you have a small team, loose timeline, and don't need production-level quality from the onset then you may not need outside serverless consultants just yet.

Message to those Looking to Hire Serverless Consultants

My name is Ryan Jones, I'm the founder of Serverless Guru, a cloud consulting company that specializes in helping organizations leverage serverless to build production scale applications, adopt serverless, and migrate existing workloads to serverless. We have a global team from more than 10+ countries. Our team is highly recognized in the community and brings years of expertise that is difficult to match. We eat, sleep, breathe serverless development. Our team collectively niched down into serverless from the early days of the movement which will come through as we help you avoid common pitfalls.

Hiring a single person from Serverless Guru means you hire our entire company as we collaborate across projects to ensure we are delivering at the highest quality possible. Our culture is one of continuous improvement and constantly challenging the status quo meaning we don't settle into one approach and die there.

If any of that is interesting and you're curious about our experiences building production scale serverless applications, we'd love to share more on a call, just submit our contact form and we will shoot you some times. Cheers!

More from Serverless Guru

Join the Community

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