Lambda has been in the news a lot lately. At Six Feet Up, we have recently had the opportunity to try it for one of our projects, and I wanted to share our experience here.
Lambda is Amazon Web Services (AWS)’ serverless infrastructure. It makes it possible to run small tasks that respond to various kinds of events without actually running any servers. This means there is no need to maintain any kind of operating system or hardware or any kind of networking.
Developers basically write simple scripts or functions (Lambda is basically an anonymous function), and Lambda, in response to some event, runs your function passing it the event and the object involved in the event. This is, basically, software development without a server. Obviously, there is a server running someplace, but developers do not actually have to manage it. This is why Lambda is so disruptive.
The traditional role of an Operations department that wants to run and own the server hardware, and patch the operating system, is non-existent in this model. With Lambda, it's truly up to the developer to write, deploy and version his/her code in response to various kinds of events. For example, Lambda can be used to scan files for viruses, or translate webhook calls from one API to another using the AWS API Gateway events.
Another big plus of Lambda is that it already listens to all the various kinds of cloud events that are happening inside of the AWS infrastructure, or everything from the elastic load balancer to S3 file system events, or to EC2 events. It can then react and respond. Developers can actually have it do things for them, like scale up more EC2 instances if they need them.
Lambda can also be used in response to various events to ensure compliance across an infrastructure. It can check that system images aren’t too old running in various areas of the infrastructure. It can also ensure that file system encryption is being used. If it isn't, Lambda can react and actually fix the problems.
One caveat with Lambda is that it needs to be kept pretty simple. Running complex applications through Lambda may not be the best as debugging a very large application running in Lambda is likely to be difficult. On the flipside, keeping Lambda nice and simple provides for armies of scripts doing lots of little work for you. It's similar to Unix Utilities in that way: you pipe information into it, and you receive information on the other side of it.
Right now Lambda supports Python, NodeJS, and even Java. However there are some intricacies in getting it tested and running on a local machine and then being able to deploy into Lambda. At Six Feet Up, we have put together some skeleton boilerplate framework bits to help developers bootstrap a Lambda project and run them through tests in an automated fashion.
What's really nice about Amazon is they really support Python as a first-class citizen. They've got a really well-written library called Boto2 for interacting with all the Amazon, AWS, APIs, and that includes Lambda. Being able to create new Lambda functions, update Lambda functions, and then test Lambda functions can all be done from the command line using Python Boto and the AWS CLI.
Lambda’s Pros and Cons in a nutshell:
Pros:
Cons:
If you have questions about Lambda, please feel free to email me. I'll have a screencast coming up soon of a talk I did for IndyPy where I showed off doing image manipulation by converting images to thumbnails when they're dropped on the S3 automatically.