Decision Management (ODM, ADS)

 View Only

CP4BA ODM topologies on OPENSHIFT with dedicated Common Services

By Pierre-Andre Paumelle posted Thu January 11, 2024 08:26 AM

  

Please find a PDF version of this article available here

Introduction

Operational Decision Manager (ODM) empowers business users and developers to collaborate when they automate an organization’s business policies. ODM automates the decision-making process and governs future policy updates. Execution of the business rules (decision services at runtime) can scale out in clusters of servers running on bare metal, virtual machines, or containers. In this article we will focus on OpenShift with dedicated Common Services.
These topologies were tested on CP4BA 23.0.1 and 23.0.2

Components and Environments

The main components of ODM in a topology are: 

  •        Decision Server console to manage the runtimes
  •         Decision Server runtime to execute the decisions services
  •         Decision Center to author the decisions services
  •         Decision Runner (non production) to execute tests and simulations on decisions

Environments description

Authoring environment

  •        The goal of this environment is to manage the authoring and test of rules.
  •         This environment is composed of multiple Decision Center pods, a single Decision Server console and some Decision Runner pods.
  •         The Decision Center is the tool to govern, author and deploy a Decision Service.
  •         The Decision Runner is the tool to execute the tests and simulations of a Decision Service using Decision Center.
  •         The Decision Server console manages the deployments of the decision services ready to be tested. It cannot be scaled up over 1 pod.

Sandbox environment

  •         The goal of this environment is to deliver a sandbox to test and execute the Decision Services for a developer or a development team.
  •         In this environment a developer could test the Decision Service as Web Service (SOAP or a RESTful API). This environment is dedicated to unit test of the services.
  •         This environment is composed of a single Decision Server console and a single Decision Server runtime.
  •         The Decision Server console manages the deployments of the decision services ready to be tested.
  •         The Decision Server runtime publishes RESTful API to execute the decision services.
  •         Sandbox environment could have different names depending on the organization like QA/Test/Qualifying environment.

Pre-Prod environment

  •         The goal of this environment is to mimic the Production environment, to be able to run performance tests of the Decision Services before a deployment on Production.
  •         In this environment a developer could test the Decision Services as Web Service (SOAP or a RESTful API). This environment is dedicated to Performance tests and long running tests. These tests could be executed on multiple rulesets to verify the interactions between rulesets in terms of performance and resources consumption.
  •         This environment is composed of a single Decision Server console and several Decision Server runtimes.
  •         The Decision Server console manages the deployments of the decision services ready to be tested.
  •         The Decision Server runtime publishes RESTful API to execute the decision services.
  •         Pre-prod environment could have different names depending on the organization like Staging environment.

Production environment

  •         The goal of this environment is to manage the execution for the production.
  •         This environment is deployed on a separated cluster.
  •         This environment is dedicated to Production to serve the company business.
  •         This environment is composed of a single Decision Server console and several Decision Server Runtime.
  •         The Decision Server console manages the deployments of the decision services ready to be used in production.
  •         The Decision Server runtime publishes RESTful API to execute the decision services.
  •         As this environment is on a separate cluster, the best option is to deploy on Production through a CI/CD. Please note that an upcoming article about promoting Decision Services using a CI/CD will be released soon.

ODM topology types

We have three topologies. The names bronze, silver, and gold come about because performance studies show that the scalability depends on the topology. Gold demonstrates better performance than silver, and silver demonstrates better performance than bronze.

  •        Bronze topology
    •        For prototypes or applications with low production constraints
  •        Silver topology
    •        For applications with medium production constraints 
  •        Gold topology 
    •        For applications with high production constraints

Bronze Topology

Bronze topology is the default installation.

All the components are installed in a single namespace with  dedicated ZEN and Common.Services;

Boxes represent pods. Decision Center is scaled up to two pods for HA.

Advantages of the Bronze topology

    •        Easy to install (Default installation)
    •        Tshirt sizing available   
    •        HA is supported – multi zone could help
    •        External database

Disadvantages of the Bronze topology

    •        No separation of Dev and production
    •        Tests of Migration or update should be done on another cluster
    •        DR is not supported
    •        No Pre-Prod tests
    •        Only Decision Runner tests are possible

Bronze topology is for prototypes or applications with low production constraints

 

Silver topology

Silver topology makes use of several namespaces in a single cluster.

Silver topology is multi- namespace, which uses separate routes per namespace.

Minimum Silver topology without Pre-Prod


Full silver configuration with Pre-prod and 2 sandboxes


Advantages of the Silver topology

    •        HA is supported – multi zone could help
    •        Pre-Prod test available
    •        One Decision Center to govern all Decision Servers
    •        Sand Box for developers available
    •        External database

Warnings of the Silver Topology

    •        All Environments are using the same IAM for Authentication
    •        Minimum of two namespaces to install (Role and certificate should be tuned)
    •        Separation of Dev and production is better than the Bronze Topology
      •        But Tests could impact Production performance
    •        Complex to install
      •        Role and certificate should be tuned



Disadvantages of the Silver Topology

    •        Tests of Migration or update should be done on another cluster
    •        DR is not supported (need another cluster)

The Silver topology is for applications with medium production constraints

 

Gold topology

Multi cluster to get a production authoring separation

The authentication is separated

The resources for production are dedicated (cpu/disk/memory/network)

Pre-Prod and sandboxes could be separated

Minimum gold topology No Pre-Prod and a single sandbox


Gold Topology with two sandboxes and a pre-prod


Gold topology with specialized productions.

You have 2 Production namespace to make sure that  rulesets are not impacted by others. So, the SLA of these rulesets are guaranteed.


Warnings of the Gold topology

    •        Complex to install
      •        Role and certificate should be tuned

Advantages of the Gold topology

    •        Complete separation of Dev and production
      •        Resources (CPU/Memory/Disks/databases)
      •        Authentication coming from separate IAM
    •        Migration test could be done step by steps
    •        HA is supported – multi zone could help
    •        DR could be supported by adding clusters in multi-geo ( several Datacenters)
    •        Pre-Prod test available
    •        Decision Runner tests are possible
    •        Sand Box for developers available
    •        External database

Gold topology is for application with high production constraints

The properties of the ODM Gold topology are the following: 

  •        Having a production environment separated from Authoring and other test environments. It can have its dedicated network & Identity Access Management (IAM) for authentication, so security & performances on production can’t be affected by the Authoring/test environments. 
  •        Having a scalable and multi-region Production (multiple clusters across the globe). 
  •        Dedicating a single Decision Center (with at least 2 replicas for HA) as the source of truth. 
  •        Locating Decision Center within an Authoring cluster. As such, it is easier to conduct tests during authoring and development phases.  
  •        Providing sandboxes to your developers to run tests in an isolated way. 
    •          Sandbox environment could use internal database for cheaper cost and easier to deploy. However, it is not secured. 
    •          Sandbox environment could also use external databases with populated data (for example, to reproduce an issue) and be more secure.
    •          Sandboxes are used for Quality Assurance & Development of your Decision Services. 

  •        Leveraging an external database allows you to manipulate data (such as making copies, backup). And, it also provides HA support. 
  •        Ideally, having a Pre-production environment identical to Production environment for: 
    •           Benchmarking purpose,
    •           Verifying scalability,
    •           Trying first in Pre-production environment. If the result is satisfactory, the exact same RuleApp can be deployed to production Decision Server Runtime without breaking your Production environment. 

  •        Optimizing costs (do not need to deploy everything everywhere). 
  •        If you have multiple lines of business (LOB), deploying multiple Authoring environments. 
  •        If possible, using CI/CD for RuleApps promotion. 
  •        Considering performance and security aspects:
    •          You could add one or more basic auth users on production Decision Server Runtime for best performance.
    •          Use external IAMs (LDAP/Azure AD/....) to manage users and groups on ODM DC and Pre-production/Production RES) 

 

ODM Topology options

The best topology for you depends on your needs and choices.

To choose the option best suited for your needs answer the following questions:

    •        Do you need a separation per domain or Business unit? 
      •        For Authoring?
      •        For Production?
    •        Do you need multi-geo for Disaster Recovery or performance? 
    •        Multi-geo for Authoring is on an Active/passive mode only
    •         Do you need a specific access management per domain or Business unit?
    • Ruleset Deployment mode
      •        With Decision Center
      •        With CI/CD
      •        With CI/CD the artifacts can be stored in repository and redeployed with the exact same version.

Installation guides

All these topologies were tested and we are writing installation guides based on these tests.

Bronze topology Installation

Silver topology installation

Validation of a topology

#OperationalDecisionManager(ODM)
#topology#CloudPakforBusinessAutomation

0 comments
36 views

Permalink