Serverless Thoughts 1

I’m on holiday this week, and I wanted to use the time to really get to grips with serverless models of deployment.

My background is in Python development (which I want to stick with; this week isn’t to learn a new language), and mainly around doing full-stack deployments with Django, and all that entails; a persistant relational database, the MVC pattern, and server-side rendering.

I have a background knowledge of AWS Lambda (ie. I know what it is, I know what it can be used for, but I haven’t actually used it), and I’ve a vague set of notions around things like AWS API Gateway, AWS SAM, etc. In short, I am no expert.

I have a very simple application which I want to deploy; a very limited set of views, and a very simple data model which would be suitable for a schemaless store like AWS DynamoDB, or AWS ElastiCache/Redis.

So last night, I began doing some research. In all instances, I was looking to deploy a trivially simple Flask application:

from flask import Flask

app = Flask(__name__)

def index():
    return "Hello, I'm serverless."
if __name__ == '__main__':

I realise this isn’t at all testing any of the factors of the serveless model which are actually interesting; this doesn’t react to events, it doesn’t do anything to mutate the state of another, it’s dull. But, I figured that if I can get Flask installed, that means that I have a reasonable Python runtime, into which I can install Python packages. And that’s good enough for me.


Zappa was my first instinct. I’ve heard of Zappa previously; at the time, it made some really interesting claims around easily adapting a WSGI application (such as a Django application) to a serverless environment. I also knew that Zappa was a Python package, so my research was rushed (or non-existant).

pip install zappa

… followed by a deployment with:

zappa init
zappa deploy

This was magical. The deployment went well, it appears that Zappa created the dependant resources which I needed in AWS, and I could curl my Flask application and get the response I expected. Very encouraging. Time to learn more, time to visit the documentation at


It’s down. I checked the Github issues; it seems the project is in a state of mid-handover. The original developer has disappeared, or lost interest. There are maintainers who are looking to create releases, but they neither have control over the project domains (and, sadly, are closing tickets which relate to this: #1976). There is a new Pypi release from March 2020, but the project is sending very mixed signals. There’s clearly work ongoing to stabilise the repository and the infrastructure, but I’m wary to depend on Zappa until these issues are resolved and the code comes into common ownership.


Following from that disappointment, I began researching Architect. This is the open-source element of Again, setup was near trivial (even so simple to understand that a quick detour into deploying a deno application took 5 minutes).

arc init
arc deploy

I’m especially intrigued by the idea of embedding your data models in the .arc DSL. This is a fascinating way to get started quickly with an application. It’s an approach which might have real merit. It feels clean and minimal and well designed.

Unfortunately, Architect cannot currently clean up after itself. This is a dealbreaker. It appears there is a package to provide this, but it wasn’t something I wanted to battle with integrating.

So I had to spend 15 minutes cleaning up the mess in my AWS account which was annoying.


Next on my list was Serverless. This seems like a ‘mature’ offering; supporting a few languages (but I only really care about Python), with a monetisation models based on selling dashboard access to teams. This is fine; the core of the tool is MIT licenses.

Again, the setup is simple, with the annoying detour of being asked to register an account. The dashboard seems useful. There’s an serverless remove command to clean up.

This seems promising.