InfoQ recently sat down with Gojko Adzic and discussed his latest project, Claudia.js, a JavaScript tool that assists with the deployment of Node.js microservice applications to Amazon Web Service (AWS) Lambda. Claudia.js enables the deployment of AWS Lambda functions and Web APIs using a single command, automatically handles the waiting for propagation of IAM roles, configures console.log to pipe to CloudWatch, and allows easier versioning management of AWS Lambda functions for production, development and testing.
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).
Adzic, a partner at Neuri Consulting LLP, has suggested that deployment to AWS Lambda is potentially complicated due to the number of steps involved. Accordingly, he has created Claudia.js, a tool that enables easier creation or updating of Lambda functions. In addition to allowing deployment of Node.js ‘microservice’ AWS Lambda applications using a single command, Claudia.js automates many of the complicated tasks, such as allowing console.log to pipe logs to CloudWatch and configuring Amazon API Gateway resources to behave as a JavaScript developer would expect.
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?
Adzic: Claudia.js automates and simplifies deployment workflows and error prone tasks required to get JavaScript code running correctly in AWS Lambda, so developers can focus on important problems and not have to worry about AWS service quirks. Claudia sets everything up the way JavaScript developers expect, so they’ll feel right at home. With Claudia, it takes less than five minutes to create and deploy a simple HTTP endpoint, check out this video that demonstrates that.
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.
Claudia.js takes care of all that. For example, roughly 120 lines of shell scripts needed to get a JavaScript function wired up as a Web API get replaced with a single command using Claudia.
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.
So Claudia does exactly that. It simplifies code setup by doing all the boilerplate for you, but introducing almost no overhead for migrating from existing APIs elsewhere to Lambda. It collects all query string, form post, and request headers, makes them easily available to JavaScript code. It sets up the processing the way JavaScript APIs expect. And then it's up to you do do something useful with that.
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.
Kappa seems to be quite similar to what Claudia is doing, but it's doing it for Python. There are some similar deployers out there that do it for other languages, for example Apex. There was nothing I could find that handles JavaScript well. Generic frameworks support more runtimes, but leave the developers to deal with language-specific quirks. And there are a ton of language-specific problems we hit when starting to run JavaScript inside Lambda.
Claudia works only for JavaScript/Node.js, but it does it really well. Because Claudia focuses on Node.js, it automatically installs templates to convert parameters and results into objects that JavaScript can consume easily, and makes things work the way JavaScript developers expect out of the box. For example, instead of reporting errors with HTTP code 200, which isn't such a big issue for Java, but breaks most JavaScript Promise HTTP libraries, Claudia automatically sets the API gateway to send back HTTP 500.
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.