Thursday, March 12, 2020

Introducing the Serverless Workflow Specification

"Serverless Workflow is a vendor-neutral specification 
for defining the model of workflows
responsible for orchestrating event-driven serverless applications."


It is apparent that workflows have become a key component in serverless application development, and this is good news for many reasons. 

For once workflows have been around for years in many different shapes or forms. The term "workflow" is used interchangeably today with the term "business process", a set of repeatable activities that need to be carried out to accomplish some sort of business/organizational goals. 

Separation of concerns is one of the core benefits of using workflows - the ability to cleanly divide responsibilities in your applications with the overall goal to create well-organized systems.

Another core benefit is encompassed in the word "orchestration" which basically means coordination and management of services and events. This is specifically important in cloud environments where our applications are composed of many loosely-coupled, distributed, event-triggered services deployed across multiple clouds. This architecture almost demands orchestration, or the need to tie and coordinate all these services and events together to describe clear business-oriented tasks and goals.

Many of the major cloud providers have adopted workflows as first-class citizens in their service offerings, with the major ones being:



As well as many many others, most notable ones including Fn Flow, StackStorm Orquesta, Netflix Conductor, Fission Workflows, etc.
It feels as there is a new serverless workflow offering coming out every month now and the numbers keep growing.

Even tho this growth and popularity is very encouraging, it creates some big issues for companies trying to adopt workflows in their serverless architectures with the major one being a complete vendor-lock.

Once you commit to a workflow solution offered by a cloud provider there is "no way out".
To explain why this is the case, we have to look at the two pieces which allow our wokflows to become "executable" in any environment:


  • Workflow model - the definition of what the workflow does. This is typically described in a markup language format such as XML, JSON, YAML, etc
  • Workflow runtime - the runtime engine which interprets the workflow model into an executable application.

Current serverless workflow offerings define proprietary implementations for both the workflow model and runtime. This makes it impossible to port your workflows from one vendor to another, thus falling into a vendor-lock.

To get out of this, there is not necessarily a need for a vendor-neutral workflow runtime implementations, quite frankly this is not possible. However this is possible to achieve on the workflow model level which is the core goal of the Serverless Workflow Specification we are introducing in this post.

Serverless Workflow is a specification being worked on by the CNCF Serverless Working Group and hosted by the Cloud Native Computing Foundation (CNCF).

The main goals of the specification include:


  • To facilitate Serverless Workflow portability across different vendor platforms
  • To be completely vendor neutral
  • To support both stateless and stateful Serverless Workflow orchestration
  • To define a light-weight and powerful Serverless Workflow model

The Serverless Workflow specification is completely open-source and operates under the Apache License version 2.0.

It is currently still in its infancy, but has an active community consisting of companies and individuals that have shown interest in moving it forward.

I am personally heavily involved in this specification and think that adoption of this specification will enhance the adoption of workflows in serverless applications.

I would like to encourage all readers to contribute to this specification to help it grow.

We will address specifics of the Serverless Workflow specification in further posts. For now I just wanted to introduce it to the public and raise interest. Looking forward to hear your thoughts and comments!

- Tihomir Surdilovic -











No comments:

Post a Comment