How do you scale your Spring DM or POJO applications without development framework lock-in?

"Cloud centric composite applications promise to be more disruptive and more rewarding than either the move to client-server architectures in the early 1990’s, or web-services in the late 1990’s. A successful Private Cloud / Platform as a Service (PaaS) solution will provide the robust and agile foundations for an organization’s next generation of IT services.

These Cloud / PaaS runtimes will be in use for many years to come. During their lifetime they must therefore be able to host a changing ecosystem of software services, frameworks and languages.

Hence they must:

• be able to seamlessly, and incrementally, evolve in response to changing business demands

• at all cost, avoid locking an organization into any one specific development framework,

programming language or middleware messaging product."

Want to know more? Read the new Paremus Service Fabric architecture paper which may be found here.

Cloud Computing - finally, FINALLY, someone gets it!

I've been really busy these last few months. So not had the time or inclination to post. Yet after reading Simon Crosby's recent article Whither the Venerable OS? I felt compelled to put pen to paper - or rather should that be fingers to keyboard.

Whilst a good read, the magic paragraph for me appears towards the end of Crosby's article.

"If IaaS clouds are the new server vendors, then the OS meets the server when the user runs an app in the cloud. That radically changes the business model for the OS vendor. But is the OS then simply a runtime for an application? The OS vendors would rightly quibble with that. The OS is today the locus of innovation in applications, and its rich primitives for the development and support of multi-tiered apps that span multiple servers on virtualized infrastructure is an indication of the future of the OS itself: Just as the abstraction of hardware has extended over multiple servers, so will the abstraction of the application support and runtime layers. Unlike my friends at VMware who view virtualization as the "New OS" I view the New OS as the trend toward an app isolation abstraction that is independent of hardware: the emergence of Platform as a Service."

Yes! Finally someone understands!

This is IMO exactly right, and the motivation behind the Paremus Service Fabric; a path we started down in 2004!

OK, so we were a bit ahead of the industry innovation curve.

Anyway, related commentary on the internet suggests that Simon's article validates VMwares acquisition of SpringSource. Well, I'd actually argue quite the opposite. Normal operating systems have been designed to run upon a fixed, unchanging resource landscapes; in contrast a "Cloud" operating system must be able to adapt, and must allow hosted applications to adjust, to a continuously churning set of IaaS resources. Quite simply, SpringSource do not have these capabilities in any shape or form.

However, I would disagree with the last point in Simon's article. Having reviewed Microsoft's Azure architecture, it seems to me no different from the plethora of Cloud/distributed ISV solutions. Microsoft's Azure platform has a management/provisioning framework that fundamentally appears to be based on a Paxos like consensus algorithm; this no different from a variety of ISV's that are using Apache Zookeeper as a registry / repository: All connection oriented architectures, all suffering with the same old problems!

Whilst such solutions are robust in a static environment, such approaches fail to account for the realities of complex system failures. Specifically, rather than isolated un-correlated failure events, failures in complex systems tend to be correlated and cascade! Cloud operating systems must address this fundamental reality and Microsoft are no further ahead than VMware or Google; indeed the race hasn't even started yet!

And the best defence against cascading failure in complex systems? Well that would be dynamic re-assembly driven by 'eventual' structural and data consistency.