Page History

...

The Control Plane should provide an API used by the Data Plane to cold-start actions, and it should also emit events each time a change in the resource allocation happens; each time GC removes idle containers, or each time a new action is created, the Control Plane should notify all Data Plane instances of such changes. 

Data Plane

The data plane layer invokes actions as fast as possible. When an action needs to be cold-started, the data plane delegates this to the Control Plane, awaiting for the action to become ready before invoking it. Once an action is warmed-up the data plane is notified, and if it was waiting for such event in order to invoke an activation, it should resume the execution. 

...

1. The request arrives from a client
2. Authentication and Authorization
   1. The Container Router validates the Authorization header with OpenWhisk Auth Service
   2. The response of the Auth Service is cached 
3. Routing
   1. Check namespace limits
   2. Forward the request to a container selected from a list of warmed actions that the Action Router keeps. 
      1. (new) Streaming the request to the action would be a nice; OpenWhisk doesn't have support for this, and such feature could remove the max payload limits
      2. (new) Websockets could also be supported, another missing feature in OpenWhisk.
4. Container Proxy sidecar
   1. Check action concurrency limit
   2. Buffer a few more requests, queueing them into an overflow buffer; this may be something useful when cold-start could take longer than just queuing a few more requests. Blackbox actions that need to download the docker image may benefit from this more. This idea is inspired from KNative Serving. 
5. Invoke the action and return the response
   1. (new) Caching the action response could be another nice to have feature, which is not implemented in OpenWhisk. Caching should be controller by the action response.
6. Collect activation info.
7. Sequence support.
   1. If the action is part of a sequence, then the Router should have logic to invoke the next action in the sequence.
      1. Other ideas to explore to support sequences, should the support in the ContainerRouter is too difficult to implement
         1. ContainerProxy could "understand" sequences
         2. Or reuse Composer and implement sequence-as-an-action.  

Flow for cold-start

When the Action Proxy is at capacity, it should return a 429 message back to the Container Router. A Retry-After  header could specify <delay-seconds>  or <http-date>  for a CircuitBreaker in the ContainerRouter to avoid routing to that action. The time window for retry should ideally be computed from the response times observed by the Container Proxy. 

...

OpenWhisk already integrates with Prometheus. See https://github.com/adobe-apiplatform/openwhisk-user-events 

Throttling/Limits

Namespace limits

Limits such as max concurrent action containers per namespace could be enforced by the Container Router. 

Action limits

Limits such as concurrent requests per action container could be enforced by the Container Proxy.TBD

Previous discussions

Provide support for integration with Kubernetes. One approach could be to deploy and run the components on a Kubernetes provider as we do for Vagrant, Docker, Docker-Compose, and OpenStack.

...