Universal Serverless Experiment

Is write once, run everywhere possible for serverless computing?

This experiment tries to do two things:

create a package that can be deployed to as many serverless platforms as possible
provide adapter code so that all serverless platforms can execute one single, platform-agnostic function

With following limitations:

Assumes that the runtime is node.js (version 10+)
The only supported trigger is HTTP
None of the outbound platform APIs will be abstracted

Compared to other approaches like Serverless @multicloud this project:

does not require any code changes to adapt code from one runtime to another
does not depend on a framework

Try it

$ curl https://serverless.project-helix.dev/hello

You will get the same function results, from a randomly selected runtime.

Supported Runtimes

Apache OpenWhisk
AWS Lambda
Azure Functions
Google Cloud Functions

API

// we use the fetch API, and node-fetch is a good approximation
const { Response } = require("node-fetch");

module.exports.main = async function(request, context) {
  let body = "hello world!\n\n";
  
  try {
    body += JSON.stringify(context, null, "  ");
  } catch {
    body += context.toString();
  }
  
  body += "\n" + request.url;
  body += "\n" + request.method;
  body += "\n" + request.headers.get('user-agent');
  body += "\n" + await request.text();
  
  return new Response(body, {
    status: 201,
    headers: {
      'Content-Type': 'text/plain',
      'X-Generator': 'hello world'
    }
  });
}

`request`

Is a Request object.

`context`

Is an object with following properties:

runtime.name: name of the runtime, e.g. aws-lambda
runtime.region: where the function is executed, e.g. us-east1 – the names are not consistent across runtimes
func.name: name of the function, e.g. hello
func.version: version of the function, e.g. 0.0.53 – the versioning schemes are not consistent across runtimes
func.app: name of the application, project, namespace, or other container of the function
invocation.id: a request ID as generated by the runtime. Formats differ dramatically
invocation.deadline: timestamp (milliseconds till epoch) when the runtime will terminate the execution and time out. Not available for Azure
env: environment variables and other runtime-managed parameters (e.g. default parameters in OpenWhisk)

`return`

Return something that looks like a Response object. We honor: status, headers, body

Known Limitations

no unit or integration tests, no CI

Next Steps

A service that deploys function from a zip file

Developing

# create a zip file
$ sh build.sh

# deploy it everywhere
$ sh deploy.sh

# fetch the results
$ sh test.sh

trieloff / universal-serverless