I’ve written before about several ways to make use of AWS Lambda functions within your Alfresco Content and Process Services deployment. In preparation for my DevCon talk, I’m diving deeper into this and building out some demos for the session. I figured this is a good time to do a quick writeup on one way to approach the problem.
What is a Lambda function?
Briefly, AWS Lambda is a “serverless” compute service. Instead of the old model of provisioning an EC2 instance, loading software and services, etc, Lambda allows you to simply write code against a specific runtime (Java, Node, Python, or .NET) that is executed when an event occurs. This event can come from a HUGE number of sources within the AWS suite of services. When your function is called, it is spun up in a lightweight, configurable container and run. That container may or may not be used again, depending on several factors. AWS provides some information about what happens under the hood, but the idea is that most of the time you don’t need to sweat it. In summary, a Lambda function is just a bit of code that runs in response to a triggering event.
Preparing the Lambda package
Creating a Lambda function through the AWS UI is trivial. A few clicks, a couple form fields, and you’re done. This is fine for simple functions, but what about when you need to use an external library? The bad news is that this takes a couple extra steps. The good news is that once you have done it, you can move on to a more productive workflow. The sticking point from doing it all through the AWS console is the addition of libraries and dependencies. We can get around that by using a Zip package to start out project. The Zip package format is pretty simple. Let’s create one, we’ll call it AlfrescoAPICall.
Start by creating an empty director for your project, and changing into that directory:
mkdir AlfrescoAPICall
cd AlfrescoAPICall
Next, create a handler for your Lambda function. The default name for the handler is index.js, but you can change it so long as you configure your Lambda function appropriately.
touch index.js
Now, use npm to install the modules you need into your project directory. For this example, we’ll use alfresco-js-api.
npm install alfresco-js-api
A real project probably wouldn’t just install the needed modules piecemeal, it makes more sense to define all of the dependencies in package.json instead. Regardless, at the end of this you should have a project root folder that contains your Lambda function handler, and a node_modules directory that contains all of your dependencies. Next, we need to Zip this up into a Lambda deployment package. Don’t Zip up the project folder, we need to Zip up the folder contents instead.
zip -r AlfrescoAPICall.zip .
And that’s it! AlfrescoAPICall.zip is the Lambda package that we’ll upload to AWS so we can get to work. We don’t need to do this again unless the dependencies or versions change.
Getting it into AWS
There are a few ways to get our newly created deployment package up to AWS. It can be done using the AWS CLI, or with the AWS console. If you do it via the CLI, it will look something like this:
aws lambda update-function-code –function-name AlfrescoAPICall –zip-file AlfrescoAPICall.zip
If you do it via the AWS console, you can simply choose the file to upload :
Regardless of how you update your Lambda function, once you have uploaded your zip archive you can see the entire project in the “edit code inline” view in the Lambda page:
Woo hoo! Now we have a skeleton Lambda project that includes the Alfresco Javascript Client API and we can start building!
Starting development in earnest
This process is simple, but it isn’t exactly the easiest way to build in AWS. With the relaunch of Cloud9 at re:Invent, AWS has a pretty good web based IDE that we can use for this project. I’m not going to go through all the steps of creating a Cloud9 environment, but once you have it created you should see your newly created Lambda function in the right-hand pane under the AWS Resources tab. If you don’t, make sure the IAM account you are using with Cloud9 (not the root account!!) has access to your function. It will be listed under Remote Functions. Here’s where it gets really cool. Right click on the remote function, and you can import the whole thing right into your development environment:
Neat, right? After you import it you’ll see it show up in the project explorer view on the left. From here it is basically like any other IDE. Tabbed code editor, tree views, syntax highlighting and completion, etc, etc.
One cool feature of Cloud9 is the ability to test run your Lambda function locally (in the EC2 instance Cloud9 is connected to) or on the AWS Lambda service itself by picking the option from the menu in the run panel. As one would expect, you can also set breakpoints in your Lambda function for debugging:
Finally, once you are done with your edits and have tested your function to your satisfaction, getting the changes back up to the Lambda service is trivial. Save your changes, right click on the local function, and select deploy:
Simple, right? Now we have a working Lambda function with the Alfresco Javascript Client API available, and we can start developing something useful! In part two, we’ll continue by getting Alfresco Process Services up and running in AWS and extend this newly created function to interact with a process.
