What is Cloud Native?
In the past few years, you might have heard the term “Cloud Native”, circulating in the developers’ sphere and might be wondering what it means. The cloud-native approach generally entails the use of cloud computing resources, for example, container-based application hosting, object storage, messaging, and orchestration services. Oracle offers a range of services under their Oracle Cloud Native portfolio that help developers build cloud-native applications. For convenience, here’s the list:
- Container Engine for Kubernetes (OKE)
- Events Service
- API Management
- Oracle Linux Cloud Native Environment
A few notable services to highlight are the Registry, Functions, and API Management services.
1. Registry. Every Oracle Cloud tenant has access to a Docker API-compliant registry to store and host container images. You can use it to host private container images and deploying to an environment like OKE. The Registry service is also an integral part of the next service that I want to highlight, Functions.
2. Functions. Functions is Oracle’s solution for serverless computing that is based on the open-sourced Fn Project. This is a powerful solution that allows the developer to deploy serverless functions using a Docker image. This allows developers to easily package software dependencies in order for their functions to execute.
3. API Gateway. Powerful as they are, invoking Functions can be a challenge. You can mask the intricate steps of invoking them, by using Oracle API Gateways.
Why It Matters to APEX Developers
As much as we love the platform, we can’t solve all problems with APEX. Some of the key principles of the Microservices architecture are to develop in small, specialized units, often employing the best software platform available to implement the solution. At Kscope17, I spoke about “Buildling in Blocks” (it was also presented as an Insum webinar) and the importance of maintaining a balance of what you implement in APEX, and when you should avoid “reinventing the wheel” and consider integrating other solutions instead.
Insum has been working with MineSense in the past few years to develop its digital platform using robust Oracle technologies. MineSense is an innovative company based in Vancouver, British Columbia, Canada, that helps mining companies increase their yields and improve efficiency, thereby reducing their environmental impact. They do this by applying Machine Learning models on IoT (Internet of Things) sensor data that help mining operations make better decisions. You can read more about their story over here.
For MineSense, serverless technologies are used to solve two problems: (1) datalog processing, and (2) multimedia processing.
Data Processing with Python
MineSense’s data scientists largely use the Python programming language for data processing. Many of these scripts were initially deployed and ran within Docker containers that were scheduled and triggered by Linux CRON jobs. It also relied on third-party, cloud-based file-sharing services for file storage and sharing. Unfortunately, this approach did not scale well and we had to design a more efficient approach to handle data processing during peak periods.
We were a step ahead with encapsulating the Python code as Docker containers, as it was an easy process for turning these into Oracle Functions. The serverless approach allows MineSense to scale automatically depending on the inflow of data files to be processed.
Multimedia File Storage and Processing
For multimedia processing, we have developed an Oracle Function approach for generating thumbnails of images uploaded by APEX application users. When an image file is uploaded to an Object Storage bucket (learn how to do this with APEX in this Oracle Magazine article) that then emits an OCI Event. This event then triggers the Function to perform the multimedia transformation.
Oracle Multimedia, as you are aware, is going away and so we can no longer rely on it for such requirements. In a more traditional approach, one might think about running a DBMS Scheduler job, after the files have been uploaded through an APEX application. However, this approach allows us to offload these computationally intensive operations to an on-demand resource. Plus, DBAs like to keep their database server free of unnecessary software, so installing Imagemagick is something we’d frown upon. Using Function to perform these transformations is one great alternative solution.
In a Microservices architecture, API Gateways are a great technology to shield client code from the complexities of working with disparate services. Since Oracle Functions are not REST services, the OCI API Gateway acts as a middleman for an APEX application, handling intricate processes like authentication and logging.
OCI API Gateways are also a great interface between on-premise REST APIs that are now needed outside of the private network environment. These services might have been developed using other programming languages like Node.js or Python, and may not have the necessary security protections needed to expose it as a public API. API Gateways are a convenient snap-in and apply housekeeping functions that haven’t already been implemented. Most recently, we helped guide an Insum client develop a proof-of-concept API Gateway that would help them expose a previously developed System for Cross-domain Identity Management (SCIM) API. It took minimal effort and the client was very impressed and has since extended the use of this OCI feature for serving up other in-house REST APIs.
For APEX developers, running Kubernetes clusters may not make as much sense as it does for other programming languages and frameworks. However, at Insum, we use Docker containers quite a bit. For example, running web applications like Tomcat, Apache Web Servers, and tools like Certbot, to support our APEX infrastructure. Running the software in containers help us manage application dependencies and server configurations better.
As for working with other OCI cloud-native features, how can we utilize them in APEX? Always remember, REST and JSON are our friends. As long as these features are available to us as REST and work well with structured formats like JSON, then there’s always an opportunity for integration. We can also wrap them using API Gateways and Oracle Functions. The opportunities are endless!
I hope you have found this short write-up to be useful and that it has helped demonstrate the synergy between APEX and cloud-native technologies. If you have an interesting problem to solve, or simply would like to have a more in-depth chat on what this means for your business or organization, then please do not hesitate to reach out. I’d be happy to have a virtual coffee session to talk cloud-native.
Title photo credit: Kirill Pershin