A simple UUID generation service created to run with several serverless computing frameworks--Serverless, Zappa, and Python Serverless Microframework for AWS (aka Chalice)--to get a feel for each framework.
Serverless computing got my radar in the winter of 2016 when I came upon the Serverless framework. With such a catchy name, it was hard not to explore what serverless computing was about. Since I work in a corporate environment, I am used to considering enterprise requirements, including:
- Security considerations like AWS IAM permissioning.
- How easy will it be for new developers to pick up a framework and start contributing effectively?
- How well-documented and/or how much community support & adoption does a framework have?
- How easy will it be to test an application in a local sandbox?
- What are the risks of vendor lock-in?
I have kept the UUID service implementation for each framework self-contained without any dependencies between them since the implementations are so simple, and DRYing anything out would distract from the original purpose to give them a test drive. While many such frameworks exist, my choices were picked for the following non-scientific and random reasons:
- Serverless received quite a bit of attention in the winter of 2016 when I first started looking serverless computing, so my curiousity was piqued and I started out working with it.
- Not completely satisfied with how to locally-test Serverless applications, Zappa attracted my attention due to its support for the well-established frameworks, Flask and Django.
- Chalice appeared in the summer of 2016 when AWS decided to join the party too, and it was obviously tempting given the support (and lock-in) by AWS.
- I preferred working in Python than JavaScript.
Each implementation is in its sub-directory named after the framework used, and each has a /uuid route that returns a single UUID in JSON format, or x number of UUIDs if the n=x query string parameter is passed, e.g. /uuid?n=10 returns 10 UUIDs.
$ curl https://sfh62fps2c.execute-api.us-east-1.amazonaws.com/dev/uuid?n=3
{
"uuid": [
"61262d74-a434-4c51-8a87-d50aa2ad77ca",
"e3765903-1ccc-4c24-af27-eb4e8df823ff",
"3a406ece-5ce3-437f-9cc4-f953b1e47aad"
]
}
- Documentation is extremely JavaScript-centric, and understandably so it is is written in JavaScript.
- API latency seems to be consistently lower than Zappa or Chalice, likely because it does not have to deal with the initialization overheads of a Flask app.
- Adding libraries is slightly clunky since they have to be vendored.
- Fantastic deployment that uses CloudFormation, which allows removal really easily too.
- Needs AWS admin permissions for deployment. :(
- How do I build unit tests?
- Deployments can be tiny.
- AWS-supported.
- AWS lock-in!
- Flask-like routing, which makes it very familiar to developers.
- Where is the rollback function?!? You gotta remove the Lambda functions, API Gateway settings and LAM role manually.
- Consistently about 150ms slower than Serverless.
- Deploys Flask and Django apps, both of which are well-documented and well-known by engineers.
- Easy to build Flask and Django unit tests.
- Avoids vendor lock-in to some degree since we can deploy Flask and Djanjo apps elsewhere really easily.
- Flask and Django apps are easy to unit test.
- Consistently about 150ms slower than Serverless.
- Easy to rollback and undeploy.
- I really like how lean Serverless functions can be, but the required IAM admin access is a bit of a pain to work around.
- Serverless is consistently about 150ms faster compared to Zappa & Chalice, but it is probably less of a concern than my ad serving and real-time bidding background allows me to think it is.
- Zappa is nice since Flask and Django apps can be developed outside of the operational setting, and then deploying with Zappa. The ability to define an IAM role outside of the framework is very nice.
- Chalice sounds like vendor lock-in.