In April 2017 we had announced work on an open marketplace for cloud functions, lambdas and other serverless application artefacts and launched a first static website at Github Pages. The project was sidelined, but in January 2018 we made the implementation called Function Hub publicly available and have since been running a stateless dynamic demo instance with the backend running Snafu in passive mode in our APPUiO Swiss Container Platform account. You can use any deployment tool (awscli, wsk, gcloud) to submit your cloud functions and make them available globally.
It took Amazon a bit longer until February 2018 to announce their AWS Serverless Application Repository but of course there it is now with, at the time of writing, 181 entries. We assume that it will grow rapidly and developers will very much rely on it in the future, similarly to how Docker Hub has become an essential ingredient for modern application development, and see the need for researchers to (1) gain insight into cloud function marketplace usage, (2) propose superior designs, and (3) from an applied perspective of strengthening the economies of souvereign countries, assist in developing viable alternatives. This blog post therefore briefly discusses our state of function hub design and prototypical architecture which is shared work with the Distributed Systems and Parallel Computing research group at Itaipu Technology Park, Paraguay.
The evolving design of Function Hub foresees a fully decentralised operations model with all the pluses and minuses attached to this topological choice. Hubs are stateless entities which aggregate their content from the function implementation repositories of attached FaaS runtimes while the attachment information is also distributed into multiple evolving registries to ensure no local state and no centralised source of information needs to be used. FaaS runtimes can furthermore broker the shipment of cloud functions among each other. For example, one instance of a serverless platform may get a request to execute a function which is stored in another one and fetches it on demand before execution. We foresee the use of standardised federation and distributed storage and versioning protocols for that matter.
The current prototype of Function Hub, after several iterations, is thus built on top of a network of XMPP-federated Snafu instances running as multi-tenancy-capable FaaS platforms. Snafu already offers a connector (trigger) to invoke functions through XMPP, in addition to HTTP and other means, but its control plane remains by design compatible to the function management interfaces of other implementations such as AWS Lambda, IBM Cloud Functions and Google Cloud Functions. Therefore, the solution of choice is the use of a bidirectional simple XMPP-to-HTTP gateway which registers as XMPP client and receives messages from the Function Hub, dedicated clients or plainly a chat client for listing and downloading functions or, with appropriate permissions, uploading and modifying them. Additional API methods may still be added on the HTTP layer if no de-facto standard protocol equivalent exists.
The Function Hub marketplace allows for rich interactions. Cloud functions can be inspected through metadata and optionally code, their implementation downloaded if permitted, they can be tested in attached isolated execution environments (through temporary deployments), and finally they can be deployed in associated platforms. While at the moment only Snafu is supported as research prototype, other systems including the commercial offerings from cloud providers as well as open FaaS platforms may be considered. This rich interaction scheme contrasts the rather simple model of the AWS Serverless Application Repository which only provides one-click deployments into a single centralised platform.
At the current stage, we consider Function Hub mostly a design study with initial prototype. The most recent implementation is available in a Git repository. It encompasses a containerised version of Snafu acting as FaaS runtime and repository for cloud function implementations, the marketplace prototype, and middleware to connect runtime instances to the marketplace. Code enhancements and documentation will be gradually added as needed for enabling future research and piloting cases.
However, beyond the current implementation we intend to work further on decentralised ecosystems and welcome feedback on this matter. For instance, function developers might be interested to get general metrics on their artefacts including popularity, measured quality and achieved revenue. Using the FaaS converter, functions developed for one system might be automatically provided for others. Companies will be able to use the hub to develop company-internal ecosystems. The six predicted trends for the future of the serverless market may also influence further work. Stay tuned for more ideas!