Serverless drives the return of workflows. Major clouds have comparable offerings, with some nits making one better than the others. But there is still the need for orchestrating cross-cloud applications.

Three years ago I wrote a post, “The Return of the Workflows,” which described the needs of DevOps at the time: Higher level orchestration and coordination of multistep automation processes. Now we witness a new generation of the workflow tools, and this time the driving force is Serverless.

Does Serverless Need Workflows?

Aren’t serverless architecture event-based? Yes, they commonly are. When it comes to taming infinite data streams with low latency, functional programming, event streaming, and event sourcing are the best tools for the task.

Yet, only a few solutions grow to become truly event sourcing and live up to the compelling promise of “event reply” paradise. More often, the problem is simpler: coordinate a series of calls to a handful of functions and API endpoints in a particular order, pass the data between the calls, and keep the state. Misapplying event-based programming to these kinds of problems makes the solutions hard to reason, hard to debug, and often leads to anti-patterns, like spreading the invocation and data transformation logic across the code of the functions.

Workflows fit here squarely, as they excel at the very three key needs: orchestrate the logic, pass data between the tasks, and keep a clear, transparent operational state.

In Serverless, workflows don’t replace event-based architectures but complement them where they fit. Case in point — the canonical serverless event-sourcing “Hello Retail” by Nordstrom uses a workflow to coordinate the logical sequence and a state of a large part of the solution.

Not surprisingly, all three major clouds have rushed to introduce Workflow-as-a-Service offerings.

Microsoft Azure Came First

Microsoft Azure came first, with LogicApps. Tapping its expertise on workflow management with Workflow Foundation, System Center Orchestrator and Powershell Workflows, Microsoft achieved what was thought impossible before LogicApps, appealing to developers and non-developers alike. It had a graphical workflow editor and was backed by a programmer’s paradise of solid JSON-based workflow definition language, but with powerful functions to send the data between tasks, not to mention 150 ready-to-use connectors to integrate with “everything.”

Amazon Web Services followed up with StepFunctions, sidelining its not-so-simple Simple Workflow Service. The rush to market resulted in inferior operational experience: for example, how would you like losing the history of executions on modifying a workflow? But it’s foundation — Amazon State Language — is solid, simple, and concise, with excellent data referencing functionality and rich error-handling with retries and catches. The simplicity comes with a tradeoff: no support for advanced workflow patterns like branching and joins, only sequence and parallel blocks.

Google joined the gang, at last, dropping its “not invented here” attitude and adopting its open-source AirFlow workflow engine for its Google Cloud Platform offering, Cloud Composer (a name reminiscent of Extreme Workflow Composer, another workflow automation tool based on OpenStack Mistral). AirFlow has long been on the good list of workflow experts with Pythonic domain specific language (DSL) for workflow definition, good architecture around the directed acyclic graph (DAG), extensibility of operations and hooks, and XCom — Google’s nickname for the cross-task-communication facility (barely documented but more than adequate). You can find a good overview of AirFlow concepts here.

There are also few new smaller workflow projects, like Flow from Fn project, or Orquestra from our own StackStorm.

For Serverless — They All Can Get the Job Done

As you see, these workflow engines differ substantially in the workflow primitives they support, in operational convenience, in the kinds of calls they can make, and how easy it is to extend them. They differ in many subtle ways. But they have one thing in common: they are brought to life to wire serverless architectures. And when it comes to serverless: with some dev effort and ingenuity, they all can get the job done. Two nuggets to watch — pricing, and impact on solution architecture.

On pricing, AWS StepFunctions and Azure LogicApps are comparable: they meter the use as state changes/function calls. Some argue that the price per unit is too high — 100x more than FaaS. More worrisome: as Ben Kehole pointed out,  the price, along with usage limits, keeps us puzzled over the intended use of these workflows as a service (WFaaS) offerings. As for Google Cloud Composer, it’s pricing is not invocation-based at all: it meters on IaaS resources required to run an underlying AirFlow. This may disqualify Cloud Composer from wearing the serverless badge: serverless, by one definition, is something that costs nothing to run if nobody is using it.

The impact on the architecture manifests as the solution takes advantage of some workflow features, or works around the lack of it. For instance, LogicApps supports “multiple instance data” workflow pattern with ‘for_each’ keyword, so the arrays of data can be handled at the workflow level. StepFunction doesn’t have support for it, which pushes the responsibility to handle arrays either up to the solution level or down into the Lambda functions.

Let’s face it: despite all the functional differences of the workflow offerings, none of the pros and cons — even their pricing — will be a decisive factor in your choice of a cloud provider. Quite the opposite: you will likely use the WFaaS from the cloud you have already chosen, enjoying the pros and sucking up the cons, as we always do with PaaS. Unless you want to rebel and do it your way, the way that works on any cloud, or even across the clouds.

Multi-Cloud?

Is multi-cloud a reality? Some say it’s already here. But there is a long way from having accounts on different clouds to production cross-cloud solutions taking full advantage of the best cloud services. Serverless functions are a way to glue the services and platforms together, but FaaS alone is not enough.

Sensing the need, Serverless.com launched Event Gateway to facilitate event-sourcing to facilitate cross-cloud serverless solutions. To the extent that such solutions become a reality, I believe there is also a space for a cross-cloud Workflow as a Service, to provide a simple orchestration and state management where needed. If and when it happens, Gartner will call it XCloud WFaaS, and someone might make a name and a few bucks on it. While this space is still vacant, what are the options in the meantime?

1) Pick one WFaaS to orchestrate all clouds. Pinch API holes in your clouds. The decision which one to pick is economical as much as technical. Technically Azure LogicApps may be more powerful, or Workflow Composer is appealing because of its open-source roots. Economically, however, functions are cheap to call within clouds, but AWS API Gateway calls come at a premium; if most of your invocations are inside AWS, you might not like the AWS API Gateway line on your AWS bill. (This is not a workflow vs events problem, it’s a cross-cloud barrier: the prospective users of Event Grid face the same challenge).

2) Orchestrate it yourself. Grab a workflow library and build your own serverless workflow solution. If it sounds like hosting AirFlow yourself, it is not, and I’ll stress again “serverless” and “library” to highlight the difference. A solution would use FaaS itself — take the hint from here and rely on an opensource workflow library that can be embedded in the code, rather than launched as a service. What library to pick? If you still tolerate Java in operations (which is unlikely if you’re reading The New Stack), look at Activiti, ditch the terrible BPEL part, and be sure to use it just like a library. Or look at StackStorm’s Orquesta workflow library and run it as serverless itself (ask me how at the ServerlessConf 2018 in San Francisco, we’ll demo it there).

If your solution turns out well technically, claim that empty space of XCloud WFaaS, and try to make it turn out well economically — we may become your users.

 *This blog was originally posted to TheNewStack.io on July 31, 2018.