I spent several weekends working a project using the Amazon Lambda serverless micro-architecture to see whether it was worth using for larger projects. I created a micro SaaS – https://pdfbatchfill.com – that essentially takes a bunch of rows and spit them out to fields within PDF forms. Here are my brief thought on Lambda:
Complex setup
My overall experience with Lambda was positive; however, I used ClaudiaJS which abstracts nearly all the underlying plumbing. When I first started I did try to set everything up myself through the web interface and I found it overwhelming with the amount of options available due to the fact that Lambda by itself is a generic application “container”. A lot of glue is required for API Gateway and Lambda to expose the endpoints. There’s a lot of little things to do just to have a working route, so I settled on the ClaudiaJS framework to deal with them. There are others like serverless.
Comes fully-loaded
Everything just works when the application is deployed. The endpoints are automatically connected to logging within CloudWatch line by line separated by instances. Having zero need for maintenance on the infrastructure is surprisingly liberating. I am able to focus mostly on the application itself.
Using S3 to host the static page and Cloudflare to handle the DNS, I got an SSL-enabled site for free, assuming a low-traffic site of course.
Limitations due to maturity
AWS services tend to start out very stripped down and Lambda is no exception. One issue, which I encountered, was Lambda’s inability to accept binary form data. Searching the Lambda forum shows that it wasn’t quite ready for general adoption. As in, your project could be SOL and stuck if support wasn’t available for a particular function you need that is only discovered mid-way through. Luckily, I was able to workaround the issue by directly sending binary data through S3.