AWS Lambda Impressions

As I have mentioned before I moved this website from a normal Wordpress installation to a combination of AWS Lambda and S3. From a newbie’s perspective, here are some of my impressions in no particular order. Note: I am confident these will change over time as both Lambda, and my knowledge of it, evolve.

Lambda is Interesting, But Not Always a fit

Lambda, given the ability for enterprises to complete rearchitect their applications, seems interesting. The ability to scale to zero or infinity seems interesting. Most enterprises aren’t going to rewrite an application just to get it to Lambda. Cost savings, on their own at least, aren’t a reason which drives enterprises to make changes.

Lambda Isn’t For Every Application

The inspiration for me to try Lambda was based on a desire to spin up cloud infrastructure using Ansible, but triggered on my phone. Yes. It’s probably not a great fit and I knew it going in, but it was a good learning opportunity. Someone posted an Ansible in AWS Layer which is exactly where I was going with it. Ansible’s source code is 100MB which becomes a concern with a maximum of 250MB per function, including layers. 150MB is still plenty of room, but it’s obvious there are use cases which need second thought.

Lambda functions have a maximum execution time of 15 minutes. A majority of Ansible playbooks will be completed within that time, but playbooks with a large inventory will hit that limit.

The Lock-In Is Real

Lambda has multiple components whose implementation details are probably specific to Lambda: events, function invocation, output objects, and layers. Moving from AWS Lambda to another serverless infrastructure will require a certain amount of re-engineering. AWS CodeCommit (an AWS hosted Git service) will trigger a Lambda function with a few clicks. But Github or Gitlab will require an AWS API Gateway event.

API Gateways Are the Lowest Common Denominator

<<<<<<< HEAD

As implied above, the API Gateway looks to be the lowest common denominator interface between Lambda and non-AWS services. This isn’t necessarily a good or bad thing. Just an observation.

As implied above, the API Gateway looks to be the lowest common denominator interface between Lambda and non-AWS services. This isn’t necessarily a good or bad thing. Just an observation.

Development Environment Isn’t Trivial

Lambda offers the Plan9 IDE in the web interface but it is only okay. Optimally, I could use my text editor of choice for development. I deployed serverless which does seem to help as it handles initial and future revisions. It introduced some challenges though. It uses CloudFoundation for provisioning. IAM is one of the most fickle parts of AWS as every interaction needs correct permissions. When CloudFormation doesn’t have proper IAM permissions, it will go into a rollback state which seems to last at least 5 minutes. No changes can be made via serverless during this time. I’ve moved away from serverless for provisoning, but will move back to it for new projects. >>>>>>> 332bf6cb0bb5f26f8585b8327325ce5356840c79