Orchestration with Code vs Config

One interesting perspective I often hear about workflows is how approaching them with configuration is better than with code, or the opposite, depending on who you are talking to.

Many established products in the space of workflow orchestration often claim it’s easier to write workflows as code. The biggest argument in favor of this is that complexity is better addressed in code compared to a configuration or DSL. This comes with the assumption that workflows will be where the logic lives.

My personal take is that this anticipated complexity doesn’t really exist. The moment your code leaves the boundary of a single method, you are already orchestrating outside of your code. And you end up building a deeply coupled, hard-to-maintain system when the orchestration leaves your library boundary to another app or service.

Code as Building Blocks

A building-blocks code model, which is interconnected only via orchestration, gives you cleaner, more testable, and maintainable code, and lets you retain a simpler, maintainable architecture. Remember you are still writing code, and just wiring things up using orchestration.

This was (or is) evident in how, some of us, use event-driven choreography. The entire idea is to decouple and run services that are not aware of each other. The events being routed from one place to another don’t have complexity that can be resolved with code.

However, the challenge with choreography is the lack of visibility into how things map. This is where the power of orchestration comes through.

Code vs Configuration

The topic of this debate is mute, as its really your code that is being orchestrated. It would make less sense to orchestrate within code. Instead the code you write should be orchestrated to create the flows that meets your goals, while keeping things cleanly decoupled, unmeshed.

What are your thoughts on this? Is it time to unmesh your workflow complexity from code?