I’ve used the word “serverless” to describe Zappa – but what does that actually mean? Obviously, it’s not a completely serverless python function – there still is a machine returning the HTTP response to the client.
The difference is that the server’s entire lifespan exists within the lifecycle of a given HTTP request. Where normal web servers like Apache and Nginx have to sit idle 24/7, waiting for new requests to come in, with Zappa, the server is created after the HTTP request comes in through API Gateway to python. It then turns the API Gateway request into normal Python WSGI, processes the request, and returns it back through the API Gateway to the client. And then, poof – the server is gone.
This comes with some major advantages over traditional web servers. The first is scalability. Because Zappa on AWS Lambda handles all of the requests, you can have as many responses processed in parallel as you need. With AWS Lambda, you get 100 function executions per second right out of the box, but the limit is arbitrary and if you scale beyond that you only need to ask Amazon to raise your limit.
The next major advantage is cost. With AWS Lambda, you pay by the millisecond. So rather than paying to have a beefy EC2 machine running 24/7 for your website, you only pay based on the amount of requests you server – which typically means you’ll only be paying pennies per month for an ordinary website. Not to mention the cost saving on not having to spend time on deployment, operations and maintenance!
Maintainability and Ease of Use
Zappa is also incredibly easy to deploy. It’s literally a single command – python manage.py deploy production – to configure and deploy your code, and after that, you never have to worry about it again. No provisioning machines, no setting up web servers, no DevOps, no operating systems, no security upgrades, no patching, no downtime. It just works!
Hacks used to make serverless lambda deployment possible
AWS Lambda and API Gateway are very new technologies, so there are a quite a few hacks that make this all possible. Those include, but aren’t limited to:
- Using VTL to map body, headers, method, params and query strings into JSON, and then turning that into valid WSGI.
- Attaching response codes to response bodies, Base64 encoding the whole thing, using that as a regex to route the response code, decoding the body in VTL, and mapping the response body to that.
- Packing and Base58 encoding multiple cookies into a single cookie because we can only map one of a kind.
- Turning cookie-setting 301/302 responses into 200 responses with HTML redirects, because we have no way to set headers on redirects.
If you want to learn more, take a look under the hood!
Though Zappa is now feature-complete enough for an initial release, there is still a fair amount of work to do. For instance, there is only one client library so far for this serverless function, django-zappa, but it should be fairly easy to add support for Flask, Pylons, and any other WSGI python web framework. The same principles that make Zappa possible should also work for NodeJS applications, but I find it’s much more comfortable to develop in Python.
Try it out!
So give it a shot! It’ll seriously change the way you think about deploying web applications. (If you just want to see a page served by Zappa, check out this little hello-world page with a self-signed certificate – real website coming soon!)
If you’re interested in contributing, you can also check out the code from GitHub and start submitting pull requests!
Whether you’re looking for some temporary help or your next full time developer, let Gun.io help you find the right person for the job.