Some call it “lambda architecture,” others call it “serverless computing.” Whatever the name, the idea is the same: Break applications into clusters of single functions that run on demand and on automatically managed resources.
At Amazon, it’s called AWS Lambda, and the latest Lambda-related features indicate serverless computing is becoming a more important part of Amazon's portfolio.
Last week Amazon unveiled two new features for AWS Lambda designed to broaden its appeal as a development platform.
Keeping a secret, making it portable
First up is the ability to associate environment variables with specific Lambda functions, which allows API keys or other secrets to be used without having to hard-code them into a function. The variables can be stored as encrypted key/value pairs in AWS Key Management Service and are decrypted on-demand—Amazon isn't reinventing the wheel. There’s a hard per-function limit of 4KB of storage for variables, but that should cover the vast majority of use cases.
The other new feature, the AWS Serverless Application Model (SAM), speaks directly to how AWS Lambda-created apps can be made easier to create, manage, and even port between infrastructures.
AWS SAM is essentially a manifest file for an AWS Lambda application that describes all the different pieces it speaks to in AWS’s architecture, such as Amazon API Gateway resources (for creating API endpoints) and Amazon DynamoDB tables. SAM files can be used by AWS CloudFormation and can be automatically generated from an existing Lambda function to be used as a model for other Lambda functions.
Another set of improvements, announced earlier this month, allows Lambda features to be used with Amazon’s mobile application development system, AWS Mobile Hub. In this scenario, Mobile Hub isn’t being used to connect to existing Lambda functions, but can help create functions and equip them with API Gateway endpoints that are used in mobile apps.
Amazon’s rationale for doing this is that it allows front-end developers to build back ends as they need them, starting from the app side rather than from the server side. It’s meant to improve workflow for developing mobile apps as much as it’s meant to improve their infrastructure—and it gives more devs a reason to build something in a “Lambda-first” fashion.
Don’t fence (or lock) me in
One ongoing concern about serverless architectures is lock-in—which users of almost any cloud service have to consider. In AWS Lambda’s case, the lock-in is not because of the construction of the functions themselves, but rather that Amazon makes it easy to become highly dependent on the web of Amazon-only services surrounding them.
The problem isn’t insurmountable. Third parties have already stepped up to offer ways to liberate AWS Lambda workloads from those constraints (such as Iron.io’s Project Kratos or the Serverless Framework). SAM itself appears to be part of Amazon’s effort to make Lambda less closed-ended. In theory, the SAM file for a Lambda function can be used to replicate it in an entirely different environment that matches Amazon, feature for feature. That’s not too far-fetched, given how Amazon’s APIs and feature sets have become de facto standards.