Global Financial Meltdown and Google Mail Service Outage

Whilst the current global economic meltdown and the recent Google e-mail service outage may seem entirely different types of event, there is some degree of commonality. Both represent catastrophic cascading failure within large complex distributed systems.

The analogy unfortunately finishes there. 

Google were up and running again in a couple of hours whilst the worlds economies may take a decade to recover. However the central theme -  how to avoid systemic catastrophic failure within complex systems - remains of deep concern to system architects and economists alike. 

Where does that leave "Cloud Computing". Quite simply don't believe the hype. Public Cloud infrastructures will continue to fail, hopefully infrequently, but almost certainly in a spectacular manner. The next generation for Public Cloud will need to be built upon a more modular resources landscape (swarms of geographically dispersed meshed data centre nodes) - with a suitably advanced distributed & partition-able Cloud Operating System. 

Unfortunately the same is true of the current generation of Grid Provisioning and Virtualization Management Software solutions increasingly used by large corporations. Use of this technology will end in tears for a number of large IT departments. To much visible complexity, too little automation. Like the economic meltdown, these solutions fail to account for outlier risks which cause systemic failure within complex systems.

The answer? Well its not a programming language (sorry Erlang!), nor a specific piece of middleware, nor specific replication technology, nor classic clustering.

To start the journey one must first realize that... 

Agility and Robustness are simply two faces of the same coin.

Forget Cloud - OSGi is the new Cool Thing!

Or so an Industry Analyst recently informed me. 

Yet the flurry of Twittering & Blogging concerning the distributed OSGi section of the new OSGi 4.2 specification is certainly interesting. Is OSGi approaching some sort of enterprise adoption tipping point? These along with other commercial indications imply this is likely.

This is good news. OSGi deserves to be wildly successful, OSGi is one of the key enablers for the next generation of enterprise. 

Yet a danger lurks in the shadows. 

The use of OSGi does not in itself guarantee any sort of coherent architecture, nor is capable of addressing the current complexity crisis with the enterprise. OSGi is simply a tool - and in the wrong hands OSGi runtime systems will seem orders of magnitude more complex than the systems they replaced.  Meanwhile, the distributed OSGi section of the 4.2 specification is simply an acknowledgment that "things" exist outside the local JVM - no more - no less. 

Distributed OSGi has little to say about how to address Deutsch's 8 Fallacies ( actually if you follow the link you'll notice that Wikipedia now have a 9th :)  ). How these distributed entities discover each other, interact with each other, and which protocols are used is left as an exercise to the software vendor. This is not a criticism of the standard - this is a good thing. OSGi doesn't constrain distributed architectures. 

Yet this allows business as usual for the Software Vendors. And so we see the same old tired SOA rhetoric.

"ESB's & WS-*, would you like OSGi with that sir?"

But joking aside - the real danger is that OSGi's fate may become hopelessly entangled with the current disillusionment surrounding the web of vendor SOA Market-ectures. 

Paremus have always argued that OSGi deserves to be complemented by a network SOA framework that is as adaptable and dynamic as OSGi is locally within the JVM. A Self-Similar Architecture!

It was for this reason that Paremus fused OSGi (the new Cool technology) with Jini (was Jini ever Cool?) within the Newton project in 2006. A solution, in its commercial Infiniflow guise, which has been in customer production for over 2 years. 

As for Cloud Computing - that story has only just started ;-)