Better service orchestration with Workflows

Going from a single monolithic application to a set of small, independent microservices has clear benefits. Microservices enable reusability, make it easier to change and scale apps on demand. At the same time, they introduce new challenges. No longer is there a single monolith with all the business logic neatly contained and services communicating with simple method calls. In the microservices world, communication has to go over the wire with REST or some kind of eventing mechanism and you need to find a way to get independent microservices to work toward a common goal.

Orchestration vs Choreography

Should there be a central orchestrator controlling all interactions between services or should each service work independently and only interact through events? This is the central question in Orchestration vs Choreography debate. 

In Orchestration, a central service defines and controls the flow of communication between services. With centralization, it becomes easier to change and monitor the flow and apply consistent timeout and error policies. 

In Choreography, each service registers for and emits events as they need. There’s usually a central event broker to pass messages around, but it does not define or direct the flow of communication. This allows services that are truly independent at the expense of less traceable and manageable flow and policies. 

Google Cloud provides services supporting both Orchestration and Choreography approaches. Pub/Sub and Eventarc are both suited for choreography of event-driven services, whereas Workflows is suited for centrally orchestrated services. 

Workflows: Orchestrator and more

Workflows is a service to orchestrate not only Google Cloud services, such as Cloud Functions and Cloud Run, but also external services. 

As you might expect from an orchestrator, Workflows allows you to define the flow of your business logic in a YAML based workflow definition language and provides a Workflows Execution API and Workflows UI to trigger those flows.

It is more than a mere orchestrator with these built-in and configurable features:

• Flexible retry and error handling between steps for reliable execution of steps.
• JSON parsing and variable passing between steps to avoid glue-code. 
• Expression formulas for decisions allow conditional step executions. 
• Subworkflows for modular and reusable Workflows.
• Support for external services allows orchestration of services beyond Google Cloud.
• Authentication support for Google Cloud and external services for secure step executions. 
• Connectors to Google Cloud services such as Pub/Sub, Firestore, Tasks, Secret Manager for easier integration (in private preview soon). 

Not to mention, Workflows is a fully-managed serverless product. No servers to configure or scale and you only pay for what you use. 

Use cases

Workflows lends itself well to a wide range of use cases. 

For example, in an e-commerce application, you might have a chain of services that need to be executed in a certain order. If any of the steps fail, you want to retry or fail the whole chain. Workflow with its built-in error/retry handling is perfect for this use case:

In another application, you might need to execute different chains depending on a condition with Workflow’s conditional step execution:

In long-running batch data processing kind of applications, you usually need to execute many small steps that depend on each other and you want the whole process to complete as a whole. Workflows is well suited because it:

• Supports long-running workflows.
• Supports a variety of Google Cloud compute options such as Compute Engine or GKE for long-running and Cloud Run or Cloud Functions for short-lived data processing.
• Is resilient to system failures. Even if there's a disruption to the execution of the workflow, it will resume at the last check-pointed state.

In orchestration vs choreography debate, there is no right answer. If you’re implementing a well-defined process with a bounded context, something you can picture with a flow diagram, orchestration is often the right solution. If you’re creating a distributed architecture across different domains, choreography can help those systems to work together. You can also have a hybrid approach where orchestrated workflows talk to each other via events. 

I’m definitely excited about using Workflows in my apps and it’ll be interesting to see how people use Workflows with services on Google Cloud and beyond. 

For more information, check out Workflows documentation and feel free to reach out to me on Twitter @meteatamel for questions/feedback!