Learn About Deploying Oracle Banking Microservices and OKE
Learn how to use Oracle Cloud Infrastructure Container Engine for Kubernetes and Oracle Banking Microservices to modernize your banking infrastructure. Oracle Container Engine for Kubernetes (OKE) is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. Use OKE when your development team wants to reliably build, deploy, and manage cloud-native applications. You specify the compute resources your applications require, and OKE provisions them on Oracle Cloud Infrastructure (OCI) in an existing OCI tenancy.
Architecture
This architecture describes how to implement Oracle Banking Microservices and Oracle Cloud Infrastructure Container Engine for Kubernetes to leverage microservices efficiently.
Oracle Banking Microservices Architecture
Oracle provides the industry’s broadest set of domain-driven banking solutions, covering retail and corporate banking, and complete front to back, from the customer digital experience layer to the banking product processors, or core banking domains.
All these capabilities are provided as a set of autonomous modules, designed using domain-driven design, and implemented using a state-of-the-art microservices architecture. Every module is composed of a set of business domain-specific microservices, a set of common functional foundation microservices (common core) across all modules, and platform services that provide the required technical capabilities.
The following diagram illustrates the different levels of microservices in the branch module.
This architecture offers maximum deployment flexibility. Every microservice can be containerized in a docker image and deployed separately. This option provides complete control over the deployment, allowing you to update or scale up any specific microservice based on particular customer requirements.
Some customers may not require that level of granularity for platform management and may prefer a simplified approach, grouping the microservices in a reduced number of docker images. Even though this approach reduces the flexibility for updating and scaling at an individual level, it still provides the required level of control for customers with standard requirements about scalability, high availability, and so on. In this scenario, it’s important to group the microservices considering their implications and specific nature. In this reference architecture, we propose a grouping that considers these factors:
- Type of workload: REST-based, batch-based, event-based, workflow-based.
- Critical components: Some components are critical for the platform. They have a higher workload than others.
The following diagram illustrates the proposed grouping.
Description of the illustration obma-service-landscape-branch-module-proposed.png
Here’s an explanation of these groupings:
- Domain SD: Contains the business domain microservices of the module, in this case, the branch module.
- CMC SD: Common core or functional foundation microservices.
- Plato SD: Contains the technical platform microservices that have not been deployed separately.
- Kafka: Used by the platform Event Hub for communication between the microservices and external systems.
- Conductor: Workflow engine of the platform used to orchestrate the microservices and create human workflows.
- Batch Server: Executes the batch processes required by the business domain.
This solution groups seven docker images.
Deployment Architecture using OKE
Oracle Container Engine for Kubernetes uses Kubernetes - the open-source system for automating deployment, scaling, and management of containerized applications across clusters of hosts. Kubernetes groups the containers that make up an application into logical units (called pods) for easy management and discovery.
To run containers in Kubernetes, they must be enclosed in a pod. A pod is the smallest atomic unit in Kubernetes and is a construct that runs a grouping of containers that shares the same network, storage, memory and IPC namespace. There is one main container in a pod, and the subsequent containers support the main container. An example would be an application container with a supporting container that sends the application logs to a logging server. We will not get into details about multi-container pod use cases in this architecture, but in most cases, there is only one container per pod.
For deploying our Oracle Banking solution, we will enclose each of the seven container images we are deploying in its own pod. This can be done by defining a Kubernetes pod manifest file for each container image.
Pods can be deployed directly into Kubernetes, but it is more robust to deploy pods with a Kubernetes deployment. A Kubernetes deployment allows you to define a pod's desired state or behavior, such as the number of copies or replicas of a given pod. A Kubernetes deployment can also upgrade an existing pod to a new application version. It is up to Kubernetes to maintain the specified state of a pod.
We will have a total of seven deployments for our Oracle banking solution. Each pod in a deployment is assigned an IP address, but IP addresses for pods are ephemeral, and change as pods are created and destroyed. To provide a consistent way to access pods in a deployment, a Kubernetes service is created for each deployment. A Kubernetes service is an abstraction that defines a set of pods. When a Kubernetes service is associated with a deployment, it will represent all the pods in the deployment, and will load balance traffic to each of the pods. Depending on how the pods need to be accessed, whether it will be accessed only by other resources in the Kubernetes cluster, other resources within your OCI VCN or externally through the internet, different types of Kubernetes services are assigned to the deployment.
To provide resiliency, our OKE node pool will span all three availability zones in our region. In case an availability zone is to fail, all pods that are deployed on nodes in the failed availability zone will automatically be recreated on nodes in another availability zone.
For the Oracle database, that stores the data for the microservices, using separated schemas for each of them, we use a Real Application Cluster (RAC) configuration in two fault domains.
The following diagram illustrates this architecture.
Description of the illustration obma-oke-architecture.png
For the Oracle database that stores the data for the microservices, using separated schemas for each of them, we use a RAC configuration in two availability domains (using two fault domains not shown in the picture). Data is replicated using Oracle Data Guard in the second availability domain.
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.
- 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.
- Bastion host
The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.
- DB systems
For a small deployment, a VM.Standard2.2 shape is sufficient. This architecture uses a DB system with Oracle Database Enterprise Edition - Extreme Performance, using Oracle Real Application Clusters (RAC). It also uses Oracle Automatic Storage Management (Oracle ASM) with a minimum of 256 GB.
- Block volume
With block storage volumes, you can create, attach, connect, and move storage volumes, and change volume performance to meet your storage, performance, and application requirements. After you attach and connect a volume to an instance, you can use the volume like a regular hard drive. You can also disconnect a volume and attach it to another instance without losing data.
- Object storage
Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can seamlessly scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.
- 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.