Much less code
Shifting REST calls into the workflow definition as a declaration (with simple authentication) enabled us to eradicate fairly a little bit of code in our providers; one service was trimmed down right into a easy information transformation perform, and one other service fully disappeared! Two features for triggering two paths within the workflow had been wanted although, however with a future integration with Eventarc, they will not be required anymore.
Much less setup
Within the unique event-driven structure, we needed to create Pub/Sub subjects, and arrange Cloud Scheduler and Eventarc to wire-up providers. With Workflows, all of this setup is gone. Workflows.yaml is the one supply of setup wanted for the enterprise move.
Error dealing with
Error dealing with was additionally simplified in a few methods. First, the entire move stops when an error happens, so we had been now not in the dead of night about precisely which providers succeeded and which failed in our chain of calls. Second, we now have the choice of making use of international error and retry insurance policies.
Studying curve
Now, all the pieces will not be at all times excellent! We needed to study a brand new service, with its quirks and restricted documentation — it’s nonetheless early, in fact, and the documentation will enhance over time with suggestions from our prospects.
Code vs. YAML
As we had been redesigning the structure, an fascinating query got here up again and again: “Ought to we do that in code in a service or ought to we let Workflows make this name from the YAML definition?”
In Workflows, extra of the logic lands within the workflow definition file in YAML, relatively than code in a service. Code is normally simpler to jot down, check, and debug than YAML, however it additionally requires extra setup and upkeep than a step definition in Workflows.
If it’s boilerplate code that merely makes a name to some API, that ought to be become YAML declarations. Nonetheless, if the code additionally has further logic, then it’s most likely higher to depart it in code, as YAML is much less testable. Though there may be some stage of error reporting within the Workflows UI, it’s not a full-fledged IDE that helps you alongside the best way. Even when working in your IDE in your improvement machine, you’ll have restricted assist from the IDE, because it solely checks for legitimate YAML syntax.
Lack of flexibility
The final side we’d like to say is maybe a lack of flexibility. Working with a loosely-coupled set of microservices that talk through occasions is pretty extensible, in comparison with a extra inflexible resolution that mandates a strict definition of the enterprise course of descriptions.
Choreography or orchestration?
Each approaches are completely legitimate, and every has its professionals and cons. We talked about this subject when introducing Workflows. When must you select one method over the opposite? Choreography could be a higher match if providers will not be carefully associated, or if they’ll exist in several bounded contexts. Whereas orchestration is likely to be greatest in case you can describe the enterprise logic of your utility as a transparent move chart, which might then immediately be described in a workflow definition.
Subsequent steps
To go additional, we invite you to have a more in-depth take a look at Workflows, and its supported options, by trying on the documentation, notably the reference documentation and the examples. We even have a sequence of brief articles that cowl Workflows, with varied ideas and methods, in addition to introductions to Workflows, with a primary take a look at Workflows and a few ideas on choreography vs orchestration.
If you wish to research a concrete use case, with an event-based structure and an equal orchestrated method, be at liberty to look into our Serverless Workshop. It presents codelabs spanning Cloud Features, Cloud Run, App Engine, Eventarc, and Workflows. Particularly, lab 6 is the one during which we transformed the event-based mannequin into an orchestration with Workflows. All of the code can be obtainable as open supply on GitHub.
We sit up for listening to from you about your workflow experiments and desires. Be happy to achieve out to us on Twitter at @glaforge and @meteatamel.
