Mention AWS, and most people think of EC2 and infrastructure as a service. Although Amazon has steadily added platform features to AWS, including storage, databases, and mobile services, no matter what you did on AWS, you needed a VM on EC2 (or a container on the new EC2 Container Service) if you wanted to run code. That meant thinking of AWS more as cloud infrastructure and less as a platform.
The IaaS model made a lot of sense when AWS was used almost exclusively for hosting cloud endpoints for mobile and desktop applications or when running Web applications and services. You might use some of the AWS platform services to simplify development, but beyond that, you’d write code the way you always have on the platforms you’ve always used.
But the types of application we’re building in the cloud are changing, and the tools we’re using are changing with them. Platforms like Node.js don’t require hefty VMs to host code, while the rapidly growing Internet of devices and sensors we’re building needs access to a scalable, event-driven, message-oriented architecture.
That’s where one of the newest Amazon services comes into play: AWS Lambda. At heart, it’s a managed Node.js service, where Amazon handles the underlying infrastructure and manages the OS and application platform. As it’s constructed around Node.js, you can use Node.js to build and test your code locally before uploading to Amazon as a zip file of code and libraries. Amazon provides a set of its own Node.js libraries in the AWS SDK, and they’re all you need to get started.
AWS Lambda applications are called functions and are best thought of as microservices that can be triggered by external events. The underlying service launches your code as soon as an event is triggered, so you’re paying for only the compute resources you use. Of course, as you may be triggering that code thousands of times in parallel, you’ll still want to write code that’s as efficient as possible.
Events are currently sourced from various Amazon services, including S3, DynamoDB, Kinesis, SNS, and Cognito. Other sources will need to be passed through those services in order to work with AWS Lambda. If you’re building IoT applications, then Kinesis stream processing will be a useful source, as will changes in S3 storage. Mobile apps will want to take advantage of Lambda’s Cognito support, allowing actions to be triggered from user identities and synchronized data. Similarly, sending a notification from SNS can trigger an AWS Lambda function, allowing you to process related data at the point a message is sent.
AWS offers two options for connecting Lambda to other services. You can use pull to subscribe to an event source and trigger an action when an event is detected as the source is polled. Alternately, you can push an event to a Lambda function directly. The push option is probably more interesting, as it means your code remains quiescent until triggered—ideal for applications that wait for a source to change (for example, sending an alert to a user when an image is uploaded to a S3 store by an Internet-connected security camera).
Like Microsoft’s original Azure or Google’s App Engine, AWS Lambda functions are stateless. There’s no persistent infrastructure associated with a function. It’s all instantiated when the function is launched and torn down when the function stops running—and two instances of the same function may not even be running on the same instance or in the same physical server. This approach means that AWS Lambda functions can scale rapidly, but you can’t use many familiar programming techniques.
The structure of a Lambda function will be familiar to Node.js developers, especially those using microservice frameworks like Seneca. Handler names define the Node.js code called by the AWS Lambda service, with data delivered as events. You’ll find the event format will change depending on the data source. Results and completion are handled by the function’s context object. You can also deliver results to Amazon services and signal that the function has completed. The actual body of your code is JavaScript, so it’s quick and easy to develop in any JavaScript-aware editor (including Visual Studio with its new Node.js support).
One note about AWS Lambda functions: You’ll need to give it permission to work with other AWS services. You’ll create an appropriate role, then give AWS Lambda the role, along with applying an access policy to the role.
It’s important to give your functions only the permissions they require—you may well have to set up several different roles for several different functions. You’ll likely need to be an administrator to set this up. Once that’s done your functions will be able to read and write from other services, though in many cases you won’t have to set up roles when pushing events from services owned by the same account.
While Amazon doesn’t call it a platform as a service, AWS Lambda is comparable to the microservice tooling Microsoft is building into its new Azure Service Fabric. Microsoft is initially targeting C++ and .Net languages, but it’s using the Actor model as a key element in handling distributed computing. There’s some overlap between the Actor model’s use of messaging and an AWS Lambda function, with AWS spooling additional instances of your code as triggers are received.
Amazon is slowly moving aspects of its AWS service away from its infrastructure focus. While it remains at its core a data center in the cloud, it’s starting to take advantage of the way a modern data center breaks down into storage, compute, and networking. Scalable microservices are the future of cloud application development, and Lambda is Amazon’s foot in the door. Amazon has done a lot to deliver storage as a service, and with AWS Lambda, it’s starting to do the same with compute.