Java Cloud Service - detailed observations
15 Sep 2015 by Simon Haslam (in General)
|I've been working with Oracle's full Java Cloud Service (JCS) for the past couple of months so thought this might be a good time to share a few observations, This blog post is mostly an informal list of observations and experiences - I am gradually refining my ideas into proper articles and presentations which I will publish over the coming months.|
Oracle PaaS Technical Architecture
My high level view of the technical architecture is as below:
As you can tell this diagram is work in progress; really the various Cloud Services (and I've only shown a few) are overlaid on each of the infrastructure tiers, but I haven't found a good way to show that yet. I'll come back to what might be under the covers later in this post.
JCS Service Levels
JCS comes in 3 "service levels" or variants:
- JCS SaaS Extension (sometimes written as JCS-SX)
- JCS Virtual Image (JCS-VI)
- JCS (i.e. full JCS, sometimes called JCS PaaS)
You may remember from my "JCS - initial impressions" post that JCS-SX is a highly constrained WebLogic environment that allows you to easily deploy certain types of web application. It seems to me now that the JCS-SX is a completely different underlying platform (probably due to its age) to JCS-VI and full JCS. It's also strange that JCS-SX is still only available in WebLogic 11g (10.3.6) given that 12c has been available for several years now - it doesn't strike me as that difficult for Oracle to offer 12c, so maybe there's some re-engineering work going on behind the scenes to modernise the JCS-SX infrastructure (which must have been launched prior to the Nimbula acquisition).
Oracle is positioning JCS-VI for test systems and full JCS for production (and pre-production). Having now spent some time digging the only difference I can see between the two variants are in the tooling - full JCS has:
- automated patching, including applying patches in a rolling manner without outage,
- automated backup/restore that can also be co-ordinated with the associated FMW database,
- a scale up and down feature to add managed servers to the cluster (either WebLogic or Coherence).
Otherwise initiating provisioning is the same (except that full JCS needs a storage container specifying for its backups), the VMs themselves appear identical, and I didn't notice any difference in performance. It is of course possible that in the future Oracle might raise the quality of service of full JCS instances (such as using the newest servers only for full JCS, or maybe prioritising full JCS provisioning ahead of JCS-VI when busy), but right now they seem otherwise identical. The cost of full JCS compared to JCS-VI is an uplift 38%-100% so you will need to think carefully about this decision.
Provisioning and Typical JCS Topology
Focussing my attention on full JCS and JCS-VI for the rest of this post, this screenshot covers almost all you need to know about creating a JCS instance:
After provisioning such an instance this is what you end up with:
As you can see JCS takes some deployment topology decisions for you. In particular:
- The WLS Admin Sever and Managed Server is always on the first VM in the instance
- There's only one Managed Server per VM
- There's one Traffic Director installation per JCS instance, not shared amongst multiple independent WebLogic domains
- The Traffic Director Admin Server and Admin/traffic Node on one VM
- There are no standby Traffic Directors with VRRP fail-over; recovery is handled by the VM itself being restarted by OPC
- You only have a single WebLogic cluster
I'm not going to step through the considerations for each design decision here, but it does show that, as it stands today, JCS will be more suitable for some types of applications than others. On the other hand JCS is also still evolving quite rapidly so many of these constraints may well be removed, perhaps with more specialised options becoming available via the REST APIs (if not JCS console).
Working from within virtual machines means it is tricky to glean too much information about the physical infrastructure. Arguably what's under the covers is irrelevant providing service levels are met but, like most aspects of IT, if you don't have at least some idea of what's happening below your current level of abstraction then it's very difficult to fix issues.
We can see the Oracle Public Cloud (OPC) runs on x86-64 servers using Xen/OVM to provide virtual machines. For example, the VMs in my test JCS instances have been on Intel E5-2690v2 processors, as used in Oracle X4-2 servers and engineered systems. As an aside: there's been some recent speculation that Oracle's possible new SPARC chip (code-named "Sonoma") might be ear-marked for Oracle Cloud - whilst I could imagine someone in Oracle Towers is already dreaming up an "Engineered Cloud" with wall-to-wall InfiniBand and Software in Silicon stuff, I'm pretty confident that most of us will be looking at x86 cloud for the foreseeable future. Returning to JCS: all the VMs run Oracle Linux 6.4, which is a definite upside for anyone working with RHEL or OL for some time, since the operating environment is very familiar.
We can also see that the block storage runs over iSCSI and that it has some healthy response times (I'd encourage those of you interested in database performance to check out Frank Pachot's recent posts: DataBase Cloud Service performance – IOPS, CPU and Network) so, as Kevin Closson speculated on Twitter, it's likely provided by ZFS Storage Appliances with huge DRAM caches.
The cloud services are orchestrated by "Service Managers" and, presumably, components from Oracle's Nimbula acquisition. This gives it the feel of Amazon EC2 and OpenStack (for example the way the VMs can query attributes), so I expect anyone with AWS experience will feel comfortable with OPC.
OPC REST APIs
Speaking of OpenStack, you can interact with the OPC Service Manager either clicky-clicky via the web console shown above, or via REST APIs. The REST APIs are brilliant and give you a clean, predictable and trackable means to co-ordinate infrastructure provisioning. Oracle's JCS REST API documents are clean and easy to use too:
My subjective impressions of both performance and stability have been very good. Over 2 months I would say the JCS console itself (i.e. the Service Manager) was running very slowly or intermittently on perhaps 3 or 4 occasions but that was usually at weekends (presumably during maintenance). This affected the provisioning processes, not the VMs that were already running.
I did have one tricky issue where disk space filled up on my database service VM and made a bit of a mess; this then had a knock-on effect to the backup of JCS which kept failing (and retrying). I was rather engrossed with SOA at the time and it took me a while to figure out what was going on, but what it did highlight to me was that, in situations like this, all those Oracle and system administration skills you've acquired over the years will still come in very useful.
Implementation Approaches and Best Practices
Despite cloud services being an abstract way of using computing resources Oracle's different PaaS services work at different levels of abstraction. For example, something like the Docs Cloud Service or Integration Cloud Service work at a relatively high, functional level with relatively few big technical decisions required, other than sizing, unless you move to more specialist needs (such as writing Cloud Adapters). On the other hand Java Cloud Service (full and JCS-VI) or Database Cloud Service, is operating at a much more detailed level, and so gives you more implementation choices.
I think it's still far too early to be talking about best practices for JCS, although I do already have a few ideas from mistakes I've made during my investigations. I'd love to discuss further with others who have spent some time on JCS so, if you're interested, please find me at an Oracle conference or drop me an email.
Having now had a good opportunity to put full JCS through its paces I like what I see! Its strengths lie in it running on modern hardware without any apparent resource contention (so far), it's straightforward to use, it has super REST APIs allowing modern provisioning automation, it comes with Traffic Director for very nice load balancing, and its WebLogic domain configuration seems well thought out.
If you're interested in JCS and like this post please check out the following:
- OTN Virtual Technology Summit is running 3 times, suited for different time-zones, in September - 60 minutes of technical details, demonstrations and general poking around on JCS! I'll be on hand to answer questions too. The first one is tomorrow - see the OTN blog for how to register for free.
- Oracle OpenWorld 2015 "What Should I Do Now? Oracle Java Cloud Service for the Oracle WebLogic Server Administrator [CON7037]"
- UKOUG OracleScene: my article about JCS in Q&A format will be the next issue
- DOAG 2015: a chance to see my OOW JCS session in Germany in November