Overview of the Serverless Workflow Model

In this post we present a quick overview of the workflow model as defined in the Serverless Workflow specification.

Note that the specification is still a work in progress and is subject to change. You can reference the specification roadmap to see the projected release status.

Serverless Workflow uses JSON or YAML formats for defining workflow models. The entire workflow model is described using JSON Schema which you can find here.

The core workflow definitions is very simple:

"Core workflow definition elements"

Each workflow model has a unique id. It can also have a version, a name and a description. 

The "startsAt" parameter defines the starting point of the workflow.

Next thing to look at is a list of reusable function definitions. Function definitions express how to invoke needed services during workflow execution. Since multiple workflow states may need to invoke the same services, defining them on the workflow top-level allows us to describe their  invocation information only once. We will go into function definition specifics in future posts.

Events play a big role in serverless orchestration. After all, we are focusing on orchestrating event-based applications running in the cloud. 

Let's take a step back and define what an event is. An event is a data record expressing an occurrence and its context (information).  Events are things that happen that we want to act upon. "A file was uploaded", or "Email was received", or "Application was submitted", or "Purchase was made", all can be considered important events that our workflow must act upon. Events are often described as "triggers". They can trigger workflow execution and/or actions (function calls for example).

Events must have a format which describes them. Currently mane different event formats exist which makes it virtually impossible to have a single event description that would work across multiple cloud providers. 

To solve this problem, the Serverless Workflow specification mandates for events to conform to the CloudEvents format.  CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.  

Going back to the workflow model, the "events" array includes reusable event definitions. Their definitions can be referenced by different workflow states. 

We will go much deeper into event definitions and how the are used in future posts.

Next, and probably the most important part of the core workflow definitions are the workflow states. States are building blocks of our workflows. Each state defines a certain control flow logic block and combined define the overall control flow logic of our applications or orchestration. States can reference the defined functions and events. 

Serverless Workflow specification currently defines nine states:

"Workflow States"

We will have dedicated posts for each of the states in the near future so stay tuned. If you can't wait, feel free to dive into the entire specification and check out the many examples available currently.

I hope this this quick intro has given you a good look into the core serverless workflow model. 

Again, we are looking for community contributors for the specification, so feel free to get involved!

- Tihomir Surdilovic -