AWS open sources serverless model: What you need to know
Just ahead of this week’s re:Invent conference, Amazon Web Services (AWS) released an open source runtime application model for its Lambda functions-as-a-service (FaaS), and the rest of its Lambda-based serverless infrastructure. Renamed AWS Serverless Application Model (SAM), the model prescribes rules for building serverless applications in the AWS ecosystem. Here's what you need to know.
Despite its vendor-specific nature, the announcement should interest all developers who are investigating serverless technologies. Amazon was one of the first companies to offer serverless/FaaS, and Foresight Data System’s CTO and principal consultant, Dean Hallman, who is currently attending the re:Invent conference this week, sums it up as such:
"AWS's SAM framework is the latest entry into the burgeoning serverless application frameworks space, offering features that partially make obsolete and partially complement, existing offerings such as the Serverless Framework, Apex, Chalice, DEEP, Gordon and others."
Here are key details about the release:
Flourish becomes AWS SAM
Amazon teased the AWS SAM release back in May at ServerlessConf. At the time, they were calling the project “Flourish.” The speaker, Tim Wagner, compared Flourish to SwaggerHub, saying that Flourish would grow a runtime model similar to the way SwaggerHub allows developers to define and manage APIs throughout the application lifecycle using the Swagger framework.
Wagner, the general manager of AWS serverless computing, is hoping that a large developer community will form around AWS SAM to build more patterns and paradigms for serverless development. That’s why you’ll find it under the Apache 2.0 open source license.
However, Hallman, who admits he is still in the process of assessing all the implications of AWS SAM, says that right now he doesn't consider it to be a completely open source utility. "While AWS has released some example SAM templates to open source, I still view SAM as primarily a closed system."
"In other words, while the YAML and JSON examples used to program the CloudFormation server-side state machine have been released to open source, the engine that processes these SAM templates (e.g. CloudFormation) is very much an AWS-proprietary system," Hallman says. "And whereas the Serverless Framework, Apex, Chalice and others can easily be forked or extended via plugin architectures, our ability to override core CloudFormation behaviors is more limited."
What AWS SAM brings to the table
AWS SAM is based on AWS CloudFormation, which defines serverless applications with templates. Essentially, a CloudFormation template is now the same thing as an AWS SAM template. AWS SAM shows developers what objects they can use in a template to model a serverless application.
A serverless application might use DynamoDB tables, S3 object storage, and Amazon API Gateway resources as components. The key benefit that AWS Sam provides is a new simplified syntax to describe the components being used. This template can be either a YAML or JSON file.
Right now, some of the interesting AWS SAM components available include:
- AWS IoT rules
- Amazon Kinesis objects
- Amazon SNS notifications
- API actions
- S3 objects
- DynamoDB tables
- CloudWatch events
- Alexa events
Getting started with AWS SAM
Chief AWS evangelist Jeff Barr shared some tips and screenshots on how to generate AWS SAM files using two different methods. In another announcement of AWS SAM, Orr Weinstein, the senior product manager for AWS Lambda, gives examples on how to use several different components in AWS SAM templates. He also provides a real application example using an AWS SAM template. So far, these are the two initial tutorials on using AWS SAM. You should also check out the GitHub page, which documents how you can use AWS SAM and provides template examples, as Hallman mentioned.
AWS Lambda blueprints are also now exportable as AWS SAM templates, says Ajay Nair, the lead product manager for Lambda.
What is serverless and why should you care?
As a quick aside, you might want to know why people care about serverless architecture. First let's define serverless.
The most basic definition of serverless architecture is an application that is composed of functions triggered by events using a service like AWS Lambda to handle the loading and execution of the application code as well as the provisioning of sufficient computing resources.
The primary benefits of serverless architectures include:
- The ability for developers to focus purely on application functionality and code
- A linear relationship between the efficiency of an application’s code and the cost of running it
- A code execution system that only runs when needed
- A significant advantage when running event-driven apps that require only short-duration, single-event transactions
Peter Sbarski 's "The essential guide to serverless technologies and architectures" provides an excellent primer to the serverless space. To get a more in-depth definition of serverless, you should read Mike Roberts’ article on serverless architecture. And if you'd like to see why serverless will fundamentally change how you code and how we build a business around technology, read Simon Wardley’s article “Why all the fuss about serverless?”
Serverless is well positioned to play a central role in enterprise development. Its primary use case will be event-driven applications, which encompasses a growing number enterprise applications as well as IoT applications and user-driven content submission applications.
AWS SAM implications for third-party serverless frameworks
Hallman sees fundamental differences between third-party serverless frameworks, and AWS SAM's approach.
"Virtually all third-party solutions build up a 'deployment context' containing environment variables, resource ARNs for FaaS rewiring, stages etc. on the client-side using locally-running languages, like Node, Go, etc," Hallman explains. "By contrast, AWS SAM moves this 'deployment context' essentially to the server side, by bolstering the provisioning capabilities of AWS CloudFormation."
Instead of a mostly functional approach executing locally, Hallman points out that AWS SAM is entirely declarative, building a deployment context on the server side and using a YAML or JSON specification to transform and rewire its state.
"In short," Hallman continues, "CloudFormation had been used by the earlier entrants into the serverless frameworks space as a kind of wire-protocol for provisioning resources and wiring them up to FaaS (Lambdas), events, and APIs; now, that wire-protocol has absorbed much of that third-party framework value-add. Many of these third-party solutions will adjust, pushing more of their variable-keeping and rewiring logic into CloudFormation, via AWS SAM, while sharpening their focus on more application-centric value-add and multi-cloud 'polyfill' concerns."
While compelling, AWS SAM does have some potential drawbacks when compared with the approaches taken by third-party solutions, Hallman warns.
"[AWS SAM] is not designed to foster a provider-agnostic serverless application codebase that could be more easily re-targeted to a different cloud-provider should that business need arise. Some view that as an important backup position, while others are loathe to accept the least common denominator-approach that such solutions often imply."
If you are in the latter camp, then you should consider how AWS SAM adoption might help streamline and potentially integrate the DevOps and engineering processes within your company, Hallman says.
AWS SAM implications for integrating DevOps and engineering processes
The AWS SAM release is the second in a series of significant and recent expansions of the AWS CloudFormation feature set, Hallman notes. In September, Amazon added cross-stack references, YAML support, and simplified substition to CloudFormation.
The September update and this month's AWS SAM release "reposition CloudFormation from a more static Infrastructure as Code (IaC) solution, to a more dynamic provisioning and deployment workflow management system that has the potential to remake how DevOps and engineering teams collaborate in the enterprise."
The roadmap for AWS SAM's collaboration workflows has been left as an exercise for the open source community to fill in, says Hallman.