Serverless Django with Zappa

Speaker 1: Okay, good morning everyone. We're going to start this morning with a look at um running Django applications in a serverless environment and using Zappa to do all the heavy work for us. So what are we talking about? We talk about serverless. Well it's definitely not the absence of servers. They're definitely still lurking out there, and we're going to need them. It's about what runs on them, when and where. And the point is we shouldn't really care about that too much. What we care about is the code that we want to run on them. So the key thing about one of the key things about serverless is that we want to avoid having any permanent infrastructure. We once it's perhaps better described as function

Speaker 1: a function as a service rather than serverless. It's event-driven processes And these respond to events or requests coming in. They do their job as much as needed. When they're finished, they disappear. And this gives the notion of full utilization. You're only really wanting to pay for the time that you're using your your code needs to use it. And this leads then on to your costs being proportional to that execution time. You only want to pay for it's there, you don't want to pay for any idle time. And also has the advantage the faster you can make your code run, the cheaper it runs. That's one key benefit people want to use serverless for. The other one is scaling without intervention.

Speaker 1: You don't want to worry about having to plan your scaling for expected peaks in demand and The worst ones, the unexpected peaks of demand. You want to be able to have stuff always available. So with serverless, if you have Ten events, ten requests, you're going to have ten processes looking after them. If it jumps up to a thousand, there's going to be a thousand running after them. There's no idle time sitting there. That you you you'd have to pay for. So why would we want to do this in Django? Um well although these are event-driven processes, we can set a whiskey request response cycle on top of that. And that's something that Zappa is going to help us with.

Speaker 1: Why? Well, because it's there. We're all here because we like sticking things together and making them work. But particularly for low traffic experimental personal web project websites, it's relatively easy to deploy in this way, get something up quickly. Doesn't have to be on all the time just when you want to use it. Relatively low running costs in that model. But also then for bigger production sites, you've got potential for lower running costs, and that's one of the big draws of serverless. It sounds very attractive from a cost perspective. But also you've got this automatic scalability for peaks in demand, particularly those unexpected ones. It's a truism that when your website's the most in demand, that's also the time when it's low likely to fall over because of that demand The service there, the idea is that it'll just automatically scale and take care of it for you.

Speaker 1: So the tool we're going to be looking at today is Zappa. It's a Python package. It's got a three-year-old active code base and it's got some integrated supports specifically for Django. What it does is it takes um API gateway requests. in in um Amazon Web Services environment, turns them into whiskey requests for you to pass on to Lambda function, Lambda functional server request, and pass it back. So it looks from the outside like a normal response request cycle. So you can picture then your website becomes this little series of ephemeral um lambda functions firing off in the background. It's almost as if your website is just distributed all across the world where it's needed and when it's needed. We have a bit of database backed persistence on that

Speaker 1: because we'll see it the Lambda functions themselves are stateless. So I talked about Amazon Web Services there. That is what Zappa sits on top of. Other services are available. There's Microsoft Azure, Google Cloud Platform, and as of literally Tuesday this week, just before the conference, Cloud Run from Google went into beta that also provides a serverless stack. What we're going to be looking at here is where Zappa integrates with some of the Amazon Web Services. There are a lot of them, as you've probably seen. We're focusing on particular subset today, obviously Lambda functions, which is Amazon's um implementation of um functions as of a service. I am

Speaker 1: the identity and access management sections. That's what Zappa's going to use in order to run all this stuff. API gateway, that's our glue between the outside world and the lambda functions. And we're using S3 for various bits of uh persistence. We'll look at some other components that you would need in a uh a full stack, but not Absolutely critical. RDS for different kinds of database backing. Virtual private clouds we'll look at briefly, mainly in terms of cost implications there. We've got things like Route 53 and Certificate Manager if we want to put custom domains on that. So to get you started, if you want to do do this in an experimental way, AWS give you a free tier if you get a new Amazon. sign up for a new Amazon account, you get 12 months of various free services to hook you into that ecosystem.

Speaker 1: Some of them, like S3 and um RDS, give you sort of database micro instance and S3 storage. The Lambda is is the interesting one. You get a million requests a month, 400,000 gigabyte seconds, so it's kind of measured in. not only the amount of resource you use in terms of memory, but also the time it runs. That's available forever and that is probably where you are looking at your sort of zero cost. part of running in a serverless stack because if you take a 512 megabyte lambda function, so memory it's allocated, you can have up to a million eight hundred millisecond requests per month. at zero cost. And that sounds very attractive because you're probably not you're doing well if you're chewing through over a million requests, particularly on your personal sites.

Speaker 1: But as we'll come to you, you need do need to factor in other costs to work out whether this is a viable production stack. So looking at lift and shift, the idea that you shouldn't be changing your Jenger application too much itself. You want to more focus on um Just getting it out there and that should just be around configuration changes necessary. And by and large in this environment, there aren't too many configuration changes to do. The main focus then is on Zappa settings, and that walks you through it, produces a JSON or YAML file in your project directory. You can create that with Zapper init and it lets you steps you through and gets you set up and going. That's largely all you need to do other than the small width of Django configuration.

Speaker 1: So let's look at it in action a bit. I'm going to risk the live demo here. We're going to create a site from scratch. and deploy it into the Lambda environment and hopefully by the next few slides it will be there. So we're gonna use Wagtail Content Management Systems Bakery Demo as a sample Django application. fairly large ish and that's going to have some sort of content added to it as part of the part of the d its demo. We're going to use S3 bucket for our static assets, using an S3 bucket to run SQLite database as the back end. I'm going to apply a custom domain to it. So what I'm going to do is I'm going to set that off running and

Speaker 1: Then go back and talk you through it in a bit more detail. So we'll leave it running in the background. So I'm just going to create this site. Fingers crossed to leave it chugging away for a few minutes. And we're gonna halt back. Frozen. Okay. Um, in case that doesn't work, there is one I made earlier that you can check out. Okay, so you won't necessarily all see this at the back, but it doesn't matter too much as

Speaker 1: this um full online walkthrough of this. This first bit of the scripts, we're doing this as kind of the barest minimum stuff we can get away with to set up this stack. The only prerequisites we had was we had an Amazon account with an IAM user ready setup. So what it's doing, it's just creating a local virtual environment on my own server, installing some of the zappa uh dependencies like Zappa. We're cloning our bakery demo. And then we're just going to do a bit of light Django configuration on that. So we're using Zappa's Django utils to provide us with a SQLite S3 SQLite backend , regular Django database configuration. We're using Django storages to configure our static assets to go to the S3

Speaker 1: bucket. We've got a little example here of plucking off an environment variable, which we'll come to in a sec. So here the meat of it here is generating the Zappa settings file. Normally you'd run that with Zapper init, here I'm just creating it from scratch with a few minimum settings. So the key few key ones there, we've got Django settings, just pointing it out at our dev settings here. We're telling it the profile name, which I am user to use to do all its work and we're telling it to build this into a particular AWS region here, the London region. Then we're doing other bits of configuration about telling it what buckets to use and where what domain we want to custom domain we want to use. And here's an example of being able to add something to the Lambda functions environment variables, in this case

Speaker 1: that debug thing that the Django settings will be able to pluck off at the other side and use Here we'll be a bit of a configuration using just the AWS command line just to create our buckets and apply some policies to them and load some content. So the really main meat of it then is what Zappa's doing itself, and that's a series of command line tools, the main one being Zappa deploy. You probably saw before there was there's various dev bits there. That just means in your Zappa settings file you can have multiple environments you can deploy to from the one project. It might be staging or production. Here we've just got a dev. So this is deploy is doing all the heavy lifting for us.

Speaker 1: It's going to take our virtual environment and our current project directory, package all that up into a Lambda compatible archive. and replace various things like version dependencies with versions that are already pre-compiled for Lambda. It'll set up various function handlers and the whiskey middleware. It's going to upload that all to its own S3 bucket that we we've told pointed it at. And it's going to create all the various IAM policies and roles it needs. It's going to register a new Lambda function for us, create the gateway to join up with the whiskey routes between the two. And it's going to do Then other little niceties for us like create a cloud watch event that's going to keep that Lambda function warm for us so that it's it never gets shut down completely and doesn't need to do a cold start which would slow down response times.

Speaker 1: So once it's done that, we're using certify here. This is just for the custom domain part that's gonna glue our custom domain onto top of what what uh to the domain that Amazon would generate for us automatically and sort out all the HTTPS certificates for that. And then because we're operating in a Lambda environment, we don't have a command line to work on. So you can't directly run your Django, usual Django management commands. So Zappa wraps up that for us. And here we're just doing all the regular things we normally do when we're deploying a Django project, we're going to collect our static stuff, we're going to migrate our database, and in this case for the demo, we're going to load some initial data. So you can wrap. any of Django's own management commands or your own management commands and run them locally via Zappa. And Zappa status there is just going to tell us if it all worked and give us our domains to

Speaker 1: look at. And then ZapperUpdate, which not calling directly here, but that's that's the step that if you were going to make some changes to your project, you would uh commit those to your repository, and then ZapperUpdate would then deploy those to your existing Lambda function. Have your new version of your site ready. So deploy itself is only used for that initial step of first creating your stack. After that, this is effectively your deploy command. So it was a quick whiz through all the details online there. So with that amount of talking, with a bit of luck, we might see something. That's looking good at this stage. So we've got API Gateway URL here. This is the one Amazon's generated for us. And you can see it's got the slash dev on the end as the script name.

Speaker 1: This is one of the reasons why it's nice to put your own domain name on because you don't have to have that on the end. Now if CloudFront is Not too s busy this morning. It will have given us some A records, which it hasn't at the moment. Normally we've got us so we won't be able to look at speed run directly on that domain. Probably by the end of the talk it will be ready. But if I look at find my mouse. I can't actually see my mouse on it. Can anyone see a mouse? There it is.

Speaker 1: Because that's the one I'm not going to remember off the top of my head Creeping in. This is for tension. Hey, we've got something. Yes, please. So that's our site if we do just prove we have got some.

Speaker 1: Django behind the scenes. Ezra Appmin. Yes, definitely a Django site. So hopefully by the end, end of the talk, CloudFront will have got its act together and created those A records we need to do to look at that site on its actual custom domain. Right, so a quick s quick summary there of kind of the workflow of what it's doing. It's going from the virtual environment, building all our bits for us. leaving us at the front end there with people being able to talk through the API gateway to these Lambda functions. I'm going to rattle through this last bit. There are various other Zappa settings we can use. There's a whole host of them that you can figure up things nicely. There's various other Zappa commands that you can use because you haven't got this command line to work directly on, things like being able to tail the log to see what went wrong.

Speaker 1: be able to invoke direct commands in the environment in the the Lambda function and then undeploy to tear your things down if you need to. So all that kind of stuff, that script work, that could all be built into your normal CI workflow for deploying sites. In terms of deploying stuff, as Apple leads quite a lot of access to various services, and if you've ever dealt with AWS roles and policies before, you know there's a lot of them. It's very fine-grained. So fine-grained it's almost impossible to work out what you need. So people often use administrator access, which is basically a root user, to do everything for you. It's actually quite hard to work out exactly what Dapper needs at the at a minimum to tune down and you end up with very long policies that go on

Speaker 1: and on and on. In fact, doing that probably took me longer to get my head around than the rest of it. So we looked in the example, the site we built using SQLite on S3, and that scales pretty well for high reads, it's surprising. It's not great for high-write concurrency. Because it's moving moving this database backwards and forwards from the S3 to the Lambda functions. So something like a content management system where it's mostly reads, possibly not too bad. If your application's got high rights, you probably want something else. So AWS provides you a variety of your choice of um relational database service , and you can get microinstances. starting at sort of $14 a week, so then immediately there there's a there's a cost on top of your sort of zero nominal zero cost for lambda for serverless.

Speaker 1: For experiments you get that free for first year. And then we're going to look briefly as well at Aurora serverless. This is um uh serverless version of of the of their Aurora database that's scales up and down on demand. That's often been uh sort of attractive people hear about that and go, oh, lower I can reduce my costs again, but we'll see that's not necessarily true. So if we want to switch out Postgres, do a bit of lift and shifting there, it's pretty straightforward. We can uh create our database cluster and database and RDS. Gives us a database URL we're familiar with. And then tweaking our environments our config is pretty straightforward. We're just going to install Psycho PG dependence. We can use

Speaker 1: database URL to pluck that database URL off our environment and configure our database for us and then we just need to remove we don't need um the S3 bucket anymore for the database. So you do that, do your Zapper updates, your Zapper Manage Migrate, and you're good to go on a Postgres back database or MySQL or whatever. Aurora service is a slightly different beast. It is tempting to go full serverless. You've got your la your your requests being run serverlessly, so it would be nice to run your your database in a serverless way as well. But it's more suited for infrequent um intermediate or unpredictable workloads.

Speaker 1: And that's because you don't actually want it running all the time. And when it goes quiet, it takes a while to come up. So it's good for occasional say big reporting jobs or for dev use where you don't mind s having a little pause, but it's not a great fit for real, you know, Django applications that are there open to the wider public. because you don't want someone waiting for too long. So when you create one of these, the usage is measured in terms of these Aurora compute units, which are sort of function of memory and CPU usage. And you set limits of the maximum and minimum you want those to run between and how long you want um it to after what time you want it to pause when it's had no requests come in on it. The important thing when if you do experiment with this and create it

Speaker 1: is that it defaults to two ACU minimum but there's no pause on it. If you don't set a pause You're immediately in for $100 a month, even if that never receives a request to it. So it's pretty vital. You set a pause, say five minutes. of inactivity it goes to sleep. And that's the critical bit because as soon as it goes to sleep, next request coming in, you've got about 30 seconds before that database spins back up. So that's why it's not fantastic for running sort of front-end websites, but it's interesting for dev or particular occasional prop projects that need to run. Another thing to mention I mentioned before about virtual private clouds, people often want to put the vi everything into a virtual private cloud. In fact with Aurora serverless you have to do that

Speaker 1: because it it's the only place it runs in, so it's isolated from the internet. That means in order to talk to it, your lambda function also has to be in a VPC. And that has then immediately cut you off from the outside world. Your lambda function can't see the outside world anymore. So if you need to connect contact your S3 bucket, it's either publishing static assets or user user-uploading content that you want to store persistently. You can use an S3 gateway. That doesn't cost you anything, so that's okay. You can talk to S3. But if you've got um your application uses third-party APIs, needs to talk to the outside world. You're going to need to go through a NAT gateway to reach it. In order to have a NAT gateway, you need an elastic IP address.

Speaker 1: Amazon will happily sell you one of those for seemingly not too bad sounding five cents an hour until you realize that's $36 a month for an IP address. And it gets a bit hard to justify that compared to thinking I can get a pretty big server for $35 a month and do whatever I want on it. So in terms of costing when you come to serverless, you have to sort of take into account these various extra factors that aren't necessarily immediately apparent. So I've got three sites running up at the moment so you can have a look at afterwards and compare and contrast what what they feel like when they're running. So we've got hopefully the speed run one will be there by now. My backup one, so that's on the S3 bucket. We've got Postgres and we've got an Aurora serverless one.

Speaker 1: In terms of performance-wise, um Postgres and Aura service pretty similar. This is a performance of the front end under load with a locust swarm hitting it. What the interesting thing for me was that SQLite on S3 actually wasn't too bad. in relative performance that was pretty good. Obviously so if you've got high rights, that's that's quite a nice solution for certainly for experiment and personal project work I do have a few minutes left. So Zappa's miscellany. So there's lots of other features that I haven't even covered yet that Zappa does for you. in a nice way. So we deployed the site to particular region, London region. You can also with a simple toggle get it to deploy

Speaker 1: to all available regions that it's capable of running in that support it what it needs. That's a nice way if you get global reach, you've got then um your response your latency is lower because people are hitting your lambda functions at the point closest to them in the world. You can have scheduled functions, so effectively running your own crontas in this environment, usually wrapped around your own management tasks. And Zappa uses those, as I mentioned before, but in order to keep these Lambda functions warm. It's got other things like rollback. So if you have deployed something, something's gone wrong, you have to do a lot to undeploy and get back to an earlier version that you deployed. A few things to mention then. Building packages from a virtual environment, slightly unusual

Speaker 1: when I first came to that. You've actually got to be sort of quite careful that you haven't actually stuck anything else in your inverted environment that you didn't mean to that's going to end up in this package that goes to the lambda function. But if you're building from a clean continuous integration environment, you're probably less likely to hit any problems there because you will just be building whatever's defined for your virtual environment. Package size limitations, there's a 50 megabyte limit of the zip file when it goes up. I've been able to deploy upload ones that's fair bit bigger than that without any problems yet. But if you did get to a if you did have a really massive application, you can actually deploy it to an S3 bucket temporarily and then Zappa will load that from that bucket when the Lambda functions are deployed, which is slightly slower than just doing it all in the in the one go.

Speaker 1: And then brief mention then timeouts and This is slightly different. So API gateways by default have 30 seconds timeout, so your response has got sort of come back within 30 seconds. Although your lambda functions themselves can have much longer timeouts. So you can run background tasks that take longer than 30 seconds, but for your end users, you're restricted more by the gateway timeout of 30 seconds, which hopefully should be enough if you're running a website. Quick mention of costs, I don't want you to take any notice of the details on this. It's more about pointing out that when you're talking about serverless and you're approaching it from the perspective of, great, this is going to cost me next to nothing or a few cents a year. Yes, that is true for the Lambda function component of itself.

Speaker 1: You've got enough free resource there to probably mean that will never cost you anything. The database side of things is probably where you really need to look carefully about what the actual costs are and compare that to the costs of just running your own database elsewhere. S3 , you need to do bit of analysis of how much throughput you're going to do that in terms of asset requests and how much you're storing in and out. Um because that can be sort of non-trivial, but again that's probably down to a few dollars worth a year maybe, unless you've got really high traffic. And then other minor things like um Route 53. So the idea is take a if you're gonna do this in a in a sort of in a production way, take an overall look at the costs. AWS has got a quite good billing section that actually keeps good track of what all this is, but uh it's quite hard to you don't necessarily discover at the start what all the costs are.

Speaker 1: Okay, so I would say um it's definitely worth giving a giving it goes up and makes it quite easy for you to deploy your personal projects into into AWS environment The free tier makes it pretty affordable, zero cost for you to to give it a whirl, so why not? Um and a reminder that just after this there's a workshop Adam's got um on building a Django uh serverless Django application if you want to. Learn a bit more. Thank you.

Speaker 2: Thank you so much. Neil Todd from Torchbox in UK. And he'll be answering questions with the remaining time. We have instructions on how to answer or ask a great question on our website. Um and we look forward to hearing from people in the audience and online.

Speaker 1: Oh, it's live. All right, Tom's just told me that site is live now.

Speaker 3: So um I noticed you have a slide with a hamster in a treadmill. Is that Is that a logo from something that 's not

Speaker 1: yeah it was just my way of thinking, I don't really care what this thing is. I mean I d I did all this stuff with with Zapper and got working out how to get it all to work and I thought, actually I've got no idea what this process is, how it works, what it does. I don't care. It could be hamsters in wheels for all for all examples.

Speaker 3: Excellent. Thanks. Um

Speaker 4: okay, I've got a question about things you have to do differently in structuring your application. One of the advantages to having a monolithic server that you deploy is that the server starts, it does all its warm-up, and then it is there and waiting Zappa is based around the idea of running a function every time someone makes a request. So if you have a even a relatively small warm-up period before you can serve a request, there is uh you know there's going to be a lag in servicing every request. Is there anything you need to do in structuring your application, particularly a Django application? uh to make to make sure that that uh lead time is as small as possible.

Speaker 1: Yeah I think in terms of geometric application itself there's not much you can do in terms of that lead time. As long as your function's kept warm At least from my experience, it feels pretty responsive once once it is warm, clicking through links. It doesn't feel like there's any lag. Where it does have an effect is I think it actually encourages you to look at your code itself and you're not saying well I've I've got this permanent infrastructure. My request can run as long as it takes because it's I'm paying for that idle time anyway. When you're paying for that cost time, you're actually you're incentivized to actually really focus on your application and get that get those times down. So to reduce that overall latency. to to the end user to serve the request and also reduces your costs if you can make your code run 20%

Speaker 1: faster. Normally like twenty percent less cost as well. So it's kind of a double benefit there. Okay. Uh

Speaker 4: you mentioned that y there is a way of keeping the things warm. What how much of state or what state is kept warm in that in that context

Speaker 1: I don't know the exact details, but as far as I know, sort of lambda uh Amazon services will keep keep that function primed and ready to go on their servers wherever those servers are. If it hasn't had any response for a while, it kind of deprioritizes it. So if from a cold start there's a few second mil few hundred milliseconds lag to bring it back up. But if it's kept warm, you are talking about sort of sub hundred millisecond times to get the responses.

Speaker 5: Is there anything that we can do in Django to improve this like warm-up phase? Anything specific for Zappa or for these function Execute functions as a request thing set up? Um

Speaker 1: I don't think there's much you can do at the the Django layer. That's more down the kind of down to the the implementation at the the service the service level. I guess different providers will all have different ways of doing that and different but they're all they're all trying to drive those responses down. And they pr they are pretty low, particularly in the Lambda one. Aurora serverless the database level is a kind of a entirely different beast. the way that whole works. So that's yeah, that's we're not talking hundreds of milliseconds here, we're talking 30 seconds. But everyone's trying to drive those starts down.

Speaker 5: All right. Thanks.

Speaker 6: Hiya. Um so serverless The economic benefits of it are obviously going to be more pronounced when you've got this gappy traffic and you've got areas where you're not getting any requests. You don't need to be paying for running it there. What your thoughts on serverless either for high volume stuff or as you've built something that then becomes high volume?

Speaker 1: Yeah, that's that's an interesting one because part I do partly did this because I'm gonna see whether it really works in this way. So we had a client that was wanted to consolidate all their various sites onto one stack, so they chose Amazon Web Services and then thought, okay, we should try doing this serverless as well. Can we run our websites uh in this serverless way? Um so we're attempting that I'm about to go into live launch next month so I'll probably know better then. But um yeah that's that's gonna be the n the most interesting thing is can it handle that sort of high demand as the as as the sites grow bigger. Are there any things we haven't thought about? just because it's running in this um serverless way. Are there any uh other factors about, you know

Speaker 1: If it's being in a in a VPC, are there any latency areas there in terms of talking to the database backwards and forwards? Is there is it anecdotal evidence if you do you want to run in a virtual private cloud? Everything runs a little bit slower because it's talking over various Elastic IPs. So the answer is I'm not 100% sure yet, but I've got my fingers crossed the next month or two.

Speaker 6: Thank you.

Speaker 2: We have about a minute left. Maybe we can answer a quick question. And if not, we can get ready for the next speaker.