As OpenWhisk is an event-driven platform, any kind of event fired to it could be intercepted and interpreted. However, in this example, we will show you only the event triggered by sending a direct request to the gateway.

The invocation flow starts with an invocation request in the form of an HTTP-based request and is sent to the API gateway. For example, we can use the wsk CLI to initiate this kind of request. After the API gateway receives the request, it will forward that call to a controller behind it.

One of the most important components of OpenWhisk is the controller. The controller is a component written in Scala using the infamous framework Akka and Spray to implement a set of REST APIs. The controller accepts all kinds of requests; if it accepts a POST request, it will interpret it as an invocation of an OpenWhisk action.

The controller then starts to authenticate and authorize the access of the requested action.

The controller will look up the credential information and verify it against the data stored in an instance of CouchDB.

If the action is not found, the controller simply returns 404 back to the caller, for example. Also, if access is denied after verification of the credentials, the controller will send a chunk of JSON back to the caller saying that they are not allowed to access the action.

If everything is granted, the controller goes to the next step.

The controller then again looks up the information about the action: what it is, what kind it is, and how to invoke it.

In our case, we use Docker as an action primitive. So, the controller will find that our action is a blackbox. Now it's ready to invoke the action.

The controller will not make a request to an invoker directly; instead, it will make a request to a Kafka cluster, the backbone of the messaging system. As previously mentioned, using Kafka could prevent the loss of the invocation, as well as make the system robust by queuing the invocation when the system is busy under heavy load.

So the controller publishes a message to Kafka. The request message contains all information needed to invoke an action. This message is also persisted by Kafka so that it can be replayed when the system crashes.

Once Kafka gets the message, the controller is responded to with an activation ID to later obtain the result of invocation.

On the other side of Kafka, a set of invokers subscribe to the requested messages. Once a message is available in the queue, an invoker will be notified. Then the invoker will do the real job, invoking the real Docker container. After it gets the results, the invoker stores them in the instance of CouchDB under the same activation ID.