The recent OSGi community event in London proved interesting from a couple of perspectives.
Dependencies – from Kernel to Cloud
Paremus engineers are no strangers to the idea of OSGi Cloud convergence. Having realised the potential of dynamic software assembly and resource abstraction in 2004, Paremus have had the opportunity to engineer a robust & architecturally coherent solution that delivers this vision.
Arthur C Clark’s third law: Any sufficiently advanced technology is indistinguishable from magic.
These concepts were presented by David Savage in his OSGi community talk ‘OSGi & Private Clouds‘; which included a live demonstration of the Service Fabric assembling a distributed trading system across a group of dynamically discovered compute resource.
Behind the scenes the demonstration involved the use of the Paremus OBR resolver (Nimble) and the new Paremus RSA stack (configured to use SLP discovery and an asynchronous RMI data provider). Perhaps not magic, but very cool none the less 🙂
So I’d argue that Paremus have the OSGi Cloud piece of the puzzle; but what about “the Kernel”?
Whilst the demonstration, consisting of the manual customisation of a JVM, was interesting; to my mind the full potential is only realised when such customisation is dynamic and in response to business requirements. To achieve this one must manage not only OSGi transitive dependencies, but also service dependencies and most importantly environmental runtime dependencies. Luckily, Paremus have these capabilities with Nimble; so perhaps in due course we’ll take a closer look at Harmony.
But then, why stop at Java?
Nimble is not just an OSGi resolver but a general dependency resolver, with extensible dependency types and deployable types. Debian is a well defined packaging standard which defines dependencies and installation from a Debian package repository is already standard practise. The Canonical ‘Ensemble‘ project is attempting exactly this: dynamic download of interdependent Debian artefacts and subsequent service provisioning.
So, are we witnessing “The Rise of the Stackless Stack” and the end of the industries infatuation with hordes of virtual machine images with static pre-baked software and configurations? I think so.
That said, contrast if you will this “Stackless Stack” vision with the Oracle’s big news:
“Oracle Exalogic Elastic Cloud is the world’s first and only integrated middleware machine—a combined hardware and software offering designed to revolutionize datacenter consolidation.”
Expensive big iron, crammed to the brim with unwanted middleware. The contrast really couldn’t be greater!
Boiling the Frog
One frequently hears complaints about OSGi:
- Its too difficult!
- What is the immediate business benefit?
The first is simple to address. No excuses – use Nimble.
The second complaint has, in my opinion, more to do with human nature than technology. All too frequently instant gratification is selected over long term health. In a similar way, for many organisations, at each point in time, the operational pain isn’t sufficient to warrant fundamental change in behaviour: it just slowly keeps getting worse.
Hence the “Boiling the Frog” analogy.
The venture capital community understand this only too well.
Sell them the Aspirin!
And at all cost ignore the existing gordian knot inadvertently created from 20 years of IT quick fixes.
Hence it was a sheer delight to listen to Eric Newcomer’s (chief architect at Credit Suisse) presentation on his bank’s considered approach to SOA and software modularisation. To summarise – Architecture is important, OSGi is important! No quick fixes, but an ongoing coordinated strategy that is intended to serve the business for the next decade.
I’m sure Credit Suisse will succeed, and I know Credit Suisse are not the only organisation starting down this path.
OSGi is a fantastic enabler, but its not magic. It can be a bitter medicine; but with a coherent OSGi / Cloud based strategy and disciplined implementation, these technologies will transform your operational cost base and your business.