Deploy Microservices with a Converged Database and Helidon
Architecture
This architecture shows the resources and topology required to use microservices with Cloud Infrastructure, a converged Oracle Database, and Helidon.
A converged Oracle Database is an optimized database that has native support for modern data types, key data center components, and the latest development paradigms. For example, a converged database supports Spatial data for location awareness, JSON for document stores, IoT for device integration, in-memory technologies for real-time analytics, and traditional relational data. By providing support for all of these data types, a converged database can run all sorts of workloads from IoT to Blockchain to Analytics and Machine Learning. It can also handle any development paradigm, including microservices.
The microservices architecture has three major tiers – the messaging tier, the application tier, and the database tier - to bring agility, horizontal scale, and robustness to enterprise applications. This reference architecture lays out standards-based components available on the Oracle Gen 2 cloud to build robust microservices using Oracle Database as the persistence layer.
The Messaging tier is a either a Java Message Service (JMS) transactional messaging built-in to the database, Transactional Event Queues (TEQ), or Kafka-based transport mechanism such as Oracle Cloud Infrastructure Streaming service.
- Event monitoring and alerting: Grafana and Prometheus
- Observability and Tracing: Kiali and Jaeger
- Traditional Applications: Java Enterprise Edition and Oracle Weblogic
- Java Microservices: Java, helidon.io, and Oracle GraalVM Enterprise
- Polyglot Microservices: node.js and python
- Service Mesh with Oracle Container Engine for Kubernetes: Istio, Kubernetes, and Docker
The database tier consists of two Autonomous Transaction Processing instances (ATP-1 and ATP-2). The architecture uses relational data, spatial data, document, text, and JSON data in the converged database and built-in transactional messaging in the database for microservices to simplify workflows.
The following diagram is an example of a microservices architecture for an online mobile food delivery application.
Description of the illustration helidon_microservices_db_architecture.png
The architecture has the following components:
- 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.
- 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.
- Service Connector for
Kubernetes
Connect the Oracle Autonomous Transaction Processing database to the Oracle Container Engine for Kubernetes with the OCI Service Broker for Kubernetes.
OCI Service Broker for Kubernetes is an implementation of the Open Service Broker API. OCI Service Broker for Kubernetes is specifically for interacting with Oracle Cloud Infrastructure services from Kubernetes clusters. It includes three service broker adapters to bind to the following Oracle Cloud Infrastructure services: Object Storage, Autonomous Transaction Processing, Autonomous Data Warehouse, and Oracle Streaming Service.
You can add OCI Service Broker for Kubernetes to clusters you've created with Oracle Cloud Infrastructure Container Engine for Kubernetes to interact with the Oracle Cloud Infrastructure services listed above. When you add OCI Service Broker for Kubernetes to a cluster, you don't have to manually provision and de-provision the Oracle Cloud Infrastructure services each time you deploy or un-deploy an application on the cluster. Instead, you interact with the Oracle Cloud Infrastructure services by usingkubectlto call the Open Service Broker APIs implemented by OCI Service Broker for Kubernetes. - Registry
Oracle Cloud Infrastructure Registry is an Oracle-managed registry that enables you to simplify your development-to-production workflow. Registry makes it easy for you to store, share, and manage development artifacts, like Docker images. The highly available and scalable architecture of Oracle Cloud Infrastructure ensures that you can deploy and manage your applications reliably.
- 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. 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.
- Microservices
Use Istio Service Mesh to connect the microservices with a proxy in order to provide tracing information visualized in Kiali.
Use Jaeger for tracing and Kiali for observability of the Istio mesh.
- Helidon
Use Helidon MicroProfile annotations to monitor the microservices health and liveness.
- Autonomous Transaction Processing
Oracle Autonomous Transaction Processing is a self-driving, self-securing, self-repairing database service that is optimized for transaction processing 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.
The following diagram is an example of the workflow of a microservices architecture for an online mobile food delivery application.
Description of the illustration microservices_converged_db.png
The following steps appear in this architecture:
- Customer searches online reviews and places an order. The Order Service microservice has a Search Reviews feature. Search Review requests and orders are sent through a load balancer to the Order Service microservice. The Order Service communicates with the database.
- Text and JSON data search and sentiment analysis are sent to the Search Reviews feature.
- The Order Service and Check Inventory Service microservices communicate with each other using transactional messaging.
- The Order Service sends a place order for delivery request to the Delivery Service microservice.
- Spatial calculation for single or multiple deliveries is sent from the database to the Route Mapping feature of the Delivery Service.
- Lowcode operational analytics are sent from the database to the Analytics Dashboard.
Recommendations
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point:
- Simplicity
The architecture amplifies the need for simplicity in designing the persistence layer for microservices with an Oracle converged database. Database security models are a good starting point to get authentication and authorization security. In addition, using backup and high availability of the database simplifies the microservice development.
A good understanding of the application drives the data access for each microservice with the design on bounded contexts, and loose coupling within the multitude of these services. Start with schema level isolation.
Correct sizing of the microservice is important to make data dependencies more manageable.
Event-driven transactional messaging built within the Converged database allows for loose coupling between microservices while preserving exactly once messaging, providing an efficient implementation of eventually consistent transactions across microservices (called sagas).
- Observability and Manageability
Observability and manageability with Helidon annotations and the use of tracing tools allows for automation in operating a microservices-based application at scale. This is an area to design well, at both the application tier and at the database tier, especially as the load on the microservices grows and adjustments are required for performance and availability at scale.
- Extensibility
Containerization of microservices that are managed by Oracle Cloud Infrastructure Container Engine for Kubernetes allows for extensibility of the application tier. While it is not always recommended to have each microservice have its own database, it is certainly possible with the converged database’s architecture. Often schema level isolation between microservices provides good isolation from unnecessary data dependencies.
- Security
A converged database provides a high level of security that an application can use to provide user level roles, authentication, authorization, and data encryption. Secure access of the microservices is also provided by Helidon in conjunction with the security in the persistence layer.
- Scale
This architecture adds microservices instances using Oracle Container Engine for Kubernetes to manage them, and a load balancer to allow use of multiple instances for each service seamlessly. Availability and scaling are addressed by using this paradigm for microservices. The database provides simple autonomous scaling to a certain level (2 to 48 Oracle Compute Units (OCPUs) per database system), which may work for most applications.
Considerations
Consider the following points when deploying this reference architecture.
- Performance
Scale application performance horizontally by adding additional instances for the microservice and manage with Kubernetes.
Scale database performance by observing the database load in Oracle Autonomous Transaction Processing performance console and increasing the number of OCPUs (up to 48 in ATP-Shared).
- Security
Security for microservices follows the security provided by Helidon Microservices and the Oracle Database security model – authentication, authorization, access control of resources. Oracle recommends that applications use the security enforcement mechanisms of the database as much as possible.
- Availability
High availability has two parts, the application layer and data layer.
Application availability is achieved by having stateless containers, being respawned by Kubernetes, and recovering any state from the middle tier metadata or the database.
Physical standby for PDBs across Oracle Cloud availability domains or across regions is recommended for high availability architectures. Review Oracle Database high availability parameters for other recommendations.
- Cost
Cloud economics applies to this microservices reference architecture. All components are available on Oracle Cloud Infrastructure as a managed service, and you pay for what you use, rather than paying for provisioning hardware.
Deploy
The Terraform code for this reference architecture is available on GitHub. You can download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.
- Deploy using the Terraform code in GitHub:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.
- Deploy using Oracle LiveLabs Building Microservices with Oracle Converged Database Workshop.
More Information
For more information, see the following resources:
- Building Microservices with Oracle Converged Database Workshop
- Microservices Getting Started Whitepaper
- Helidon Microservices
- Jaeger Tracing
- Istio Service Mesh and Service Management
- Kiali Service Mesh Management for Istio
- Transactional Event Queues and Advanced Queuing User's Guide
- Oracle Database High Availability Overview
- Oracle Database Security Guide