Deploy Oracle Cloud Scale Billing on OCI
As communication service providers (CSPs) strive to meet the demands of a growing subscriber base and introduce new 5G services, they are increasingly migrating their business support systems (BSS) to the cloud to improve operational agility.
Oracle Communications Billing and Revenue Management (BRM) application is an industry-leading, cloud-scale, revenue management solution for the communications industry. BRM has been designed to support the business processes at the heart of a CSP’s monetization strategy and can be deployed as a cloud native, containerized application running on Oracle Cloud Infrastructure (OCI) and utilizing Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE).
This architecture describes a high-level conceptual architecture for the deployment of BRM in a single availability domain inside a single OCI region. Actual deployment details will depend on a number of factors that are specific to the service provider’s business requirements and may differ from this reference architecture.
BRM has the functional richness and operational performance to enable innovative, customer-centric businesses to meet high-revenue growth demands for business-to-consumer (B2C) and business-to-business (B2B) service provider offerings. To illustrate BRM’s enterprise-scale billing performance, Oracle Communications Cloud Scale Billing solution (which is powered by BRM) was put to the test. Running on OCI and using OKE, the solution completed a bill run for 10 million accounts across eight representative CSP enterprise customers in 4.5 hours. Oracle achieved a billing throughput of 2.29 million accounts per hour and an invoicing throughput of 5.11 million accounts per hour. For further details, including the test methodology and OCI architecture used, please see the technical brief found in Explore More.
BRM has a multi-service architecture that takes advantage of industry-accepted, cloud native technologies such as: Docker as the container runtime, Kubernetes for container orchestration, and Helm for packaging and deployment. Cloud Scale Billing provides industry-proven, modern billing and revenue management for communications and digital businesses, offering:
- Flexible service and industry business model support
- Faster innovation: rapid launch of digital offers with design-time flexibility
- IT agility: modern cloud native deployment model with low total cost of ownership, designed to be deployed in public and private cloud infrastructure
- Comprehensive billing operations to ensure an accurate and consistent billing experience to help minimize customer billing complaints
- Billing for complex hierarchical structures, including: flexible group account plans, roll-up rules, recurring, usage, purchase charges, bill time discounts, payments, collections, adjustments, and dispute management
Architecture
This architecture is used for end-to-end revenue management for communications service providers and communications related enterprises.
Revenue management is the end-to-end process for generating, capturing, and collecting revenue for each service and customer. Oracle Communications Cloud Scale Billing has been designed to support the efficient scheduling and execution of high-performance billing and invoicing tasks, running on cloud native infrastructure. Billing and invoicing are multi-threaded applications designed to optimally utilize the available compute resources to ensure large scale jobs are completed in the least time possible.
The billing operation is decomposed into multiple parallel smaller processes enabling efficient scalability and is well-aligned with dynamic Kubernetes autoscaling. Increasing the number of hierarchies or subordinate accounts in a hierarchy yields predictable throughput and scalability characteristics.
In addition to a high-performance, cloud native architecture, powerful operational capabilities are available to configure, schedule, and view billing, invoicing, and other key revenue management functions.
BRM’s extensive suite of APIs (including web services, REST, and TM Forum–aligned Open APIs) allow service providers the flexibility and control of integrating BRM with external enterprise business applications without giving direct access to the database, reducing the risk to data security and lowering operational management overhead.
The containerized BRM application allows service providers the flexibility to deploy the application in OCI public cloud, on-premises (bare metal or virtual machine), or an OCI-dedicated region at the customer.
oci-brm-functional-diagram-oracle.zip
In this conceptual reference architecture, the BRM is deployed using an OKE cluster in OCI. It is recommended to configure BRM application worker nodes in different fault domains (FDs) within an availability domain (AD). Cloud native business logic pods can be configured to horizontally autoscale (up and down) based on CPU utilization, enabling optimization of compute resources during the running of billing jobs.
The diagram shows an Oracle RAC cluster in a dedicated private subnet. The Oracle database is accessible through the Kubernetes network so that the BRM cloud native pods can perform database operations. The Oracle database you use can be deployed on bare metal, virtual machines, or Oracle Managed Database as a Service (DBaaS) on OCI. For the latest supported database versions, please see the “BRM Software Compatibility” section in the product documentation. The database can be replicated to a standby database using Active Data Guard.
A bastion host is configured in a public subnet to allow access to the BRM worker nodes from the customer’s network (for example via SSH). The BRM web clients and external integrations connect to the load balancer through the Internet gateway. Additional security rule enforcement can be provided by Oracle Cloud Infrastructure Web Application Firewall (WAF) for Internet traffic.
You use an ingress controller behind an external load balance to expose BRM services outside of the Kubernetes cluster and allow clients to communicate with BRM. The ingress controller monitors the ingress objects and acts on the configuration embedded in these objects to expose BRM HTTP and T3 services to the external network. The load balancer provides a highly reliable, single-point access into the services exposed by the Kubernetes cluster. In this case, the services are exposed by the ingress controller on behalf of the BRM cloud native instance.
The following diagram illustrates this reference architecture.
oci-brm-architecture-topology-diagram-oracle.zip
The architecture has the following components:
- Tenancy
A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.
- 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).
- Compartment
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.
- Availability domain
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 domain
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 subnet
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.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.
- 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.
- 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.
- Service gateway
The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
- Cloud Guard
You can use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
- Security zone
Security zones ensure Oracle's security best practices from the start by enforcing policies such as encrypting data and preventing public access to networks for an entire compartment. A security zone is associated with a compartment of the same name and includes security zone policies or a "recipe" that applies to the compartment and its sub-compartments. You can't add or move a standard compartment to a security zone compartment.
- FastConnect
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
- Exadata DB system
Oracle Exadata Database Service is an option that enables you to leverage the power of Exadata in the cloud, should your business needs require this. You can provision flexible X8M systems that allow you to add database compute servers and storage servers to your system as your needs grow. X8M systems offer RoCE (RDMA over Converged Ethernet) networking for high bandwidth and low latency, persistent memory (PMEM) modules, and intelligent Exadata software.
Considerations
Consider these points when deploying cloud native BRM in OCI.
- Autoscaling
You can use the Kubernetes HorizontalPodAutoscaler (HPA) to automatically scale up or scale down the number of BRM pod replicas in your deployment based on a pod's CPU or memory utilization. See the Oracle Communications Billing and Revenue Management Cloud Native Deployment Guide in Explore More for more information.
- Performance
BRM deployment architectures and system sizing will vary from customer to customer and will depend on many factors, including, but not limited to, subscriber base, expected usage volumes, billing and invoicing models, account hierarchy complexity, and data retention requirements, which should be discussed with Oracle or your implementation partner prior to and during the deployment project design phase.
- Availability and resiliency
For an additional degree of availability, BRM can be deployed across availability domains and regions. In such models, data replication across RAC instances can be provided using Active Data Guard.
- Converged charging
If you need to support high volume, low latency core network charging for 4G and 5G services, you should consider deploying Oracle Communications Cloud Scale Charging, powered by the Oracle Communications Elastic Charging Engine, alongside BRM (not included in this reference architecture). In a performance test running on OCI using OKE, the charging engine achieved single-digit millisecond latency in a multi-site performance test scaled to support 100 million concurrently active subscribers. Achieving 270,000 transactions per second, the test showed that Oracle’s cloud native solutions can meet even the most strenuous charging requirements of the world’s largest CSPs. See Explore More for more details on Oracle Communications Cloud Scale Charging.
Explore More
Learn more about billing and revenue management.
Review these additional resources:
- Best practices framework for Oracle Cloud Infrastructure
- Oracle Cloud Scale Billing
- Oracle Communications Billing and Revenue Management Cloud Native Deployment Guide
- Oracle Cloud Scale Billing Performance Test
- Cloud Native System Administrator's Guide
- Oracle Scales Up Billing for 10 Million Enterprise Accounts
- Cloud Scale Charging – A Cloud Native Converged Charging System (CCS)