Serverless computing has become a compelling model for companies to add business value without their development teams having to worry about provisioning, managing and scaling infrastructure. The concept is that developers write code that performs business logic based on some specific input data, and the platform handles the details of:
- Where to run it: Use some machine with available capacity in its pool
- When to run it: Either event-driven or scheduled
- How to run it: Decouple your developers from your runtime. You do not have to be concerned about whether your program is running on bare metal, in a VM or in some sort of container
Serverless computing enables a large class of applications where deployment becomes a solved problem. DevOps maintains the responsibility to set up the platform for automated resource provisioning and configuration management. Resources become available as and when required.
The most well known serverless computing platform currently is AWS Lambda. Similarly, Google and Microsoft have recently announced similarly-architected platforms with Google Cloud Functions and Azure Functions, respectively.
Independently, containerization has taken the deployment process by storm. Containers enable self-contained, immutable services to be run on any machine without worrying about differences in environments. Meanwhile, high quality orchestration tools like Kubernetes allow containers to be effectively managed in a fault-tolerant manner.
Serverless Containers: The Holy Grail
Wouldn’t it be great if the serverless paradigm could be easily implemented on a containerized infrastructure?
- Fast development in serverless environments by writing simple functions.
- The ability to move containers to the most performant, cost-effective platform based on the workload.
Announcing Project Kratos
I’m happy to announce that Project Kratos is now available in beta. Iron.io is rolling out a set of tools that allow you to convert AWS Lambda functions into Docker images. Now, you can import existing Lambda functions and run them via any container orchestration system. You can also create new Lambda functions and quickly package them up in a container to run on other platforms. All three of the AWS runtimes are supported – Node.js, Python and Java.
Why pick Lambda?
AWS Lambda is currently the most widely used serverless platform. There is a ready pool of developers who have experience using Lambda, and an even larger pool who are interested but unable to use it in production. Perhaps these developers may not want to use Amazon infrastructure or may have outgrown it. Until now, there was no easy way to have a Lambda-like experience on other platforms. This project changes that. Lambda compatibility is a stepping stone to more powerful structured functions.
How do I try this out?
You can use the `iron lambda` command’s subcommands to perform various actions. You can import an existing Lambda function on AWS and convert it to a Docker container by running:
iron lambda aws-import <function-name>
Note that depending on your Docker configuration you may have to prefix `sudo` to these commands.
You can write a lambda function in node.js, Python or Java and convert it to a Docker image by running:
iron lambda create-function --function-name <name> --runtime <runtime> --handler <handler>
Let’s walk through a simple example. Here is the code for the function. It is based on AWS’ example Lambda function that uses ImageMagick to perform various image operations. The only tweaks are that we use `console.log()` for the output instead of `context.succeed()` because Docker containers don’t have an HTTP “response” concept unlike Lambda functions.
If you save it as a Lambda function in your AWS console (I have chosen to call it image-tools), you can now import it using the ARN. It will look something like:
$ iron lambda aws-import arn:aws:lambda:us-east-1:<id>:function:image-tools
This will create a local Docker image called `image-tools`. In addition the code is download to a folder called `image-tools/` if you want to fiddle with it and use the `create-function` command to package it up later.
You can test this function locally by passing it a simple encoded payload:
$ iron lambda test-function -function-name image-tools -payload '<payload>'
Operation getDimensions requested
Identify operation completed successfully
You can run this Docker image anywhere and pass it the appropriate payload.
Let us deploy it on IronWorker and try it out. The publish-function command publishes this to Docker Hub and registers it with IronWorker.
$ iron lambda publish-function --function-name <docker user>/image-tools:latest
We can then run it on IronWorker:
$ iron worker queue -wait -payload '<payload>' <docker user>/image-tools
Do you support everything Lambda does?
Not yet. Interaction with most AWS services is possible via the provided AWS APIs. In addition, SNS can use Webhook triggers to start tasks on the Iron.io platform. There are some limitations to what we can support, and others we simply haven’t implemented yet.
The biggest difference is that Lambda functions on AWS can return HTTP responses. Since this Lambda support only packages up the function as a Docker image, out of the box HTTP support is not available. We think this is a reasonable future goal.
A full compatibility description can be found in the documentation. Of course, we would love to improve this project and we could use your help.
Contributing to Lambda support
Seamless integration with IronWorker
Iron.io is the premier service for running data-processing or event-driven workloads at scale, that is — serverless computing! We have run over a billion Docker containers till date and with this feature, we can now run Lambda functions too.
Once you sign up for an Iron.io account and set up credentials the `iron lambda publish-function` command will publish the Lambda function to Docker Hub and register it as a IronWorker. You can then queue up these jobs, schedule them, or, for true event-driven workflow, use webhooks to trigger these jobs with a payload.