(ANGEL SHOULDER) AWS Lambda: I love it! Quick, easy deployments and a better model for more granular on-demand pricing.
(DEVIL SHOULDER) AWS Lambda: I’m feeling JavaScript fatigue again. I have to learn a new deployment process, even though I just perfected my AWS / Docker / Heroku / Digital Ocean deployment.
Enter Claudia JS, an opportunity to let some other enthusiasts take over the minutiae of this Brave New World. You get the chance to quickly get up and running, and learn if this new technology stack is even right for you.
Benefits 101
As outlined by Rinki Sharma in Advantages & Disadvantages of Using AWS Lambda with Advanced Features:
- Reduced cost
- Reduced (no) machine maintenance
- Reduced scaling cost
- Easier operational management
All the advantages are extra-technical for application developers. In other words: they are not advantages that immediately accrue to these developers or within the deployment environment. A good counter-example would be Docker, which is advantageous for managing deployment environments from a pure developer perspective based on ease and convenience.
The advantage of AWS Lambda is entirely based on pricing and separation of concerns. While many of the advantages accrue to developers in the long-term, these are not explicitly the concerns we have on day one of a project or short-run hackathon.
Although some may come to different conclusions, my conclusion is that I should choose the easiest route into this technology. I should get the most out of my early investment. In other words: I want the plug and play solution. I want Claudia JS.
AWS Lambda
I was in the middle of a lightning build for a hackathon. In the process, we decided to test the merits of AWS Lambda for our service layer.
We had the perfect API storm for a serverless test case:
- Fairly robust on-demand calculations
- No need for a database other than auditing purposes
- Simple, contained React app that we hosted on S3 (another interesting topic here from Kyle Galbraith)
- No need for authentication
Our API layer was essentially a ‘worker’ layer. It was a place to store proprietary business logic, algorithms, and make a variety of third-party API calls. This was a great test case for Lambda. It’s simple and hits right on all the benefits of serverless functions.
Slow Start, until…
Initially, we landed on the the extremely robust Serverless node module. I have no qualms with the library. Only, I wanted to get a simple API up and running. I wanted to get it up and running with no confusion whatsoever. I spent a good half-day fighting with the library. In the end, I searched haplessly for alternative solutions (as we all do at the end of our configuration ropes).
I stumbled upon the AWS article suggesting Claudia JS, and I was shocked that the library did not have more excited publicity.
Convince me
AWS pros and system admins notwithstanding. I don’t want to mess with AWS configurations all day long. Plug and play is my middle name, even if it costs a bit in the interim. This is nothing compared the value of my (your) time.
Claudia JS provides:
- A clean process for defining APIS
- Clean greenfield deployments
- Clean update (incremental) deployments
Plug and play feels good. Plug and play is similar to when corporate team building activities assign partners at the outset. Sure, we all have an optimized partner selection. It’s just unlikely to happen amidst the chaos. We’re all better off with the democratizing power of random choice.
Claudia removes the deep (and often important) question of how to structure server-less APIs. Instead, it provides a fairly standard boilerplate in an effort to let you move forward on the things you wanted to do. In case you need a reminder that was: Reduced cost, reduced (no) maintenance, reduced scaling cost, and easier operational management.