The union of SpringSource, an open-source application framework company, with Hyperic, a "build, run and manage" tools vendor, arrived with the claim of being able to compete with Microsoft and IBM - saying a lot about how some perceive the importance of interoperability.
The salient discussion surrounds what is exposed by the platform. Some believe that what one should see is the appserver or application framework, and on some rare occasions, an application runtime. IMHO this could not be more egregious. Developments with Web applications over the last 4-5 years have made it quite clear that all one really needs is an endpoint or URI (I won't step into the REST vs WS debate in this post), and going beyond that simply takes us "back to the future" - that of J2EE, star architectures and tight coupling.
Whilst this still has currency with infrastructure development - albeit having the level of coupling greatly ameliorated by frameworks such as Spring - it has none with application development. Microsoft has recognised this and driven scripting and managed code development with WPF and its Silverlight subset in response, which has only succeeded in bringing more app development to its doorstep. Adobe's continued work on Flex and AIR have transformed it into one of the principal Web platforms of choice. Ruby on Rails has taken the development of Web apps by storm. Prism, JavaFX and other frameworks are responses to these successes. Spring has endeavoured to enable a greater level of abstraction at the system level, moving the needle on abstraction and loose coupling enabling many of these frameworks. On the other had, there are those with more of a management consulting approach who will claim that one can do the same with a traditional server-centric architecture, and that enabling that for the Cloud is as simple as exposing one's EJBs as Web Services.
The very concept is risible, but sadly, it still bends the ear of many IT organisations which are struggling to get their heads around Web architectures. It calls to mind General Melchett from Blackadder goes forth: "A stubborn refusal to look facts straight in the face will see us through." There are still many who sell this stubborn refusal to accept the failures of the star architecture and the value proposition of distributed software, as there are those organisations who have had to swallow the bitter pill and re-craft their applications as distributed after miserably failing with the star architecture.
It is better not to start down that road, and embrace the abstraction afforded by Web and now Cloud architectures. If one has to know the axiomatic semantics of a service in order to use it, they are already too tightly bound, and essentially re-crafting a traditional desktop or server application as a Web/Cloud one. The abstractions provided as a part of Web and Cloud development are there to protect the developer and (eventually) the user, not to impede them.
Taking this to management and monitoring, we can see strong parallels to BPM and BAM. For the majority of cases, audit, management and monitoring at the abstraction level is more than sufficient. Only for someone seeking to debug an issue at a lower level is it necessary to drill down beyond the abstraction. This "click-down" is a critical feature of any audit, management and monitoring stack and is the most compelling value proposition from Hyperic - principally due to the applications to both automation, which is among the primary goals of CC, and fault handling/troubleshooting. Without the ability to report starting at the abstract level and provide for "click-down" to get to the bottom of a bug or issue when necessary, a system, whether CC or not, can neither achieve automation nor enable issue resolution in a reasonable timeframe.
The SpringSource/Hyperic union heralds good things to come. I look forward to the combined efforts of these organisations to advance the goals of Cloud Computing
Comments