Lifecycle Hooks

[lkingland]

Lifecycle Hooks

This is a discussion about the specification and implementation of basic lifecycle hooks for Functions.

Overview

Functions are an abstraction on a full-featured network service. They are instantiated, live and die in the same manner. As long-lived processes, we can provide hooks for the Function developer to certain lifecycle events. In addition to the base two methods defined in #2080 (the constructor and request handler), we can also provide hooks for starting, stopping, health checks etc.

Functions which use the instance-based constructor will be able to provide hooks for the following base set of lifecycle events. All code examples are in pseudocode, with the exact implementation varying slightly from language to language.

.Stop()     # Invoked on a stopping Function instance (time-bound).
.Alive()    # Invoked on liveness checks.
.Ready()    # Invoked on readiness checks.
.Start(cfg) # Invoked on a newly started Function instance

On Stop Event

When the Function process receives the OS signal that it is being shut down, this event causes the Functions middleware to invoke the Function instance's Stop() method. This can optionally return an error which should be propagated out of the process such that the final exit is non-zero.

On Liveness and Readiness Checks

The Functions middleware will create a default readiness and liveness check handler for the endpoints. These will always respond with an acknowledgement if the process is available and nonblocked. The Function can optionally implement .Alive() and .Ready() to provide custom implementations for these queries.

On Start

In order to keep the base case as simple as possible, the steps of instantiation (construction) and initialization (starting) are separated. The constructor method signature is left with neither arguments nor an error return to ensure that the simplest possible Function method signature is always an option.

To provide initialization (especially based on environmental configuration) a separate .Start(cfg) is allowed. The argument cfg is a map of all environment variables.

Environment Variables are for the boundary between the OS and the process. Since the Functions middleware now occupies this boundary, allowing a Funciton instance to be a clean library, it is necessary to pass these values through to the Funciton instance as the argument map that it is. A Function accessing environment variables should be considered an antipattern when using the instanced function paradigm. This is because one of the key strengths of a function is that it is portable. Accessing environment variables from within a library is anathema to both this and idempotency (as elusive as that is in practice)

For example

New()       #  Simplest possible constructor
.Start(cfg) # Optional start handler with access to config

Future Hooks

Additional Lifecycle Events not covered in the initial implementation might include:

.Create()	# Invoked on first instance when Function first created (first deploy).
.Update()	# Invoked on all instances when Function updated (redeployed).
.Delete()	# Invoked on last remaining instance when deleting.

Example

To see how this works in action, an initial implementation has been completed for the Go language, and is demonstrated as a screencast.

Summary

Input on this initiative would be greatly appreciated. It is no exaggeration to say that defining the base set of method signatures supported by Functions is one of the most important decisions we can make. This is the contract between the Functions Toolchain and Functions Developers.

Please see the associated Epic Issue #2025 where individual tasks are in the process of being enumerated.