Tune and optimize resources with standalone runtime PODs with BAW which are not used exclusively for business purpose rather internal functional usage of various services

Summary:

We understand following core components i.e. runtime pods required for standalone BAW installation.

https://www.ibm.com/docs/en/baw/20.x?topic=cibaw-containers-in-v2103-installing-configuring-migrating-business-automation-workflow

The stand-alone Business Automation Workflow configuration includes these components:

Workflow Server (JMS included)

IBM Process Federation Server

Elasticsearch

Application Engine

User Management Service (UMS)

Business Automation Navigator (BAN)

Content Platform Engine (Content Platform Engine)

Content Management Interoperability Services (CMIS)

Content Services GraphQL

For our use case, we wish to use BAW with case capability for which following components i.e. services not required for our use cases.

Workflow Server JMS

Application Engine

Content Services GraphQL

Elasticsearch

We wish to know if these pods can be disabled OR get excluded from standalone installation of BAW on containers CNCF with AWS EKS. If not, what are the possible ways to optimize resources for those services which are not in use like reducing CPU and RAM limits in CRD.

Post discussion with PMR TS010621916:

We requested sharing documentation reference, tech note etc. to understand more on how the standalone pods internally use various services with interdependence. e.g. Workflow Server JMS is used for internal communication between pods while Elastic Search is used for the task indexer used by Process Portal/PFS. Additionally, I believe the Content Services GraphQL is used for certain functionality in the CPE. I also understand App Engine accesses AE DB through GraphQL also. ** Understanding from your feedback is that all listed pods are must to install standalone BAW due to service interdependence.

IBM Support response:

We don't have a specific tech note to note where all of the standalone pods are used internally, that can change between versions and you should generally assume that if we include the pod with the installation, it is required for a functionality reason. We would not include pods in a deployment that are not used for standard functionality (as that would cause performance concerns as you know).

Requested Idea:

With above understanding, we feel that there is more detailed documetation required to understand inner workings of different components, depedencies, communication etc. to avoid confusion arising from product documetation.