Last update: January 2024
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 Certified Kubernetes (CNCF).
These topologies were tested with ODM 8.11 and 8.12. The installation documentation is available here.
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.
Boxes represent pods. Decision Center is scaled up to two pods for HA.
Advantages of the Bronze topology
- Easy to install
- 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
A 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 IDP 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
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 from separate IDP
- 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 Datacenter)
- 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 secured.
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 a 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.
ODM Bronze topology on Certified Kubernetes
How do I install ODM 8.11.0.1 Silver topology on Certified Kubernetes?
#CloudPakforBusinessAutomation
#containers
#OperationalDecisionManager(ODM)
#topology