Erik Farmer
Programmer
Programmer
One of the efforts I was hired on for at getTalent was to implement a microservice architecture. That meant breaking up lots of web2py code into focused flask applications. It was a good experience that allowed me to see different parts of the application one section at a time and afforded me the opportunity to make changes as each commit was essentially a fresh check in.
But something terrible has happened. I discovered AWS Lambda and now I want everything to be a Lambda function
For the uninitiated Lambda is an on-demand server on AWS that responds to certain triggers. You can run AWS code when something is uploaded to S3, hits an API Gateway endpoint, in response to CloudWatch and many more (a Lambda can even call another Lambda; something something turtles all the way down). The best part is that you are only charged based on the runtime and memory allocated to the Lambda code.
After some initial testing and toy code I was able to start migrating certain functionality from flask to Lambda (specifically running Image Magick on 'someone else's server'). The results have been more than wonderful as we get to move some of the heavy lifting (and possible security issue) from our micro service container to it's own environment with it's own dependencies and resources. There were some caveats however. Lambda requires that all external dependencies be bundled with your Lambda code. So say you want to use SQL-Alchemy in a Python Lambda function; you would need to include the libmysqlclient.so file (and it would need to have been built on an AWS Linux AMI). There is also some additional set up when deploying in VPCs and what not but it is nothing insurmountable.
Hopefully the low cost of running Lambdas will allow myself and others to get some simple apps off the ground for even less than the cost of a t2.micro instance.
back