Once we have developed our applications in the form of functions, we need a place to host and run it. This hosting place for the functions is provided by the cloud service provider. Now, once we have successfully hosted these functions and implemented rules when a particular function should execute, it is the duty of the cloud provider to handle the correct execution of these functions.

Now, when these functions have to execute, the cloud provider determines the correct environment that will be required to execute a particular function. Once this environment has been determined, the cloud provider launches an ephemeral container inside which the function code resides. This container provides the function a complete isolation from the other functions that might be executing in the environment. Now, once the container has launched successfully, this function executes, and provides a response back.

The interesting part happens once the function has completed its execution. Once the function has completed execution, the cloud provider can either terminate the container instance in which the function was running or it can keep it alive to handle newer requests. Most of the time, the decision is taken based on the frequency of the requests that are arriving and the kind of policies that have been set by the user.

If a function instance is still running and waiting, a new incoming request might be redirected to that instance only, whereas if there are no ideal instances of a function running, the cloud provider will launch a new instance and redirect the request to that instance.

With this, we have a good idea of how FaaS works inside the serverless architecture and how it enables us to develop serverless applications. But how are these functions actually triggered? This brings us to another important component that comprises the serverless offerings. Let's take a look at what it is.