Serverless Django

Thank you everybody. Hello? Can you hear me okay? Albums are good? Okay, great. Hello. My name is Rich Jones. I'm the founder of gun. io. Ask me how afterwards. Plug is over. I'm also the author of Django Knockout Modeler, Django Easy Time Zones, Django Easy Time Zones. Easy Split, Django Easy API, a bunch of other Django packages you may have encountered in the wild. But today I'm here to talk about serverless Django using the Zappa framework. This talk, if you haven't able to tell already, is going to move pretty fast. I believe that it's kind of better for people to be overwhelmed

than the board. Uh if I don't make any sense, at any point feel free to interrupt, ask questions, yell at me, tell me if I'm wrong or whatever. I I you know That'd be great. Ask a question. Yeah. First question you're probably wondering, what does serverless mean? This is a big buzzword that's going around. You've probably all heard it. In our context It's going to mean no permanent infrastructure. We're going to be using these cloud services in particular called AWS Lambda and AWS API Gateway. There still are servers. Serverless is just a buzzword marketing thing. The key difference here is that the servers are ephemeral.

So with a traditional web server that you're probably used to for your car and Django deployments, you have a web server like Nginx or Apache that's constantly listening for new requests as they come in. It'll then turn the incoming request into a whiskey environment. That whiskey environment gets sent to your whiskey server like to Unicorn or UWSKI. Django then processes that whiskey response. It gives it back to the web server, which gives it back to the client, which then goes back to the list. The problem with this model is that if you get a surge of requests, they form a queue. And if you have the queue too long, then the requests that come in at the end don't get processed in time so the

user receives uh you know a timeout response and what that goes down. With Zappa , the request from the client comes in through the API Gateway service. This g then gets mapped to a normal dictionary using this uh horrible thing called VTL that I learned so So that you don't have to don't even worry about it. At that point , the server gets created. The server, Zappa , this and then converts that API gateway mapping into a normal whiskey object, feeds that whiskey to Django. Django processes it like it normally would Returns the response through the API gateway. At that point the server dies

and uh API gateway returns that response to the client. That whole process takes about 30 milliseconds. By the time the user has actually has received the page, the server that sent it has already disappeared, which is pretty sad. Like there is no downtime because the server server is always down. So there are a ton of advantages to this. The first one right off the bat is it's super scalable, out of the box. So each request corresponds to one temporary microserver. But that also means that 10 simultaneous requests are 10 simultaneous servers. just keep adding zeros and it goes all the way up. So you can serve literally,

we'll show you by the end of the talk, how to build applications that can serve trillions of events. Another advantage is that it's also orders of magnitude less expensive. So with AWS lambda, you pay by the millisecond of time that you need And it's 0. 000000002 milliseconds. So if you uh you know if you optimize uh properly, you you end up pay pretty much nothing. You also, if you're a first-time user or you get, you know, you talk to Amazon, you can get a ton of seconds for for free and other purposes for free. So just as an example, for my own personal projects, previously I was running on four Digital Ocean

like Lino, whatever Heroku drops uh for various projects that I was running and it was costing me almost a thousand dollars a year. I converted them or just re -converted deployed for using Zappa uh and now I'm below the free tier so it saved me a thousand dollars a year right off right off the bat just for my own personal stuff. So if you use this for your clients they're very happy or use it for your clients to your company they'll be very happy. There's zero maintenance. Because the servers are never up, you don't have to maintain anything. Uh is zero load balancer, you don't have to run a uh a load balancer, you never have to worry about that again. You never have to worry about patching the operating system. Um you still have sort of you know make sure that your application is secure. See my CCC talk on hacking

serverless architectures if you want to know more about that. But you don't have to worry about maintaining the ops. And again, there's no downtime because it's permanent downtime. What else can the framework do? Um so it also enables you to do this cool stuff called event driven architecture, which is also very buzzery but But this one is actually very cool. And we're going to show you how to do some cool stuff with that later on in the talk. But basically it means that the code will execute in response to not just web requests that come in but other events that can happen in your ecosystem, such as somebody submitting a file upload and triggering uh you know data processing of that, uh responding to income emails

or text messages or database events or user events that occur inside of your you know your system. That's cool, but you want even more features Because you guys are so needy. Uh but you're in much, because there's other cool features that we're gonna blast through, like rollbacks and free SSL, and uh common log tailing and It has auto keyboard. It works with all your favorite uh C extensions because we compiled everything so you don't have to. It works with all like hundreds of uh packages already that you already use. You can use environment, you get you know 12-factor encrypted remote environment variables. It works with your s your CI system. You can just Invoke any function in your thing, just directly, just type invoke and then the name of it and it'll execute that

that function remotely. You can even just type in raw Python and then have that execute. in the on one of these lambdas automatically. It has a nice Django integration, of course. So you can do Zappa Manage and then any of your favorite Django management commands. and it'll invoke that remotely. Secure deployments, just add it, you know, set your API key. There's a couple different ways you can do it. You don't need to modify your existing apps whatsoever because It speaks Whiskey. There's no vendor lock-in, so unlike all the other uh serverless frameworks out there, because it speaks this magical thing called Whiskey that only Python has. You can take your uh your uh

your Zappa application and you can move it back to your uh colo or whatever if you don't if you don't like it. You're not locked into anything. It's battle tested at this point. I know it's used in production by a bunch of banks and governments and medical companies. It works with any whiskey application, so Django, it works with all your favorite CMSs that you're probably using. Flask, pyramid, bottle, hug, all these other ones. This guy used it and saved a bunch of money. He didn't have to do anything, so that's cool. Thanks for Good on you, Spencer. Um it's super duper easy to get started. So all you have to do is inside of your virtual environment, you do pip install zappa. used to doing this for a bunch of other packages, I'm sure.

And then you call this function called Zappa init. This is gonna bring up a cool DBS like look at old school SPR, uh then you're gonna answer a bunch of questions uh about how you want to Your deploy to look. It's going to print out a settings file. So this says this if we want to deploy this, our dev environment to USD1, which is in Virginia, I think. It'll automatically detect your that it's a Django application and this is the path to your settings file. It'll use the AWS credentials file that it'll detect from your system and it'll uh automatically create an S3 bucket to upload your code. Then you call

Zappa deploy. Under the hood, this is then squishing your whole squishing and optimizing your whole project into a lamp -compatible format. It's replacing all of the dependencies. that you have in your in your projects to make it work on Lambda. It adds the middleware layer that we talked about to convert to whiskey. It'll upload that package so that Amazon has the code, it'll register the function, it'll register and configure the API gateway, it'll then get rid of the code so it's not you're not paying to have it sit around on S3 anymore and then it'll create this key warm event that'll make sure that your uh lambdas are always fast to return. So you just this is it just from zap deploy, that's it.

And then uh boom, you're serverless. It's that simple. You didn't have to do anything. You now have an infinite scalable, uh uh you know, super cheap uh deployment of your application. Uh with with a single uh single command. Only didn't actually quite work because on Django uh there's this disallowed hosting. So it's not very fun when you deploy you immediately get an error page. Django is less tolerant, which I guess is a super usual feature. So there's a couple of Django gotchas that we're gonna go through. uh real quickly. The first one is this allowed hosts thing. So we're gonna put in the

the uh automatically generated endpoint URL uh for our dev environment or if you're operating off the domain or subdomain which I recommend it just makes more sense to do it that way. You put that into your Django settings file and then call zapple update and then you'll see your hello world page which is cool. The second gotcha is static files. This is always kind of a pain in the butt no matter where you're deploying to. You go to the admin page, you see this kind of like the fall styled thing. The solution is what we already saw in the lightning talks yesterday. It's this cool project called Django storages. Josh is here, but told me that he wasn't gonna come to my talk because he's working on his.

So no thanks, Josh. So you add this to your installed apps. You configure it, all this is saying is like use it, pretty much. Um then we call collect static, which you're probably already familiar with, um update so that the deployed code is using it, and then you know all of your uh cool uh static assets are working. Yay. Um another gotcha. This is the big elephant in the room with serverless. uh is the database. Like at some point at the end of your application will need some permanent infrastructure maybe in the form of form of uh a database. Uh this is kind of tricky. Uh

another but you actually you're all laughing Why are you all laughing? That's a serious question. Do you actually need a database? So in a serverless environment, can you replace having permanent infrastructure with ephemeral infrastructure? Can you use cues? Can you use static storage? Can you use notification services, stuff like that? Try to avoid permanent infrastructure wherever possible. So an example of this is another library I wrote called NoDB. which is an incredibly simple but sort of clever way of replacing the need for database with static storage. So you can just in you know two lines of code.

Uh it's sort of clipped off a bit there, but basically just no dv. save, no db. load, and you have permanent uh object storage of any Python object uh that you never really need to worry about maintaining a database. Another example of of how performant this this path would be is so I've written a BitTorrent tracker that deploys to Zappa that doesn't have a database but can still out of the box scale to serve millions of users, like the same size as the Pirate Bay, for you know really no cost. um and without the database at all. Um because it's really fun. But because it's a Django Con, we love the ORM and we actually do want a real database. show you how to set

how to set that up anyway, begrudgingly, even though this is kind of a pain in the butt. You have two options here. One is to use Amazon's RDS service which is their hosted database. Or you can set your own up on EC2, which will save you money, but then you have to maintain this infrastructure. If you just use RDS, then they kind of handle everything for you so it's like I don't know. But we're going to use RDS because it's easier and it's kind of a more pro thing to do. The other thing that we mentioned was the virtual private cloud, even if I didn't mention it and now I have. What is that? Great question. Super long answer. The TD TLDR is that it's a virtual network inside of your AWS

ecosystem. with strict security policies. The point of this is to prevent random Uber internet traffic from poking in on your database and your queues. and other cool stuff that you have in your uh Amazon cloud, but also allowing traffic internally so that your Lambda functions can access your database. There are a lot of patterns that you can use here. There is no one size fits all. It's gonna depend on the needs of your organization. So talk to your ops team about like what this is going to look like for you. The basic setup that you're gonna need to deploy a Django application with a database

is, and you can configure this just with a couple clicks in the web console. We have a single virtual private cloud with two private subnets. You're gonna have two in case one of them fails, your application will still work. And you're gonna allow traffic to inside of the subnets on port 5432 if you're using Postgres. If you want to access stuff outside of your private network, using third-party APIs, you're going to need to add a public subnet or two public subnets and a NAP which gives them addresses so you can talk about it. to other things. It's a like I said, it's a couple of clicks in the in the dashboard. It'll take two minutes, but make sure

you talk to whoever's In your Django settings, the init function spat out, you're just gonna add the information that you copy about the BPC. That's another uh field. Um now you have a database and your lambda can access that database. How can Django talk to it? Uh you don't need need to do anything particularly special here. RDS will give you an address that you can copy and you post it, paste it into your databases setting like you do with any other database that you're deploying with um the issue here is now that because our database is inside of this virtual private cloud, if we're you know in a coffee shop or whatever trying to work on it

We can't access stuff inside of a virtual private cloud from uh outside of it. So what we can do is create a new management command. uh in Django that will allow us to like update and then execute database initialization from with inside the virtual private cloud. You actually don't need to create that because I did it for you just now and created a package called Zapajjango Utils which will do all the common stuff that you want to do in Django without having to do anything special. So just pip install is a zappa Django utils , add it to your project, call update, and now you'll have this new management command available to you that will automatically create the database. and tables for your project

from within inside Lambda. So you can access this private resource without actually being physically inside of the virtual private project. And then you can do your normal make migrations and then you run the migrate command from with inside of the virtual private cloud using that. Similarly, you want to create a new admin user. Previously what I was recommending is that you did this invoke raw thing that's like I'm not going to make you copy this anymore. So you can just do zap would manage create admin user. So then we have a default user. We can log into our Django application. running uh uh on lambda and now it just operates as if it were any other regular deployment. Sweet.

Um Um the final this one isn't really gotcha, it's super easy. Zappa does support Let's Encrypt. We'll give you free SSL certificates that will auto-renew for your subdomain. Amazon, in response to the awesomeness of Let's Encrypt, offers their own free um uh alternative now called ACM M Zone Certificate Manager that does the same thing. Um because it's you know Zappa uses both. ACM is super easy to set up. You just copy a single ARN of the network location of the certificate or the Amazon location of this

the name of it, you put it into your uh zappa settings, you call Zappa certified, and now your domain It will automatically set up the network traffic, the DNS stuff for it, and give you the SSL certificates that will then auto-renew and it's free. So you get free SSL, we're super alive. So what about the events? Alright, event-driven architecture. This is the fun part. That stuff, you know, great, you have free infinitely scalable, super cheap, hosting your Django, whatever. Let's do event driven architectures, because then you can put that you know that on your resume and get a race. The basics is that we're going to be executing code in response to events that happen inside of your AWS ecosystem.

So in practice, this is going to be I mean no blocking pages on file uploads and we don't have to manage any queue system like Celery. I all respects to the People who wrote Celery, if you're here, I despise celery for maintaining it. Part of the like the motivation for this project is just like I pulled all my hair out when trying to celery. So we're not going to use that anymore. So here's a practical example that you could uh that you can use uh uh for avatar resignment so if you have um you know uh multi-user app whatever and you allow your login users to upload uh uh any image they want for their for their little picture on the site, we want to make a

thumbnail image automatically. So the architecture of this, you know, a little serverless pattern is the user from the browser is going to make an upload directly to S3 Because there's a new object in our S3 that will allow our Lambda function to execute, and then we're going to return the processed image back into S3 and set it in the database that they have a thumbnail. So the code is super is pretty simple. The only thing, the magic thing here that we really need to know is that the event comes in this format. where they're uh where it gives us the key. So we take in we define any function that takes in an event of a context object

and it's gonna have this you know uh nested dictionary format. We're gonna get the key information. It'll show where they uploaded the file to. We're gonna process it. We're gonna download it. We're gonna download it to the temp directory because that's the only only uh writable environment that we have, uh then we're gonna resize it, then we're gonna put it back on S3. In your Zap settings file, uh you point in the events key, uh point to uh the function that you that we just made so process avatar in the users. util package. And then we're going to define the event source that anytime An object is created on inside of this S3 bucket that we defined. We're going to execute this code. And then finally we're going to call Zap

the schedule that will register all of the events that we want to execute. skewed in response to. That's all you have to do. One thing to watch out for in here is make sure that you don't get stuck in an infinite loop. So if you're putting something back onto S3, make sure that uh you don't do it in such a way that that re-triggers the same event because then all of those cost savings that we got earlier will quickly start to diminish. So two ways you can avoid this are either to have two different buckets, one for uh uploaded information want the processed information, or you can just you can set the path of where the newly created object goes through Second example that will be practical for us.

So in addition to S3 events and email events, whatever, time is also an event source that we can use. So let's say for this example we want to send a daily notification to our team's Slack channel with statistics about what's happened in our ecosystem. So we're going to define a super super simple function. We're going to use the Slacker package. We're going to calculate how many objects, how many new users objects. We're created in the last 24 hours and we're going to send a notification to our Slack channel saying this happened. So it's two lines of code. Super. And then in our settings file, rather than say setting

the S3 location as the event source, we're going to use this rate function that will set say execute every 24 hours call this um call this function that we define. We're going to schedule it using that to schedule and then it's going to show up in our selection. It's that easy. You can use uh cron and rate syntax if whatever you prefer. You can schedule as many functions as you'd like and it'll work. You can do really good complex stuff here. But what if you don't want to wait for the events to happen? You can also execute functions asynchronously inside of a different lambda from your lambda. So why do you want to do this? In case you're picking, okay, so let's uh

Let's imagine that we have a super simple function that takes a little while to run. So we're going to get our cake ingredients and we're going to bake cake, and we're going to you know return it somehow. Let's let's imagine that this function takes five minutes to run. We can't bake the cake in response to an API response normally because it If uh we're expecting a five-minute operation to occur in the span of a single H request, it's gonna time out and you're never gonna be able to deliver like A So what we can do is use zappa. async task. All we have to do is wrap our, okay. is wrap our cake

baking function uh with this task decorator and then at the URL at the API endpoint uh just call the the bake cake function as we normally would. And now what this is gonna do, uh it'll return the your cake is being made message immediately and then in a complete completely separate uh server, uh ephemeral server, you know, Lampha server, it's gonna bake that cake for us. So we don't have to do anything other than it's a single decorator. Like normally you'd have to configure this and post a cue and salary, which I hate. We don't have to do anything. It's one it's one letter coke. Who knows? Make as many, you can make literally trillions per case. It has four we uh

that we just showed you uh I don't have a ton of time left but I want to get to questions so this is gonna get if you like I'm gonna blast through the hard like the hard stuff right But just bear with me. You can go back and we can look at the slides later. You can talk in the hallway. What if you need to make mission-critical cakes for the entire planet? Um, so we're going to talk about globally available serverless architectures. This is the This is the fun stuff. This is, you're not going to see this anywhere else. That sounds cool. Why do I want to do that? You might not need this for your first Zappa deployment app, but it's going to be cool for you guys to be aware of the capabilities. that you could that you could do with this. So the benefits of global deployments are redundancy. So the cloud

cloud computing is an active fate. Amazon does go down too Like it happened pretty it happened this year, it happened last year, but usually doesn't happen across the whole planet all at once. It'll just be uh you know one of the regions will will go down. Pro tip , if you were a company, don't host your SP. So they're supposed to see this little red nothing's working. but because they hosted this little red thing on the thing that wasn't working, everything was green and everybody went crazy. Number two reason that you should do this is speed. So um From my apartment to Ohio takes 40 milliseconds, from my apartment to Tokyo takes 200 milliseconds just to get there. That's you know without the response or

the SSL handshake anything like that. So the earth is big. We want to provide all the users in different countries with the same level of service that we provide in the United States. Scalability is another reason to do this. Let's say you have uh 5,000 simultaneous connections in one region and then if you you know deploy that globally to nine different regions and you get 45,000 connections. That's trillions of hits a year that you can handle out of the box now, which is cool. When's the last time you saw uh trillions with security? Uh because it's in different regions, uh I'm gonna blast through some of this because it's in different regions you have access control you can prevent non-US uh employees from accessing US data. This big topic. I'm not saying that

Similarly, regulatory compliance, different countries have different laws, especially regarding medical, financial, personal identifying information. communications data retention and stuff like that. So you you'll want to have different deployments of different policies and different access controls if you're dealing with medical information in an in international environment. Um I'm not your lawyer. Uh you don't want me to be a lawyer, but you'll may need this to talk to you a lawyer about it. How do you do it? Uh super easy. Remember that zappa init command that we set up with? One of the questions that it's gonna ask you is Do you want to make this a global application? All you have to do to do all this cool stuff is hit Y. Generate uh unique mouse for every one of your uh uh cake businesses for different regions around the world and then deploy dash-all, certify dash-all, and then now you're you've deployed your application uh to

nine different regions around the globe uh simultaneously. It's it's super easy and yeah you'll get less than you know for the example for a cake example it's less than 200 millisecond response time for anywhere in the world to make a cake. But you have to make a decision on routing policy. You can because you know there's different cables I and put them there, they're all hooked up and we have to figure out how to uh actually wrap this uh route the stuff. You can only do it based on latency, so just use the fastest region from where your client is visiting or you can use geolocations to say like if they're in Japan send them to the Japanese data center no matter what. These are just check boxes that you set in the in the route.

If this is useful for you, let me know if this should be rolled into a feature in the zapp article itself. Final elephant in the room is a database. If you have a globally deployed database, you're going to want to use this thing called the read wrap lookup so you have one primary database um that takes in all the all the rights and then the globally distributed read replicas that just make a copy of that primary database around the world. So your reads are coming from a single local source. Your writes are going to the one centralized server that means that your your reads are going to be super fast because they're coming from the same region. Your writes are going to be slow because they have to go to the the the one that's probably in New York no matter where they are.

Django is capable of handling all this stuff for you out of the box. In your databases uh setting, you'll define all the different uh find your your primaries and your replicas. And then you'll have to create a class called router that will respond with based on the actual Django model that you're using. You can route that to the different database everywhere in the world that you'll need. And then there's one more setting to install your routers that we just made inside your Django set. So that way we get fast local dates because they'll be reading from the local database, slow local writes.

The tip for that is use Ajax. So have your you know when the client saves the form because that's going to be slow don't have the the page block on it do it with javascript uh so they don't get that like stuttering effect um as they as they have button. In conclusion, oh man we did it. We got something stuck. Cool. Save time and money, build awesome event-driven applications, never have any downtime, be fast everywhere in the world. Use Zappa. All your favorite companies are already using Zappa. It's been explosive growth of the project in the past 18 months. It's super cool. the community is awesome. If you want to contribute, we already have over 100 plus contributors, which is the

statistic that I'm most proud of for this. contributors as of five minutes ago um from six continents. If you have penguins that live in Antarctica, I would like to get that up to seven so please are um the ways that you can help number one is just use it um there's it's full bugs and I'm I'm sure you'll find them. Slack channel and report the bugs that you find. And then I will tell you to fix the bugs that you find. I also need help just triaging pull requests. There's a a ton of old PRs that are like 90% of the way there that just need like a little bit of help getting past the finish line. Python 3. 6 support just came out. I don't like Python 3. 6 Sorry.

If somebody here really does like Python 3, having somebody commit to being the maintainer of the Python 3 packages would be super useful. Similarly, if any of you are Windows users, I I don't have a Windows machine anymore. would like if somebody could step up and be uh kind of the Windows maintainer of the project. We need better documentation, better tutorials, support for non-AWS in the pipeline. That one's going to be big if anybody wants to to talk to me about that one after I've read some plans. I'm also starting to build a library of common functions. So we saw these like little snippets. If we could all build little things that are useful for us together and then share them, then these are just little tiny things that anybody can install into their ego

server. And we'll all benefit from that. So I think that would be cool thing for all of us to work on. Shouts, these are the people who support on Patreon. Special thanks to everybody in the Slack channel who helped. with the features in this talk. Do you need awesome scalable serverless apps? You should just hire me to build them. There's my email address. Sorry, I had to do it. The codes on GitHub here, we've got a Slack channel. Thank you.