Orchestrate event-driven, distributed services with Serverless Workflow and Kubernetes
Serverless workflows have gained renewed interest and usefulness with the rise of serverless architectures. Once seen as centralized and monolithic, they now play a key role in cloud-based event and service orchestration. Until recently, there was no vendor-neutral way to describe service orchestration, so developers were dependent on vendors and vendor implementations. We realized that we needed a common, standards-based language for describing serverless workflows.
In this article, we introduce the Serverless Workflow specification, now in its 0.5 version release. Our goal with this project is to empower anyone to develop serverless workflow libraries, tooling, and infrastructure for modeling workflows across different cloud platforms.
About the Serverless Workflow specification
The Serverless Workflow specification defines a common, declarative, domain-specific language for workflows. Developers can use it to describe both stateless and stateful orchestrations. The specification is a Cloud Native Computing Foundation (CNCF) sandbox project hosted by the CNCF Serverless Working Group.
The Serverless Workflow project’s main focus is hosting a vendor-neutral, portable, community-driven workflow language based on standards rather than proprietary definitions. We’ve targeted the orchestration of event-driven, distributed services. You can use both YAML and JSON formats to describe a workflow using the Serverless Workflow specification.
Structure of the Serverless Workflow language
Figure 1 shows the structure of the Serverless Workflow language. The structure includes three main parts. Each part builds on existing standards.
In the next sections, we’ll describe the three main parts of the Serverless Workflow language structure.
Part 1: Defining events
Serverless Workflow utilizes the CloudEvents specification for defining events that can be consumed or produced during workflow execution. The specification defines a clear one-to-one mapping between how events are defined within the CloudEvents format and how you define them in your workflow language definitions. You can use CloudEvents context attributes to define one or many event-correlation rules. Event definitions in Serverless Workflow are reusable, meaning that you can reuse them between multiple workflows. Figure 2 shows an event definition in the CloudEvent format compared to the same event definition in the Serverless Workflow format.
Part 2: Defining services or functions
Serverless Workflow uses the OpenAPI specification to define the services and associated operations that will be invoked during orchestration. To define a service operation, you only need to specify the path to the OpenAPI service definition(s) and select the unique operation ID for the service operation that you want to invoke. Figure 3 shows Serverless Workflow service definitions in relation to their OpenAPI definitions.
As shown in Figure 4, Serverless Workflow lets you describe the invocation of both RESTful and event-triggered services or functions.
Part 3: Defining the control-flow logic
Serverless Workflow defines pattern-based control-flow logic constructs for defining what will happen during workflow execution. You can define workflow states or steps and their associated transitions, error handling, retries, data management, and more. Figure 5 shows control-flow logic constructs in Serverless Workflow. You can use these to define simple sequences and more complex constructs such as parallel executions, looping, retries, and user interactions or decision steps for controlling the overall orchestration.
Additional components of Serverless Workflow
In addition to the workflow language definition described in the JSON Schema definitions, specification, Serverless Workflow provides a set of language extensions. The extensions enhance workflow definitions to improve the overall performance, cost, and effectiveness of an orchestration. Serverless Workflow also provides software development kits (SDKs) for Java, and Go, with more planned in the future. Additionally, it includes a Visual Studio Code extension and an online editor, providing useful features such as code completions and diagram generation for both JSON and YAML workflow formats. Figure 6 shows components of the Serverless Workflow project.
Use cases for Serverless Workflow
You can use the Serverless Workflow specification language for various use cases, including payment processing, data analysis, continuous integration deployments, and many others. The specification’s use cases document describes several use cases in detail. Figure 7 shows a flow diagram for a sample use case.
Video demo: A Kubernetes use case
Serverless Workflow is well-suited for container environments. You can directly translate its event and service definitions into Kubernetes-specific constructs such as brokers, sinks, and so on. See our KubeCon + CloudNativeCon North America 2020 talk for a demonstration of how to deploy Serverless Workflow to manage and orchestrate services running on a Kubernetes cluster.
Get involved with Serverless Workflow
The success of the Serverless Workflow project depends on community involvement. We invite anyone to join and contribute to our weekly community meetings. The community meeting is a good place to bring up questions about the project. You can also use the Serverless Workflow GitHub repository to raise issues or reach out to us on the Serverless Workflow community Slack channel.
Serverless Workflow is a portable, community-driven workflow language that is based on existing standards. Being part of the CNCF cloud-native landscape ensures its continuous growth, development, and usability. Serverless Workflow is the leading vendor-neutral workflow language in the serverless space. Our goal with this project is to empower anyone to make a difference in the evolution of container orchestration.
You can use the following resources to learn more about the Serverless Workflow specification and how to use it in your projects: