In September 2020, Oracle first announced that it was working with Ampere Computing to provide ARM-based chips for its Compute instance offering on the Oracle Cloud Infrastructure. They have delivered!
ARM chips are found in many low-powered devices like smartphones, single-board computers, and IoT devices. So, if you are an Oracle Application Express (APEX) developer, you might be wondering, “What’s in it for me?” Well, remember we talked about running a customer-managed Oracle REST Data Services (ORDS) instance for an Oracle Autonomous Database?
The OCI isn’t the first platform to offer ARM-based compute resources. You will find a similar offering from AWS with their Graviton processors. Instead of custom-designing a processor, Oracle opted to use the Ampere Altra Processor that has 80 cores running at a maximum frequency of 3.3 Ghz. Check out AnandTech’s review of the chip.
If you are interested to read about the performance comparisons between the ARM and x86 architectures, please check out this report. What I understand is that for hosting web applications that are typically single threaded, ARM chips offer a better cost-to-performance ratio, not to mention, lower power consumption. Each processing core is also generally cheaper than its competitors, thus allowing cloud vendors to provision them at cheaper rates. We saw this happening when Oracle first launched the AMD EPYC-based compute shapes that were cheaper than Intel’s at that time.
As with other processor types, OCI customers can opt to provision virtual machines or bare metal machines:
- VM.Standard.A1.Flex. Like the AMD EPYC Flex shapes, users can create instances with a flexible number of OCPUs and memory. Servers can be provisioned with 1 to 80 OCPUs, and 1 to 512 GB memory.
- BM.Standard.A1.160. Only one shape for bare metal machines is available at this time. It comes with 160 OCPUs and 1 TB of memory.
Oracle has also provided a generous Oracle Cloud Free Tier allotment of Ampere compute instance. Users can provision an Always Free compute instance with up to 4 OCPUs and 24 GB of memory (see the press release). The Always Free block volume allotment has also increased from 100 to 200 GB. Yes, there are no charges and no end dates for these resources. I will use this to host the customer-managed ORDS instance. Beyond that, according to the cost estimator, each additional OCPU will cost you only $10 per month, and $1 for every gigabyte of memory!
Note. These A1 cores are single-threaded. In x86-based shapes, 1 OCPU has 2 virtual CPUs.
The downside of moving to an ARM chip is the availability of software support. For example, though you can install the Oracle Instant Client on an ARM system, Oracle has not released AArch64 database binaries. Fortunately for us, there already exists a Java port for this architecture, so there should be no issues deploying ORDS or running it standalone. However, at the time of writing, the ORDS package is not available to install through the Oracle Yum repositories. I will instead deploy ORDS on a Tomcat server using Podman. The official Docker image that I will use can be found here. Take note that you will have to ensure that you deploy a version of ORDS that’s compatible to what the ADB is using.
After provisioning the Oracle Enterprise Linux 8 server, login as the user opc and install the following software:
- OCI Command Line Interface (CLI)
- [Optional] Support for emulating Docker CLI using podman
sudo dnf install python36-oci-cli podman podman-docker
Create the base directory where we will deploy our files to.
BASE_PATH=/opt/podman/ords && \
Stage the following installer files in the directory
Note: At the time of writing, the ADB is still running APEX 20.2 with the latest Patch Set Bundle. To download the patch, you will require a qualified support contract.
Create the following Dockerfile in the directory specified by the environment variable
Alternatively, run the following Bash script to create the Dockerfile:
cd $BASE_PATH && \
Build the container image.
cd $BASE_PATH && \
Set the following environment variables based on your tenancy, data region, and ADB:
Use the OCI CLI to generate the required ADB wallet, and then create the base64-encoded string needed for configuring ORDS to access the database.
export OCI_CLI_AUTH=instance_principal && \
Create the database user named in the environment variable
ORDS_USER and asssign the necessary privileges. Refer to the section User Accounts in the previous post if you require help. Then create the ORDS configuration files:
mkdir -p $ORDS_CONFIG_DIR/ords/conf && \
Prepare to stage the APEX images files by first setting the following environment variables:
Execute the snippet below to extract the necessary files from the APEX installation file and deploy them to the Tomcat container.
mkdir -p $APEX_IMAGES_DIR && \
If your instance is running a version of APEX that has a patch available, then be sure to apply it. Again, you will need access to Oracle Support with the rights to download patches. Set the environment variables:
Then run the snippet below to deploy the changes:
mkdir -p /tmp/$APEX_VERSION && \
Create a utility
run.sh script to run the container. The script allows one argument to set the port number to map to, and also used to set the container’s name.
cd $BASE_PATH && \
Finally, since we are running this as a rootless container, the firewall rules must be updated to allow communication on port
8080. Execute the following commands:
sudo firewall-cmd --zone=public --add-port 8080/tcp --permanent && \
Run the container that’s listening on port
cd $BASE_PATH && bash run.sh 8080
Finally, setup a load balancer for the customer-managed ORDS instance. This was discussed in an earlier post.
If you are also interested in testing out some “redundancy”, you might like to run a second container:
PORT_NUMBER=8081 && \
And then add this as a backend server that’s listening on port
8081 to the set. Just be really careful about exceeding the maximum number of concurrent database sessions if this is an Always Free ADB.
To be clear, this is really for experimentation and simulation use only. As a best practice, the second container should be deployed on a separate host, preferably in a different availability domain.
This is a great addition to the family of OCI resources that Oracle provides. Besides deploying customer-managed ORDS to complement the Autonomous Database, APEX developers can also use them to host other workloads to supercharge web applications. For example, running a WebSocket server using Socket.IO to display realtime updates, or hosting a REST service using Spring Boot. A choice of provisioning low-cost and highly-efficient servers, and the expanded Always Free limits. What’s there not to love?