Serverless Computing is quickly evolving: Who will be left behind?
The 2016 AWS re:Invent will take place in Las Vegas in less than a week. We are all expecting big updates, especially regarding one of the AWS suite’s highest trending and pervasive services: Lambda.
In the past few days, AWS announced some interesting updates, and I assume that they are just preparing the ground for bigger news during the event.
Here is a short recap of what AWS has announced so far.
AWS Lambda – Environment Variables
How many times have you hard-coded sensitive information directly in your Lambda Function code?
How often have you deployed a “production” Lambda Function with the wrong “development” keys?
How many identical Lambda Functions have you re-deployed just because a simple configuration parameter had changed?
I bet many of you have been avoiding ugly workarounds in favor of sophisticated automation tools (such as the Serverless Framework) to solve most of these problems.
Either way, you can finally configure Environment Variables natively on AWS Lambda by using the AWS KMS secure storage. It means that your variable values will be securely encrypted and retrieved by AWS when needed.
The interesting part is that you won’t need to change your Lambda Function code much, as you can simply read the variable values from the standard environment of each Runtime (e.g. process.env in Node.js, os.environ in Python, etc.).
I’d like to highlight two important details of this new feature:
- You are limited to 4KB of storage, independently of the number of variables.
- Environment variables are immutable for each Function Version, which means that you will need to create a new Version to update their values, starting from $LATEST.
AWS SAM – Serverless App Model
AWS SAM might be the biggest Serverless update since the initial AWS Lambda announcement. Tim Wager already announced Project Flourish at the first ServerlessConf in New York earlier this year.
AWS SAM appears to be the new name of Flourish, which is aimed at becoming the first vendor-neutral reference for Serverless applications.
In practice, AWS SAM makes it easy to define all of the resources used by a Serverless application. The new model will allow you to create specific resources that are optimized for serverless apps with Amazon CloudFormation. This is incredibly useful for all of the automation tools and frameworks that already help you with the deployment and management of Lambda Functions, API Gateway APIs, DynamoDB Tables, etc.
Technically, you can finally define a Serverless application with only a few lines of text. Indeed, you can use the new AWS::Serverless CloudFormation namespace.
Here is a list of the new resource types:
- AWS::Serverless::Function: Represents an AWS Lambda Function, including its IAM role (or policies list), Environment configuration, VPC configuration, Events mapping, etc.
- AWS::Serverless::API: Represents a collection of API Gateway resources and methods. Please note that you don’t need to define this resource manually (it will be automatically inferred by the AWS::Serverless::Function events mapping) unless you want to generate more accurate Swagger documentation.
- AWS::Serverless::SimpleTable: Represents a DynamoDB table with a single attribute primary key. You can always use the complete AWS::DynamoDB::Table resource if you need more advanced DynamoDB features.
For example, here is how you’d define a simple read-only API connected to a DynamoDB table:
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Ready-only access to DynamoDB table.
Resources:
MyReadOnlyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.get
Runtime: python27
Policies: AmazonDynamoDBReadOnlyAccess
Environment:
Variables:
TABLE_NAME: !Ref ItemsTable
Events:
ReadItem:
Type: Api
Properties:
Path: /item/{itemId}
Method: get
ItemsTable:
Type: AWS::Serverless::SimpleTable
Unfortunately, some of the native Lambda event sources are not supported yet—namely, AWS CodeCommit—but I am looking forward to its upcoming improvements and how it will change the development workflow of Serverless applications. If you want to learn more, you can find the project on GitHub.
API Gateway – Binary Data Support
I have personally met many AWS users who have been waiting for this feature for a long time. API Gateway only supported JSON payloads and responses, and the implementation of API resources related to multimedia has been pretty hard, or hacky, at least.
You can now provide binary payloads—e.g. a big PNG image—and expect binary responses such as a resized PNG image.
To achieve this, you simply have to define two options:
- The contentHandling property of Integration and IntegrationResponse, which can be either CONVERT_TO_BINARY or CONVERT_TO_TEXT.
- The binaryMediaTypes of the RestApi resource, which contains a list of MIME types you want to treat as binary data.
Unfortunately, the new contentHandling property is not fully supported by API Gateway Resources backed by AWS Lambda, for which the request body is always converted to JSON. I’m looking forward to furthering improvements on this front.
Another interesting use case has always been the possibility to serve gzipped responses with API Gateway and Lambda, which makes sense if the size of your JSON responses is big enough and easy to cache. So far, the only available alternative is serving an API Gateway through an additional CloudFront distribution or implementing a custom decompression functionality on your client.
More Serverless News – Not only AWS
The Serverless ecosystem is evolving on many fronts, and many other actors are working hard to make an impact on the Serverless revolution. The following updates are not strictly related to AWS and won’t be affected by the upcoming AWS re:Invent, but are definitely worth mentioning.
If you are interested in Serverless updates, you can check our blog’s Serverless archive. Here is a selection of our serverless material:
- Google Cloud Functions VS AWS Lambda
- Bluemix OpenWhisk: IBM’s Function as a Service
- ServerlessConf Tokyo Highlights
- [webinar] Getting Started with AWS Lambda – Coding Session
- [webinar] AWS Lambda: Advanced Coding Session
Serverless Framework 1.2 Milestone
The Serverless Framework has changed a lot since we first talked about it six months ago. It was only in version 0.5 and a lot has happened in just a few months, including their $3M fundraising.
After Version 1.0 was released on October 12, the development team at serverless.com committed to a bi-weekly release plan, and they’ve just announced version 1.2, which includes the following:
- AWS Lambda environment variables support
- Per-function custom IAM roles
- Better naming customization for CloudFormation resources
- Improved local execution and error handling
- Easier packaging and included configuration
You can find all of the scheduled milestones on GitHub. The next version, 1.3, is due on November 30 and it will bring more exciting features. Not to mention are all of the new, top-secret announcements yet to come during the AWS re:Invent.
For example, they have just disclosed a new open-source project called Serverless Dashboard. It will represent a new user-friendly layer on top of the Serverless CLI to enhance the framework user experience.
Here is a screenshot of the native app for Mac, which you can find on GitHub:
Azure Functions general availability
Last week, Microsoft announced the general availability of Azure Functions.
Microsoft released its Function as a Service in preview only eight months ago. It supports C#, JavaScript, Python, and PHP.
This new serverless platform is gaining traction with big enterprises and small startups in the Microsoft ecosystem. In fact, it is creating a new Application Model under the Azure App Services, in addition to a whole new series of services such as the Azure Bot Service.
I am looking forward to more features coming soon, as well as its integration in the Serverless Framework.
Open-Source Iron Functions
Iron.io announced its first major open-source project, IronFunctions. The project is mostly written in Go, and it represents a new effort to build a hybrid/multi-cloud serverless solution by using open-source technologies such as Kubernetes, Mesosphere, CloudFoundry, OpenShift, Docker, etc.
Choosing Docker as a packaging mechanism makes IronFunctions language-agnostic, although the team also decided to support the AWS Lambda packaging format to improve portability, and they announced that they would support others soon.
What to expect next?
AWS announced Lambda at its 2014 re:Invent, and I’d expect much more news from this year’s event. Since then, Serverless has become a global movement. Each Cloud provider has built its own serverless solution—with different approaches and benefits—and at the same time, hundreds of local communities have gathered to share serverless ideas, wishlist items, and problems.
Here is my personal serverless wishlist for the upcoming months. I hope that AWS will surprise me next week!
- Declarative Dependencies Management: Package.json for Node.js, requirements.txt for Python, manifest.xml for Java. This is just how developers want to define and manage their code dependencies.
- Native Unit Testing: I would love to define my testing suite directly in the Cloud and let AWS Lambda do all the dirty work. Running my 1000 tests locally will always be an option, but why can’t Lambda run all of them in parallel and speed up my development?
- Longer execution time: Because some people just need to run their code for 20 minutes every day, why should they launch an EC2 instance or recursively invoke Lambda Functions?
- More supported languages: I can think of native support for Ruby, PHP, Swift, Python 3, etc. If you want to make a developer’s life easier, native support will be a big help. And no, supporting Docker is probably not the ultimate solution.
Let us know if you have interesting improvements to add to our wishlist, and meet us at AWS re:Invent next week!
