If you’ve been following the community around API Gateway and Lambda, you’ve
specifically aimed at serverless development. Today, they announced a new
version and a new name. The
artist formerly known as Prince project
formerly known as JAWS has moved to serverless/serverless on
Github and serverless.com is their new domain.
One of the biggest new features is that it uses the builtin versioning and aliases to handle request routing to multiple code versions. Versioning seems (so far) to be pretty under-used by lots of Lambda users, but is vital to teams bigger than just one person.
Versioning lets you can set different stages of your application (test, staging, prod) to use different versions of the Lambda functions that back your application. This means you can support multiple API versions simultaneously if you want to.
The Serverless team has also moved off CloudFormation in favor of custom scripts. Most of the reason for this move is the lack of CloudFormation support for event sources and API Gateway resources.
Quick Vocabulary Lesson
Serverless has some terminology you’ll want to know before diving in
A collection of modules, endpoints, and configuration that is a single deployable unit. Each application you build should probably be a single project. You can deploy a project to multiple stages (prod, staging, etc).
In Serverless, a module is one of the components of your project. A module should be a self-contained piece of reusable functionality, like sending notification emails or handling service webhooks.
Plugin support isn’t done yet, but when it is you’ll be able to integrate actions into each step in Serverless. Plugins might be adding external resources, build systems like thaumaturgy, or just about anything else.
As the migration winds up and the plugin API is defined expect to see more plugins and more modules become available.
A function in Serverless maps directly to a Lambda function, and is contained within a module. Modules can have as many functions as you want, but try to keep them logically grouped so you can reuse modules.
Of course, the best way to get familiar with the framework is to head to serverless/serverless and try it out for yourself.
Make sure to check out the Serverless framework docs and thank the team @goserverless on Twitter. As always, if you have an idea, question, or comment email email@example.com or find @ryan_sb on Twitter.