1 Overview of the BRM Cloud Native Deployment
Learn about configuring Oracle Communications Billing and Revenue Management (BRM) to run as a cloud native application in a containerized and orchestrated deployment architecture.
Topics in this document:
Note:
This guide provides information for BRM cloud native 12.0 Patch Set 8 only. If you are installing a previous patch set, follow the instructions in the appropriate patch set version of the BRM cloud native documentation. You can download PDF files of the BRM 12.0 Patch Set 7, Patch Set 6, Patch Set 5, Patch Set 4, Patch Set 3, and Patch Set 2 cloud native documentation from the "Cloud Native Installation and Administration Guide for Older Patch Sets (Doc ID 2846971.1)" knowledge article on My Oracle Support.
About the BRM Cloud Native Deployment
Oracle Communications Billing and Revenue Management (BRM), along with the following BRM applications, are available in a cloud native deployment option, supporting a Kubernetes-orchestrated containerized multi-service architecture to facilitate continuous integration, continuous delivery, and DevOps practices. This allows you to harness the benefits of cloud with the services of BRM.
-
Oracle Communications Pricing Design Center (PDC)
-
Oracle Communications Elastic Charging Engine (ECE)
-
Oracle Communications Pipeline Configuration Center (PCC)
-
Oracle Communications Billing Care
-
Oracle Communications Business Operations Center
Note:
You can also deploy Oracle Communications Offline Mediation Controller on a cloud native environment. See "Overview of the Offline Mediation Controller Cloud Native Deployment" in Offline Mediation Controller Cloud Native Installation and Administration Guide for more information.
You can set up your own BRM cloud native environment or build your own images of BRM and its applications. You use the cloud native deployment package to automate the deployment of BRM products and speed up the process to get services up and running, with product deployments preconfigured to communicate with each other through Helm charts.
BRM Cloud Native Deployment Architecture
In the BRM cloud native architecture, each BRM service runs as a Docker container and is deployed as a Kubernetes pod, which is the fundamental building block of Kubernetes. Many of the core BRM services can be deployed and managed as multiple replicas within a Kubernetes replica set.
Figure 1-1 shows the pods and other components in a typical BRM cloud native deployment.
Note:
Not all pods are shown for clarity. Pod names are descriptive and may differ from actual names in some cases.
Figure 1-1 BRM Cloud Native Deployment Architecture
In this figure:
-
Pricing Design Center, Billing Care, Business Operations Center, and Pipeline Configuration Center are client applications. They connect to the CM, which represents the business logic layer of BRM, by using the Portal Communications Protocol (PCP).
-
The CM communicates with other pods, which represent the data management layer of BRM, by using the PCP protocol.
-
All PCP protocol communication is encrypted using TLS.
-
The data managers (DMs) interact with other downstream products that run the business logic.
The downstream products can be containers or an on-premise system.
-
ECE rates events and applies charges.
-
Rating files for the batch pipeline are fed in through a Kubernetes PersistentVolumeClaim (PVC). The batch pipeline output is also available in a PVC for consumption by the Rated Event (RE) Loader pod.
Note:
To improve security, BRM services are not exposed outside of the cluster. Only PDC, PCC, Web Services Manager, Billing Care, and Business Operations Center are exposed.
Images and Containers
BRM has a multi-service architecture with each service provided as a Docker image for deploying as a run-time container in a Kubernetes cluster on cloud infrastructure. A Docker image consists of read-only layers, each of which represents a Dockerfile instruction. The layers are stacked and each one is a delta of the changes from the previous layer. BRM cloud native deployment images are built by stacking multiple layers, extending an operating system image with a dependent library image, and then with an image packaging the application.
Images and Containers with Non-WebLogic Server Pattern
BRM cloud native images that do not use WebLogic Server, such as the BRM base image, use the layering pattern shown in Figure 1-2.
If you want to build your own BRM images, you must layer the images in this pattern.
Figure 1-2 Base Image Layering with Non-WebLogic Server Pattern
Note:
The Oracle PDC BRM integration image and PDC IE image have an additional dependency on BRM applications. It references the brm-apps and realtime-pipeline images for copying BRM applications and the LoadIfwConfig utility from Pipeline Manager.
Images and Containers for Applications Using WebLogic
Some applications that use WebLogic have images that are based on the WebLogic image, and some applications use an external WebLogic image.
The following images are based on the WebLogic image:
- PDC application image
- Web Services Manager image
- Pipeline Configuration Center (PCC)
Figure 1-3 shows the layering pattern for a PDC application image, but a similar image stack also applies to the Web Services Manager image and Pipeline Configuration Center (PCC) images.
If you want to build your own PDC application, PCC, or Web Services Manager images, you must layer the images in this pattern.
Figure 1-3 Images Based on a WebLogic Image
In this figure:
-
Fusion Middleware Infrastructure 12.2.1.x is the base image. This image is available from the Oracle Container Registry (https://container-registry.oracle.com).
-
The Fusion Middleware Infrastructure image is based on Oracle Linux and Oracle JDK 8 (Server JRE). It's regularly patched with critical security fixes until the release date.
-
The PDC application image extends the Fusion Middleware Infrastructure image, which provides WebLogic Server and JRF for OPSS for authorized access to the application.
Figure 1-4 shows the layering pattern for a Billing Care image, but a similar image stack also applies to the Billing Care REST API and Business Operations Center images.
If you want to build your own Billing Care, Billing Care REST API, or Business Operations Center images, you must layer the images in this pattern.
Figure 1-4 Images Using an External WebLogic Image
In this figure:
-
Oracle Linux 8 is the base image. This image is available from the Oracle Container Registry (https://container-registry.oracle.com). The Oracle Linux image is regularly patched with critical security fixes until the release date.
-
The Billing Care image extends the Oracle Linux image. It references an external image (not part of the stack) for WebLogic functions, like WebLogic Server and JRF for OPSS for authorized access to the application.