Research task: federated gateway/provider

[alexellis]

Research task

Show how one or more gateways can be federated

Use-case

• centralised control-plane
• multi-tenancy with hard separation of workloads
• multiple providers - i.e. faas-lambda and faas-netes at the same time
• multi-region / globally distributed cluster i.e. East/West/Europe

Expected Behaviour

As a user with access to the faas-cli I would contact an OpenFaaS gateway and due to my user or perhaps some annotations or constraints that would cause the gateway to contact one or more other gateways another hop along.

Example

If we have for instance two Kubernetes clusters and installations it may look like this:

faas-netes - east coast (named east) faas-netes - west coast (named west)

When deploying a new function I may want to deploy to both or just one. It may be done through configuration at the federated provider / gateway level or through annotations in the function spec.

I would expect it to be relatively simple to make a PoC to show two gateways URLs being invoked from a single new provider named something like faas-federated. https://github.com/openfaas/faas-provider/pulls

Another example may be functions which cannot fit within local capacity can be directed to another federated gateway.

Functions could also be split between faas-lamba and faas-netes where the former work well in a Lambda runtime and the latter require a "full container" owing to size/memory requirements or data stickiness.

I'd like to know from the community if you think this is useful and how you'd see it working.

[matipan]

I like the idea of being able to have gateways on different zones and be able to deploy to the one where the resources the function accesses are closer. I'm not sure how helpful this will be for our users, in my case I don't really need it.

I believe that if someone out there is building a FaaS platform on top of OpenFaaS this will definitely be a somewhat necessary feature(so that their users can deploy functions to different zones without much trouble)

[ewilde]

Derek assign: me

[ewilde]

I'm working on a first version of this that will route functions based on annotations, will report back on this issue when I have something to show

Annotation	Description
federation.provider_name	route the request based on the provider name i.e. kubernetes, swarm

[alexellis]

federation.provider_name is quite verbose. What if we used a constraint or a shorter annotation key?

[Templum]

I hope this is still open for some input. Overall it is a pretty interesting topic. Based on the shared use case I could see the following way of implementing it:

Extend the current implementation of the OpenFaaS Gateway to feature an Raft Consensus Algorithm. Which is used in combination with something like Zookeeper, where Gateway can register themselves and further provide some meta information (zones, faas-providers, ...).

Based on the Raft Algorithm one or n Masters get elected, incoming requests will be forwarded to them and then forwarded to the target node based on zones or other meta information. The Zookeeper cluster would be the source of truth in regards to connected/disconnected nodes, overall resiliency could be improved by storing the connected nodes in a local cache.

OpenFaaS Cli would need to be extended in order to provide that information during deployment and invocation.

Hope the explanation is enough to get the concept, any ideas on it?

[alexellis]

Derek close: https://github.com/openfaas-incubator

[alexellis]

Thanks for your input @Templum - please see the upstream repo that we put together with @ewilde