Unclear when Orchestrator Plugin should use single-container Sonata Flow vs. entire Sonata Flow K8s Operator / Knative / OpenShift ecosystem

[BillKlineVT]

What do you want to improve?

Need clarification on when to use "dev mode" deployment of a single-container SonataFlow vs. the Orchestrator Helm chart/operator to support the Orchestrator plugin. Are there certain features/use cases that are only supported by the more heavyweight operator?

What does the current documentation state?

The Orchestrator plugin is configured by default ("dev mode") to create a single docker container as the backstage-internal-sonataflow service to support Backstage calls for Orchestrator workflows.

When considering a production use of the Orchestrator plugin, the documentation steers one to much more complex deployment of OpenShift, and the Orchestrator Helm chart which deploys RHDH (Red Hat Developer Hub) Backstage, OpenShift Serverless Logic Operator (with Data-Index and Job Service), OpenShift Serverless Operator (Knative Eventing and Knative Serving).

What would you like to be added/updated in the documentation?

Examples of when a single-container SonataFlow should be used vs. when the full SonataFlow Orchestrator operator should be used

[batzionb]

@masayag

[masayag]

@BillKlineVT Could you please review the content at this blog post to see if it contains the information you need?

[BillKlineVT]

The blog post looks great! Thank you for taking the time to lay out the differences!