Deploy IBM Sterling Order Management Software in a Container Engine for Kubernetes cluster
IBM Sterling Order Management Software is an omnichannel order fulfillment software. As of software version 10.0, the software is available on IBM certified containers. IBM certified containers are packaged with containerized IBM Sterling Order Management Software and validated for cloud deployment allowing customers to deploy the containers to any public or private cloud including Oracle Cloud Infrastructure (OCI) using Oracle Container Engine for Kubernetes (OKE) clusters.
This reference architecture provides an overview to deploy the IBM Sterling Order Management Software in an OKE cluster. OKE delivers a highly available and scalable production-ready Kubernetes cluster to deploy containerized applications in the cloud. Deploying IBM Sterling Order Management Software in an OKE cluster allows the application to integrate with other OCI managed services easily to further simplify the deployment.
Architecture
IBM Sterling Order Management Software requires a database and a Java Message Service (JMS) server as pre-requisites to deploy the application. In addition, the IBM Sterling Order Management Software certified container must be customized to use the selected database and JMS for deployment.
- IBM Db2 database V11.x or higher OR Oracle database v19c
- IBM MQ JMS server V9.x or higher OR WebLogic JMS
- IBM Sterling Order Management Software certified containers V10
The following diagram illustrates this reference architecture.
oci-oke-ibm-sterling-arch-oracle.zip
In this reference architecture, the OCI Autonomous Database service provides the IBM Sterling Order Management Software application database. Autonomous Database is a fully managed, preconfigured database environment with four available workload types: Autonomous Transaction Processing, Autonomous Data Warehouse, Oracle APEX Application Development, and Autonomous JSON Database. Autonomous Transaction Processing with Oracle database version v19c is used for this deployment.
For the JMS server, IBM MQ messaging server is deployed with the IBM Sterling Order Management Software in an OKE cluster. IBM certified images and helm charts are available for the IBM MQ server deployment. The IBM MQ server must be configured with the queue manager and necessary queues for IBM Sterling Order Management Software.
- File Storage
The application and agent services require persistent NFS shares to store shared data (Search Index, CDT import, or export) used by the application server and agent server containers. The IBM MQ service also requires network-attached storage to store MQ configuration data and messages. The OCI File Storage service is deployed to provide persistent volume to the application, agent, and IBM MQ services.
- Container Registry
The container images for this solution must be stored in a repository that is accessible from the OKE cluster. OCI Container Registry is utilized to store the images. OCI Container Registry can also be used as a Helm repository if customers have their own helm charts. The OKE cluster connects to the OCI Container Registry through a service gateway, so the traffic does not traverse the internet.
- API Gateway
The API Gateway exposes the IBM Sterling Order Management Software endpoint to users. It provides authentication and authorization to users that access the IBM Sterling Order Management Software application.
- Load Balancer
The Load Balancer provides access to the ingress controller in the OKE cluster. The ingress directs traffic to requested services by users of the IBM Sterling Order Management Software application.
- Certificate Authority
The Certificate Authority service manages the TLS certificates for the IBM Sterling Order Management Software public endpoint.
- Key Management
The Key Management service manages the keys used by the Certificate Authority service.
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Container Engine for Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetes is a fully managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. You specify the compute resources that your applications require, and Container Engine for Kubernetes provisions them on Oracle Cloud Infrastructure in an existing tenancy. Container Engine for Kubernetes uses Kubernetes to automate the deployment, scaling, and management of containerized applications across clusters of hosts.
- Autonomous database
Oracle Cloud Infrastructure autonomous databases are fully managed, preconfigured database environments that you can use for transaction processing and data warehousing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.
- Network address translation (NAT) gateway
A NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
Recommendations
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Load balancer bandwidth
While creating the load balancer, you can either select a predefined shape that provides a fixed bandwidth, or specify a custom (flexible) shape where you set a bandwidth range and let the service scale the bandwidth automatically based on traffic patterns. With either approach, you can change the shape at any time after creating the load balancer.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet.
- Autonomous Database version
Use the latest available version for the Autonomous Database.
Considerations
When deploying IBM Sterling Order Management Software in an OKE cluster, consider the following for scalability and availability:
- Application availability
The IBM Sterling Order Management Software application is deployed with multiple pods in the deployment to provide high-availability.
Fault domains provide the best resilience within an availability domain. If you need higher availability, consider using multiple availability domains or multiple regions where feasible.
- Scalability
You can manually scale the number of CPU cores of the database up or down at any time. The autoscaling feature of Autonomous Database allows your database to use up to three times the current base number of CPU cores at any time. As demand increases, autoscaling automatically increases the number of cores in use. Autonomous Database allow you to scale the storage capacity at any time without affecting availability or performance.