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:
A few notable services to highlight are the Registry, Functions and API Management services.
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, specialised 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 their digital platform using robust Oracle technologies. MineSense is an innovative company based in Vancouver, British Columbia, Canada, that help 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) data log processing, and (2) multimedia processing.
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 by 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.
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 transformation 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 framework. 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 utilise 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 wrapped them using API Gateways and Oracle Functions. The opportunities are endless!
I hope you have found this short write-up to be useful and 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 organisation, then please do not hesitate to reach out. I'd be happy to have a virtual coffee session to talk cloud-native.
Notes for Marketing Team: