| I've been using AWS Lambda on a side project (octodocs.com) that is powered by Django and uses Zappa to manage deployments. I was initially attracted to it as a low-cost tool to run a database (RDS) powered service side project. Some thoughts: - Zappa is a great tool. They added async task support [1] which replaced the need for celery or rq. Setting up https with let's encrypt takes less than 15 minutes. They added Python 3 support quickly after it was announced. Setting up a test environment is pretty trivial. I set up a separate staging site which helps to debug a bunch of the orchestration settings. I also built a small CLI [2] to help set environment variables (heroku-esque) via S3 which works well. Overall, the tooling feels solid. I can't imagine using raw Lambda without a tool like Zappa. - While Lambda itself is not too expensive, AWS can sneak in some additional costs. For example, allowing Lambda to reach out to other services in the VPC (RDS) or to the Internet, requires a bunch of route tables, subnets and a nat gateway. For this side project, this currently costs way more running and invoking Lambda. - Debugging can be a pain. Things like Sentry [3] make it better for runtime issues, but orchestration issues are still very trail and error. - There can be overhead if your function goes "cold" (i.e. infrequent usage). Zappa lets you keep sites warm (additional cost), but a cold start adds a couple of seconds to the first-page load for that user. This applies more to low volume traffic sites. Overall: It's definitely overkilled for a side project like this, but I could see the economics of scale kicking in for multiple or high volume apps. [1]: https://blog.zappa.io/posts/zappa-introduces-seamless-asynch... [2]: https://github.com/cameronmaske/s3env [3]: https://getsentry.com/ |
Lots more features in the pipeline, too!