Deploy a Microservices-Based Application in Kubernetes Connected to an Autonomous Database

Architecture

In a microservices architecture, each microservice performs a simple task, and communicates with clients or other microservices by using lightweight mechanisms such as REST API requests.

This reference architecture is for an e-commerce application that's composed of multiple polyglot microservices deployed as Docker containers in a Kubernetes cluster. Data persistence is achieved using an Oracle Autonomous Transaction Processing database. Media and image files for the e-commerce application are stored in Oracle Cloud Infrastructure Object Storage.

The following diagram illustrates the architecture.

Description of mushop-infrastructure.png follows

Description of the illustration mushop-infrastructure.png

The architecture has the following components:

Regions
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. Oracle Cloud Infrastructure Container Engine for Kubernetes handles distribution of the nodes in the cluster across multiple fault domains. So your containerized application is protected against physical server failure, system maintenance, and power failure within an 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.
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.
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.
Internet gateway
The internet gateway allows traffic between the public subnets in a VCN and the public internet.
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.
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.

In this architecture, the media assets of the application are stored in Oracle Cloud Infrastructure Object Storage in a bucket of the standard storage class.
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.

The following diagram shows the interactions between the containerized microservices in this architecture:

Description of the illustration mushop-infrastructure-expand.png

Traffic from the public internet is routed by the DNS service through a web application firewall (WAF) to the load balancer, which forwards the incoming requests to an Ingress (Nginx) microservice. The Ingress microservice sends traffic to a Router (Traefik) microservice. Depending on the nature of the requests, the Router microservice routes them to the appropriate microservices in the application. Besides interacting with other microservices, many of the microservices also interact with Oracle Cloud Infrastructure services: Object Storage, API Gateway, Functions, Email Delivery, Streaming, and Autonomous Database.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.

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.

Use regional subnets.

Note:
The Terraform code to implement this architecture provisions the Oracle Autonomous Transaction Processing database in the Oracle services network. If you prefer to expose only a private endpoint for the database, then you can adjust the Terraform code to attach the database to a private subnet, as shown in the architecture diagram.
Container Engine for Kubernetes
In this architecture, the worker nodes in the Kubernetes cluster use the VM.Standard2.1 shape, and they run on Oracle Linux. You can create up to 1000 nodes in a cluster.

Considerations

When implementing this architecture, consider your requirements for the following parameters:

Scalability
You can scale out your application by updating the number of worker nodes in the Kubernetes cluster, depending on the load. Similarly, you can scale in by reducing the number of worker nodes in the cluster. When you create a service on the Kubernetes cluster, you can create a load balancer to distribute service traffic among the nodes assigned to the service. This architecture uses a load balancer to handle incoming requests.
Application availability
Fault domains provide resilience within a single availability domain. You can also deploy instances or nodes that perform the same tasks in multiple availability domains. This design removes single points of failure by introducing redundancy. In this architecture, Container Engine for Kubernetes is responsible for distributing the nodes across fault domains inside an availability domain and for managing the distribution of the microservices across the available nodes inside the Kubernetes cluster.
Manageability
All the microservices are containerized using Docker. These images are stored in the Oracle Cloud Infrastructure Registry service. The deployment is automated using Terraform, which also deploys other common services, such as Grafana, Prometheus, and Helm charts.

You can use other Oracle Cloud Infrastructure services, such as API Gateway, Functions, and Email Delivery to manage the backend APIs and to enable subscriptions to product-related newsletters or email.
Security
Container Engine for Kubernetes is integrated with Oracle Cloud Infrastructure Identity and Access Management (IAM), which provides easy authentication with native identity functionality. Use IAM policies to control who can access your resources and the actions that they can perform.

Consider usingOracle Cloud Infrastructure Web Application Firewall (WAF) to protect the application against malicious traffic from the public internet.

You can use the Oracle Cloud Infrastructure Streaming service to stream and record application-level events.

To protect your Kubernetes secrets, you can store them in a vault, or encrypt the secrets by using keys that you maintain in the Oracle Cloud Infrastructure Vault service. The Kubernetes cluster can access the vault, keys, and secrets privately through the service gateway of the VCN, without exposing the access requests to the public internet. Policies that you define in Oracle Cloud Infrastructure Identity and Access Management govern access to the vault. The Oracle Cloud Infrastructure Audit service lets you monitor and track the usage of your vault-protected keys and secrets.

Deploy

The code required to deploy this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

Deploy by using Oracle Cloud Infrastructure Resource Manager:
1. Click
  If you aren't already signed in, enter the tenancy and user credentials.
2. Review and accept the terms and conditions.
3. Select the region where you want to deploy the stack.
4. Follow the on-screen prompts and instructions to create the stack.
5. After creating the stack, click Terraform Actions, and select Plan.
6. Wait for the job to be completed, and review the plan.
  To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.
7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
Deploy by using the Terraform CLI:
1. Go to GitHub.
2. Download or clone the code to your local computer.
3. Follow the instructions in deploy/complete/README.md.

Explore More

Learn more about deploying containerized microservices-based applications to Kubernetes clusters in the cloud.

Change Log

This log lists only the significant changes:

December 1, 2020

Added steps to deploy the architecture by using Oracle Cloud Infrastructure Resource Manager.