With the demo application in place, it's time for us to understand how the execution of this application works behind the scenes.

Behind the successful execution of the application, there are several steps involved which start from the wsk action invoke command that we ran to execute our application. So, let's take a look at the steps that happened behind the scenes:

1. Making the API call: Every action that we build to deploy on OpenWhisk is mapped as an API endpoint that will invoke the action. When we run wsk action invoke, the command makes a call to the API endpoint that has been mapped for the provided function. This call is then intercepted by Nginx inside OpenWhisk, which acts as a termination point for SSL and then invokes the controller.
2. Processing by the controller: The controller, which is an implementation of the REST API, disambiguates what the request is supposed to do based on the HTTP method used for the request. Once the ambiguity of the request has been resolved, the controller then resolves the action that needs to be invoked. Beyond this, the controller has a few more duties to perform:
   • Validating Authorization: The controller verifies whether the user is authorized to invoke the action based on their privileges with respect to the action that needs to be invoked.
   • Fetching the action: The controller fetches the action from the actions database before the action can be invoked.
3. Finding the invoker: The action needs an invoker that can execute the action. For this, the controller queries the service discovery service inside OpenWhisk, which provides it with the list of the invokers that can invoke a provided action. Based on the list, the controller determines a free invoker on which the action can be invoked.

4. Communicating the Request: The controller communicates the request to the invoker through the use of Kafka, which is a distributed message platform that handles the processing and delivery of the messages from the producers to consumers. In this case, the type of execution was asynchronous; an action ID is provided to the user as soon as the controller has delivered the message to Kafka.
5. Invoking the action: The invoker fetches the message from Kafka and invokes the action by launching a docker-based container inside which the function code executes.
6. Storing the results: The results of the invocation needs to be stored somewhere from where they can be queried later. For this, OpenWhisk stores the results in its database, from where they can be queried again using an Action ID.

This is how our serverless code executes behind the scenes with OpenWhisk. Now, with this knowledge, let's take a look at the advantages that a shift to the serverless development approach provides us.