Developers of the world, unite! You have nothing to lose but your servers -- well, sort of.
The Serverless Framework, a system for building applications using so-called serverless architectures, is now out in a full 1.0 release after several months of work.
Formerly known as Jaws, the Serverless Framework makes it easier to build and deploy applications using event-driven systems like AWS Lambda. Developers create the service on their local machines with a Node.js-powered CLI, then push it out to a given provider with a single command.
Look, Ma, no servers!
Apps created with Serverless Framework can be triggered by events specific to the provider they're deployed to. For an API gateway, this would typically be an HTTP request, but on Amazon this can also be an S3 or SNS (Simple Notification Service) event, an AWS Schedule event, or stream events from DynamoDB or Kinesis.
The kinds of events available aren't hard-wired into Serverless, but are supplied by a provider definition. Right now, there's only one supported provider, Amazon Web Services, but plans are on the table to support other services, such as Azure Functions.
Serverless's behavior also can be extended, such as to add new commands or hook existing functions (such as perform an action before or after deploying to a remote server), thanks to its plugin architecture.
When first introduced as Jaws, it allowed developers to automatically leverage many of Amazon's existing resources for their apps, such as rate limiting and scaling functions. The main difference between the Jaws version of Serverless and its current incarnation is that Serverless makes more complete use of Amazon's existing automation resources, namely CloudFormation, so there's less reinvention of that wheel.
Deploy once, deploy everywhere
The term "serverless computing" might be better described as "administration-less computing," a distinction InfoWorld's Eric Knorr teased apart earlier this year. Instead of worrying about how many instances of what kinds of services to spin up, developers concentrate exclusively on application logic that reacts to external events, and leave all architectural details to the provider.
Serverless provides two other big advantages: One, it make the actual act of deployment as minimal as possible, allowing devs to concentrate on the actual code.
The other advantage is that Serverless is meant to be service-agnostic. In theory, the same app can be deployed across multiple clouds -- or, more important, moved between clouds -- without getting bogged down in the implementation specifics for each cloud. In practice, that'll require delivering support for more providers than Amazon alone.
The folks behind Serverless have two basic plans for making all that happen. First and most obvious is releasing Serverless as open source under the MIT license; second is to use its $3 million in seed funding, courtesy of Trinity Ventures and others, to build out Serverless and provide resources for it. But "The Serverless Framework was born as and will always be open source," states Serverless, Inc. -- a good contrast to the largely proprietary architectures it's being built to deploy to.