Red Hat Summit and JBoss World – 1

Written By:
Published:
Content Copyright © 2012 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt

I wear hats. I wonder if I dare wear my bright red Orvis packable lite felt fedora with a red band here? I’m kinda interested whether I’ll see any red hats at this event and whether they’ll be “Real Hats” or just toys…

Enough of whimsy (and I only saw a couple of real Red Hat fedoras with a black band, although a lot of red baseball caps were given away). I’m also interested in seeing how Red Hat, in effect, is bringing technologies from different partners together in an ecosystem – converging on CEO Jim Whitehurst’s goal of becoming “the default choice for next generation IT architectures” perhaps? There’s Robert Leblanc from IBM (I last heard him a week or so ago at Innovate); Irfan Khan from SAP; and so one. It’s becoming a sort-of one-stop-platform for technology…. And, unlike at some other events, I’m looking to have time to get to more tech sessions, more comfortably…

I’m also looking forward to JBoss developments, especially on the Business Rules front, and Craig Muzilla (VP Middleware Business Unit, Red Hat) didn’t disappoint. Although I thought he was perhaps over-modest when he said that “this open source thing is really starting to no take off”; as I thought that had happened some time ago, he told a strong story (and remember that Red Hat has now passed the $1billion barrier). Technically, the story is around JBoss Enterprise Application Platform 6, the JBoss Data Grid (its NoSQL, distributed cache, in-memory data management offering) and, of course, JBoss Enterprise BRMS (Business Rules Management System), which he described as JBoss for people who can’t code Java.

The devil is in the detail, of course, and I wonder how NoSQL enthusiasts cope with giving up the ACID properties of relational databases (although, as Red Hat points out, after the Big Data revolution there’s still a place for relational structured data). And, although Business Rules enable better business agility without code, there is a question of how complexity is managed as Business Rules evolve with business changes and, possibly, the business overlays rules on rules and even tries to implement inconsistent rule sets. Nevertheless, the JBoss demo was impressive (if based on a pretty simple scenario) and, as usual, I got the impression that JBoss knew what it was doing – part of its support offering includes advice on how to develop and manage rules.

Dr Mark Little (Senior Director, Middleware Engineering, Red Hat), who was probably pretty stressed until the live demo completed OK, identified several issues that Red Hat is striving to address. First, that the JVM wasn’t originally architected for multi-tenancy (that is, you tend to feel safest with 1 app per JVM as a single rogue app can bring down everything on a JVM running several apps) and this really limits efficiency in utilising resources (and, of course, there’s the non-deterministic garbage collection issue, although I thought there were already several solutions to that). Little hopes to see a single modular JVM emerge, a lightweight JVM into which you can plug modules providing (for example) multi-tenancy if (and only if) you need them. However, that’s up to the Java Community Process to manage….

Second, Little identified the Big Data and NoSQL issue and the need for effective standards in the area (he mentioned Red Hat’s involvement in JSR 107 and 347). No argument from me there, and I look forward to seeing its document-based NoSQL solution in more detail.

Thirdly, I was particularly pleased to hear Little attack J2EE bloatware: “the standard isn’t bloated, some JVM implementations might be”. So, if you want bloated J2EE you can buy it – just not, he claims, from Red Hat…

His fourth issue was the polyglot explosion in new languages and I liked his approach around leveraging what we’ve got rather than implementing everything from scratch. Reuse is good and he talks about providing proper APIs in other languages to tried-and-tested Java technologies that address language issues, not just providing a loose wrapping around a Java invocation that leaves he underlying Java visible.

He noted “constrained devices”- such as Raspberry Pi as a 5th issue. This is somewhat related to his bloatware issue, in my opinion. He’s managed to get a full Java EE stack running on a Raspberry PI, which isn’t so unreasonable when you think even this has the power of a business laptop of some years ago, and even that could run quite a bit of software and still do useful work.

Compare that with Nik Software’s functionally excellent Snapseed photo editor, which runs almost unreasonably slowly on a Netbook – a rather less “constrained device”. Snapseed can take advantage of the graphics coprocessor in an Ultrabook and run on an iPad but it can’t cope with a wimpy machine that “only” has a spec somewhat higher than what I bought as a power-hungry business laptop a few years ago.

The availability of cheap memory and multicore processors shouldn’t blind us to the fact that, in the universe of things, resources may still be limited in some places and that “bloat” – inefficiency and waste, in other words – is a bad thing. I’m perhaps being a bit unfair to a graphics-intensive app like Snapseed, but I’m sure that Nik’s programmers could make it perform adequately on a NetBook if they thought it was a platform worth bothering with. Programmers have always had a tendency to program for the latest and fastest platforms and exploit the availability of cheap memory and power as wastefully as they can. I’m glad that this doesn’t seem to be the attitude at Red Hat.

In general, then, I’m encouraged by this JBoss World keynote and its implications for Red Hat’s general approach. Perhaps its claim that technology choices are coming down to the choice between a proprietary cloud platform and Red Hat’s open hybrid cloud PaaS offering is correct. There’s lots more but that’ll have to wait. This blog is already long enough and I haven’t got started on the General Session yet! Oh well, next time…