Deploying Node.js Microservices to AWS Lambda with Claudia.js: Q&A with Author Gojko Adzic
AWS Lambda is a compute service that runs code in response to events, and automatically manages the underlying compute resources. AWS Lambda can automatically run code in response to multiple events, such as changes to data in an Amazon S3 bucket, modifications to an Amazon DynamoDB table, or as a response to HTTP requests using Amazon API Gateway (the so-called ‘serverless’ architecture).
InfoQ sat down with Adzic and discussed the creation of Claudia.js, the motivations and goals of the tool, and the viability of AWS Lambda for running production workloads.
InfoQ: Hi Gojko, thanks for taking time to speak to InfoQ today. Could you introduce your new microservices deployment project, Claudia.js, please?
AWS Lambda and API Gateway offer scalability on demand, zero operations overhead and almost free execution, priced per use, so they are a very compelling way to run server-side code. However they can be tedious to set up, especially for simple scenarios. The runtime is oriented towards executing Java code, so running Node.js functions requires people to iron out quite a few issues, that aren’t exactly well documented.
InfoQ: What are the overall goals with Claudia, and what are the non-goals? For example, many microservice toolkits are emerging, such as Seneca.js, go-kit and Spring Cloud, but Claudia appears more focused on deployment?
Adzic: The whole cloud microservices space is growing rapidly at the moment, and there are new frameworks and tools popping up everywhere. Many of those you mention are frameworks - they help people get started with standard communication tasks, distribution of work, and service discovery. For our use case, that was just a huge overkill. We wanted to run simple stuff, such as reacting to GET and POST requests, processing files in S3 or acting on AWS SQS/SNS Queue messages. AWS services are already pretty terrific for all that, and we didn't mind using them directly.
The big problem we were facing while migrating from Heroku is a ton of boilerplate setup required each time, that's error prone and complex. We didn't want to change the way we're organising code, structuring projects, connecting to services and abstract away AWS. We just needed something to get the code running in Lambda reliably and quickly.
InfoQ: How do using Claudia differ than deploying applications using the standard approach to AWS Lambda? How does it differ than the 'Kappa' work undertaken by Mitch Garnaat?
Adzic: Claudia is using the standard approach to AWS Lambda deployment, it's just automating all the boilerplate. My goal was to avoid introducing too much magic, so we use the standard AWS Node.js SDK for everything. It helps people focus on the problem they are trying to solve, not having to remember the exact sequence of AWS API calls and all the security policies they have to enable.
InfoQ: Can you explain what motivated you to create Claudia.js? Was this part of a larger project?
Adzic: While working on MindMup 2.0, we started moving back-end code from Heroku to AWS Lambda, and collected a ton of checklists and troubleshooting tips to make it work well. Claudia is essentially automating all that, behind a convenient API.
Over time, we plan to migrate all the server code to Lambda. MindMup 2.0 is essentially a single HTML file, served from a CDN, that uses back-end APIs for dynamic functionality. This allows us to support users at scale, cheaply.
InfoQ: Do you believe AWS Lambda is ready for production use? If so, what would be the typical use cases?
Adzic: For us, it's doing the job well so far. Other projects might have different constraints, so "ready for production use" is quite contextual. In my view, it's a great replacement for relatively isolated server-side processing, where a second or two of latency is not an issue, but throughput, parallel execution and scaling on demand are important. Examples are file conversion, handling user uploads, sending out notifications, scheduled tasks, authentication or validation.
The compelling reason for using Lambda is zero admin and automatic scalability, with pricing per usage. If the code is using something that already requires a lot of other admin work, then it may not make such a big difference. If it needs microsecond latency, Lambda is probably not the right answer (yet).
InfoQ: Are you looking for help with the project? If so, what is the best way of contributing?
Adzic: Sure. Claudia is open source. I'm sure that there are many other developers out there thinking about migrating to cloud code execution. It's at the point where it does everything we need now, but if other people get involved, we can make it useful for a much wider set of use cases. The code is on Github, the best way to contribute is to fork it there and submit a pull request. The repository can be found at https://github.com/claudiajs/claudia
InfoQ: Thanks again for speaking to us today. Is there anything else you would like > to share with the InfoQ audience?
Adzic: As a summary, if you want to build simple services and run them with AWS Lambda, and you're looking for something low-overhead, easy to get started with, and you only want to use the Node.js runtime, Claudia is a good choice. If you want to export SDKs, need fine-grained control over the distribution, allocation or discovery of services, need support for different runtimes and so on, use one of the alternative tools.
Additional information on Claudia.js can be found within the project’s GitHub repository, and Adzic has created a three minute video, ‘Claudia.js Introduction’, which provides a high-level overview of the tool usage.