This section presents the recommended container architecture for WorkflowGen in order to run the web portals and Windows services. There will be many references to the image configuration properties; see the Configuration section for information on these.
This section is only about container architecture. SQL data and volumes should always be used regardless of the architecture.
This is the simplest architecture you can run with WorkflowGen: a single container without replicas that runs both web applications and Windows Services. Therefore, you would set the WFGEN_START_SERVICE environment variable to all. This architecture is well suited to development and test environments, but it can also be considered when the performance with a single container fits the product usage. You can't replicate the container because there should only be one instance of each WorkflowGen Windows Service running.
Docker Compose example
This is the same example as in the Getting Started section. It has one WorkflowGen container that runs every service (web applications and Windows Services).
This example is different from the Getting Started example. This Helm release is not scalable in the cluster. It has a pod that runs all of the WorkflowGen services (web applications and Windows services) and another pod for the database. You can use the steps in the Getting Started example to generate the requested values. Don't forget to get the external IP address of the load balancer once it's created.
Multiple web application instances, single Windows Services instance
Since there can be only one instance of each WorkflowGen Windows Service running at a time, this architecture lets you run multiple replicas of the web applications in order to scale WorkflowGen to meet your traffic and processing needs without having more instances of the Windows Services.
You'll need to set the WFGEN_START_SERVICE environment variable to web_apps for the web applications' containers, and to win_services for the single container to run all of the Windows Services without web applications. This architecture is good for scaling the web portals to the traffic and processing needs, without too much pressure on the Windows Services.
This is the same example as in the Getting Started section. The Windows Services containers will always be in the same pod when you use the WorkflowGen Helm chart. You can use the steps in the Getting Started example to generate the requested values. Don't forget to get the external IP address of the load balancer once it's created.
Multiple web application instances, dedicated Windows services containers
This recommended architecture is the most scalable. It has multiple containers for the web applications that can be scaled for increased traffic or processing needs, and has dedicated containers for each Windows Service: one for the directory synchronization service and one for the engine service. Therefore, you would set the WFGEN_START_SERVICE environment variable to web_apps for the web applications' containers, to dir_sync for the directory synchronization service container, and to engine for the engine service container. This architecture is good for high availability and high performance scenarios.
This is the same example as in the Getting Started section. The Windows services containers will always be in the same pod when you use the WorkflowGen Helm chart. You can use the steps in the Getting Started example to generate the requested values. Don't forget to get the external IP address of the load balancer once it's created.
