Try though we might to shift everything to a glorious set of stateless services, there are still plenty of scenarios in which an application might need to store some state, commonly to track some information about a user and that user’s session. In these cases, an in-memory cache is a powerful addition to an application, and is nearly indispensable to an elastic cloud architected app which is expected to be able to scale horizontally on-demand, to allow information to be shared between application instances, avoiding the need for load balancer complexity to implement sticky-sessions. Application Container Cloud Service added the ability for applications to add a Caching Service binding in the 17.1.1 drop, and in this blog post we will explore how to leverage this capability in a Node.js application.
I’ve been using the API Platform and Integration Cloud Service (ICS) for some time now. Independently, they are powerful products but together they are even better.
Initially, most ICS use cases were SaaS to SaaS or an extension to an existing SaaS. But more and more I’m seeing people use ICS in place of a standard service bus to do basic validation, enrichment, transformation and routing.
But how do you expose these ICS services using standard API methods? Well, it isn’t too difficult to go into API Platform and define an API to point to the ICS service, but this could be quite tedious.
Luckily, all the Oracle products have an “API first” strategy, so it wasn’t too difficult to setup an ICS flow to automatically publish new services into the API Platform.
I have been Integrating applications for the last 15+ years and normally every integration is a new challenge. It really doesn’t matter what technology or standards you use or have used in the past, the reality is that integrations come a new set of challenges. In the past few years the pre-built adapters have simplified in a way these challenges, but with hybrid architectures a new set of challenges comes to the picture, for example; connectivity, security, simplicity, message reliability, etc.
I was very excited when I learned the way Oracle Cloud is using to solve this problem. It is with something called Oracle ICS (Integration Cloud Service) Connectivity Agents, that basically get installed close to the Application being integrated, for example on-premise or in IaaS. Then using ICS in a browser, you can introspect into the backend application as if it was close to ICS, in fact with this solution ICS is completely oblivious of the location of the actual backend application. The Connectivity Agent will in this case connect internally with the back-end applications and communicate to ICS by pushing out messages via Messaging Cloud Service.
Reading Alessia’s recent post about her experiments with beacons reminded me of a post that I have been meaning to write for a while, regarding my previous dabbling with building location-aware applications. Beacons are a powerful tool by which to provide fine-grained location services to applications, but need to be used carefully, and really need to be part of a larger mix of technologies in order to provide the richest experiences. In this post, I will look at the weaknesses I have previously encountered using beacons, and outline some of the strategies I have used to mitigate those weaknesses.
In a previous blog on OCCS, I covered the steps required to provision the service. As an input to the OCCS Service provisioning I was prompted to specify the number of worker nodes I required, which for my example I set to be two. Having provisioned the service, I can now start to build and run my Docker images on these worker nodes. As part of the provisioned service, I have a node dedicated to the Container Console which provides a nice web User Interface that allows me to Build, Deploy, Run and Manage Docker Containers on the worker node hosts that I provisioned as part of my service. The two worker nodes are the hosts that I will ultimately deploy and running the image of interest such as WordPress, MySQL, Oracle Database, Tomcat, Nginx, WebLogic Server or whatever you want pretty much. The Container Console makes it very easy to build, run and deploy images via a web administration console.