The Application Container Cloud team has been busy working on a bunch of cool new stuff—most notably a few weeks ago releasing the new "Application Cache" feature.
As many folks are starting to learn, Application Container Cloud is Oracle's polyglot lightweight application development/deployment environment—build your single process Java SE, Node, PHP, etc. service and within Application Container Cloud, you get a horizontal scale out docker-based infrastructure for that service. These services can be wired together in Stacks enabling you to build out relatively complex applications made up of many different microservices interacting with one another. There are various cool capabilities like an automatically plumbed in software load balancer front ending the service endpoints, a prescriptive 12-factor style of development and deployment, some really nice diagnostics for Java apps using the Java Flight Recorder feature of the Oracle JDK, and a fully integrated DevOps tool chain using the Oracle Developer Cloud Service for continuous integration and delivery. Here's more on the development model for Application Container Cloud here for those new to it.
But something that had been asked by many of the developers using Application Container Cloud is whether it could provide some way to share state or cache data across multiple application instances but still hold true to the standard 12 factor model of development that the Application Container Cloud espouses? From this question was born the new Application Cache capability.
Under the covers Application Caches run on the super scalable datagrid infrastructure of Oracle Coherence, but to the application interacting with it it looks just like a simple GET/PUT REST API. As a picture says a thousand words, architecturally it looks like:
Creating an Application Cache is very simple—simply go to the platform services page of the Oracle Cloud and click on Create a Cache and you will get a self-explanatory wizard pictured below where you can set the cache size and level of reliability (basic is single JVM node for development whereas the recommended is a highly available clustered cache) you want as shown below:
Once deployed there are really two basic steps to utilize it in your Java, Node, or PHP Application Container Cloud service:
1. Bind your cache to your Application Container Cloud services that you want to share data with. This is done declaratively through the service binding feature of ACCS, where you wire together the moving parts of your application.
Visually what is described in the documentation looks just like the screen shot below for the cache I created above. I am connecting the cache MyCache to the Java service "Green." Under the covers what this is doing for you is setting a few environment variables documented above and ensuring there is secure network connectivity to the MyCache cache:
2. As the cache currently exposes a simple REST based API for get, store, replace and remove you can simply borrow from the code samples we provide for Java, Node and PHP in the documentation here:
Something very cool that has happened around application caches is as the community around Application Container Cloud grows, people are building out all sorts of supporting demos and libraries. For example, within a couple of weeks of the caching capability going live, Callan Howell-Pavia created a very nice helper library to wrap the REST APIs in Node for those developers creating, testing, and running Node applications on the Application Container Cloud. Very cool and available here.
This area is also something the Application Container Cloud core engineering team is planning to formalize over the next few monthly releases. Rather than just providing raw REST APIs, having a formal set of application client libraries is clearly the next step—but in the meantime this library already gives a great working model today for folks wanting to get busy with an API abstraction.