TIBCO BPM Enterprise Reference Architecture
TIBCO BPM Enterprise, like most enterprise software, is intended to be used in conjunction with a standard set of software and hardware infrastructure. It is not a software appliance, and therefore, cannot be simply installed on a machine and used in a safe and secure manner. Such an approach is possibly suitable for some development and "proof of concept" purposes. However, using TIBCO BPM Enterprise in this way in a production environment would be extremely problematic. For this reason, a reference architecture is proposed that defines the type of expected deployment for TIBCO BPM Enterprise in a production environment.
This section describes the logical topology of the recommended architecture. This is then mapped onto three actual physical architectures:
It is presumed that TIBCO BPM Enterprise is the primary component in the system supported by the reference architecture. For the purposes of this description it is presumed that the Kubernetes system is only being used to support TIBCO BPM Enterprise. However, typically the Kubernetes system will host multiple enterprise systems, and possibly other components that comprise part of the overall system for which TIBCO BPM Enterprise is the primary component.
The following diagram shows the logical structure of the reference architecture:
Legend
Note that in the illustration, worker or "minion" node connectivity is only shown on the far right-hand Kubernetes node. This connectivity is replicated across all of the Kubernetes worker nodes.
The illustration shows a tiered architecture, where it is expected that users will access the TIBCO BPM Enterprise system via the internet or via a VPN, and that the system will be administered remotely from the data center that is hosting the complete system. Each tier of the system is encapsulated in its own "zone" bounded by two firewalls. As is conventional for such architectures, it is not possible to cross more than one firewall boundary from any system.
Above the outer tier of the system is the application end user (represented by the TIBCO BPM Enterprise web client) and the Kubernetes administrator, this being a separate and distinct persona from the TIBCO BPM Enterprise administrator. Both of these users will not have any physical access to the machines hosting Kubernetes or any other component part of the system. End users will typically also not have logins for these machines. The Kubernetes administrator may have an operating system login to these systems, but will not be able to perform such logins remotely.
The top tier of the diagram contains a conventional web DMZ. This contains the required load balancer for the TIBCO BPM Enterprise system. This will also be a reverse proxy, in order to facilitate the indirection required to access this system via an external system. The reverse proxy will implement sticky session capability required by TIBCO BPM Enterprise. Also located in this tier is the jump system (located on a Bastion server) that is used to administer the Kubernetes system. Typically, access to this server is only possible via a VPN (not shown on the diagram).
The middle tier contains the Kubernetes system. This must consist of at least one master node and one worker node, though typically there will be two or more worker nodes. The diagram shows three worker nodes (this being the default used by some cloud services). Each worker node will house one or more pods, these consisting of a set of containers required for a particular application. In the case of TIBCO BPM Enterprise, the pod will typically consist of the mandatory TIBCO BPM Enterprise container. Other pods may also be present on the worker nodes. They may be required by other applications or for the required capabilities of the installed Kubernetes system.
The bottom tier contains the enterprise infrastructure used by Kubernetes and TIBCO BPM Enterprise. This tier contains the LDAP directory required by TIBCO BPM Enterprise, this most likely being the directory used by the organization running applications in TIBCO BPM Enterprise. This tier also contains the database required by TIBCO BPM Enterprise, the SMTP email server used to send work item notifications and emails from executed email tasks, as well as the container repository used by Kubernetes.
Log files are emitted as standard log files. These are emitted and managed at the pod level by Kubernetes. In a production environment it may be necessary to combine these logs such that a single log file is available on a machine that is not a Kubernetes node, or is available in a log management system.
The replica set is the primary mechanism to be used for HA/FT purposes. The minimum number of replicas should be one per node. Scaling will be performed using standard Kubernetes HPA mechanisms.