The purpose of this epic is to gradually transition from a local dev-mode to a prod-mode.

There are several aspects to this, which will influence the required bits:

Deploying a workflow in dev-mode vs prod-mode

• SonataFlow CR can be configured to run on k8s/OCP either in dev-mode or in prod-mode.
  • For dev-mode, all services are packaged inside the base image and run locally. This option fits nicely with the self-service of developers to deploy their workflow into a reserved namespace, without interacting with the production services. In that case, interaction is done directly with the exposed service of the deployed application.
  • For prod-mode, the workflow spec is deployed and configured by the SonataFlow operator, according to the SonataFlowPlatform, SonataFlowBuild, and mainly the configuration of the operator which determines the persistency, backing services, and communication with them. 

In production, The SonataFlow operator is responsible for installing the DataIndex service and the JobService, and their persistence (based on providing the configuration for the PostgreSQL db).

The epic should be responsible for providing a solution for deploying the entire services in production mode. The full-blown list of services to cover by this epic are:

• PostgreSQL
• SonataFlow Operator
  • DataIndex service
  • Job Service
• OpenShift Serverless operator
  • knative serving
  • knative eventing
    • configured for knative kafka-broker
• Kafka broker

To start gradually, and based on the progress of SonataFlow Operator, the first deployment will include the 

• PostgreSQL
• SonataFlow Operator
  • DataIndex service
  • Job Service

Workflows will be deployed as k8s deployments.

References to an architecture evolution based on development progress:

https://lucid.app/lucidchart/c7af8790-7be2-4735-b3d4-10ab9fd36ca5/edit?beaconFlowId=796FA56562C8A430&invitationId=inv_1183a019-aeed-4f4d-94be-b95f83dae266&page=0_0#