Serverless Django with Zappa Course Overview

Video Course - Serverless Django Applications With Lambda

Let's explore what Serverless is and isn't

Why Go Serverless? Understanding Zappa's Benefits

About the Author

Class Details

Introduction

We establish the necessary AWS credentials

Creating and Configuring an AWS Account for Zappa Deployment

Let's create a reliable development environment

How to Set Up an AWS Lambda-Like Environment with Docker

Understanding the Basics of Django and Zappa Development

Activating the Environment

Getting Started

Setting Up a Zappa Development Environment

How to Deploy a Django App to the Cloud with AWS Lambda

Serverless projects sometimes need changes

What You Need to Know About AWS Lambda Deployments

Dive into Zappa

Serving static files is different in Serverless

Django Tutorial - What are Static Files?

Two Ways to Handle Django Static Files

Serve static files directly from your project

Configuring WhiteNoise with Django for Static Files

How to Set Up S3 Buckets to Serve Static Files from Django

Final thoughts on static files

Hosting static files

A Quick Overview of HTTPS and Custom Domain Names

Setting Up a Domain Through AWS Route 53 for a Django App

Some hints for those not using AWS services

Not using AWS services

Domain Handling with Zappa - WWW and Non-WWW Options

Custom Domain Names

Creating a Cloud Database and Connecting It to a Django App

A Detailed Walkthrough for Creating Your First RDS with AWS

Connecting a Django App to a PostgreSQL Database

An Introduction to Creating Django Models [with Examples]

Final thoughts on databases

Connecting a Database

A Primer on Securing Serverless Apps in AWS

Creating a Virtual Private Cloud in AWS for a Relational Database

Securing an AWS Virtual Private Cloud for Django Deployment

Get Ready for Production

Whether you are a solo developer working on your next startup idea or a team of folks working with Django, this course shows you the way to simplify your operations overhead while saving money.  The open source Zappa utility paves the way to migrate your Django application away from old-school servers and onto the AWS Lambda serverless platform.  It's almost like having your own private Infrastructure team!

No need to watch for OS security patches or tweak Apache settings -- just focus on delivering value to your users.  All this with minimal changes to your Django application.  Leverage the power of AWS to rapidly respond to spikes in user traffic, while saving money by only paying for the web requests actually needed.

For folks ready for serverless Django, this course covers:

* Which Django apps are best to migrate and how to prepare them
* Configuring a generic and portable development environment easily set up by new developers in minutes
* Deploying and updating your code to AWS Lambda
* Best practices in serving Django static files
* Leveraging AWS services to secure your site with HTTPS and your own custom domain name
* Learning how to configure a secure network environment in AWS VPC
* Connecting your Django application to a hosted RDS database

All this while leveraging the AWS Free Tier.  While there are some lessons that may have additional cost to complete (e.g. bring your own domain name), the vast majority of this course will be using the AWS Free Tier and won't cost anything.

It's taught by Edgar Román. I was introduced to Django in 2009 and I consider it my go-to web framework. With continuous support from a vibrant community in addition to an incredibly rich ecosystem, I would be hard pressed to find another framework that matches up.

I've been using Zappa to host my Django applications for several years now, and I have found no other solution that is as powerful and cost-effective as serverless Django hosting on AWS -- especially for the solo developer working to get a product to market.

I hope you enjoy this course and harness the power of serverless Django with Zappa in your projects!

Learn how to migrate your Django application to a serverless environment hosted by AWS Lambda.

Serverless Django with Zappa

How to migrate your Django project to the AWS serverless environment

Adapt your code to changes necessary for running in the cloud

How to setup a reliable and consistent local development environment for serverless projects

How to setup and connect to a hosted RDS database

Learn about setting AWS IAM permissions for serverless projects

How to map a custom domain name to your Django project

Effectively serve Django static files via S3 or AWS Lambda

How to navigate the AWS Console to host multiple domain names

Learn about setting up a secure network environment using AWS VPC

So now that we have our first deployment operational, we should reflect a bit on this new environment. First, remember that when there is no web traffic, your project is not doing any work and you will not be charged by Amazon.

When your deployment is very busy, then AWS Lambda manages instances for you, scaling up as traffic increases and then scaling down when traffic decreases. The best part about this?

Your dev and QA environments hardly cost anything, but your production environment can scale up to handle lots of traffic.

The first time you invoke your function, AWS Lambda creates an instance of the function and runs its handler method to process the event. When the function returns a response, it stays active and waits to process additional events. If you invoke the function again while the first event is being processed, Lambda initializes another instance, and the function processes the two events concurrently. As more events come in, Lambda routes them to available instances and creates new instances as needed. When the number of requests decreases, Lambda stops unused instances to free up scaling capacity for other functions.

At some level of traffic, it may no longer be cost-effective to keep using AWS Lambda, and it may become cheaper to use EC2 or another service. Your business may vary, but I would say it would take a fairly large amount of traffic to cross this threshold. While the prices may be slightly outdated, 

 provides cost breakdown for a low traffic site.

AWS Lambda charges by a chunk of requests and also by the duration of execution time - measured in milliseconds! So we want our Django app to finish quickly.

Using Django in AWS Lambda makes a lot of sense since most web requests are not long-lived and finish quickly. Think about it, 

users browsing the web get upset if a page takes more than 2 seconds to load

Each AWS Lambda invocation has a time limit on how long it can run. It's configurable from between 30 seconds and 900 seconds (15 minutes). By default, the Zappa utility sets the max execution time to 30 seconds and after that limit, the function is terminated. For most web requests, this is completely fine - who would wait 30 seconds for a page to load? Also, the AWS API Gateway has a 30-second timeout; so for all web requests, 30 seconds is the effective maximum.

However, there are some circumstances where you need your AWS Lambda invocation to exceed 30 seconds. For example, you could be running a management command or doing some backend processing. If you'd like to modify the execution timeout, use the 

Another challenge AWS had when designing this service was to make sure no Lambda was using too much disk space. The limits for typical Zappa projects are:

---
title: What You Need to Know About AWS Lambda Deployments
description: Serverless projects sometimes need changes
privateVideoUrl: https://fullstack.wistia.com/medias/2zcp01y6n5
isPublicLesson: false
code: https://gitlab.com/fullstackio/books/newline-course-apps/edgar-roman-serverless-django-with-zappa-app/-/tree/main/code/module02/module02-all-lessons?ref_type=heads
---

So now that we have our first deployment operational, we should reflect a bit on this new environment. First, remember that when there is no web traffic, your project is not doing any work and you will not be charged by Amazon.

## Scaling

When your deployment is very busy, then AWS Lambda manages instances for you, scaling up as traffic increases and then scaling down when traffic decreases. The best part about this?

**Your dev and QA environments hardly cost anything, but your production environment can scale up to handle lots of traffic.**

From the [AWS Docs about Lambda Scaling](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html):

> The first time you invoke your function, AWS Lambda creates an instance of the function and runs its handler method to process the event. When the function returns a response, it stays active and waits to process additional events. If you invoke the function again while the first event is being processed, Lambda initializes another instance, and the function processes the two events concurrently. As more events come in, Lambda routes them to available instances and creates new instances as needed. When the number of requests decreases, Lambda stops unused instances to free up scaling capacity for other functions.

At some level of traffic, it may no longer be cost-effective to keep using AWS Lambda, and it may become cheaper to use EC2 or another service. Your business may vary, but I would say it would take a fairly large amount of traffic to cross this threshold. While the prices may be slightly outdated, [this blog post](https://medium.com/@bezdelev/cost-breakdown-for-a-static-website-on-aws-after-18-months-in-production-d97a932d2d25) provides cost breakdown for a low traffic site.

## Execution Time

AWS Lambda charges by a chunk of requests and also by the duration of execution time - measured in milliseconds! So we want our Django app to finish quickly.

Using Django in AWS Lambda makes a lot of sense since most web requests are not long-lived and finish quickly. Think about it, [users browsing the web get upset if a page takes more than 2 seconds to load](https://designingforperformance.com/performance-is-ux/).

Each AWS Lambda invocation has a time limit on how long it can run. It's configurable from between 30 seconds and 900 seconds (15 minutes). By default, the Zappa utility sets the max execution time to 30 seconds and after that limit, the function is terminated. For most web requests, this is completely fine - who would wait 30 seconds for a page to load? Also, the AWS API Gateway has a 30-second timeout; so for all web requests, 30 seconds is the effective maximum.