Sunday, January 31, 2010

Ministratio Ecnephias: the Coming Hurricane of Cloud Services




Future Service Oriented Applications which depend on a mix of Services delivered from the Clouds must be managed with unprecedented agility and discipline.  Development managers ought not lose sight of the fact that the Clouds from which Services are offered up for consumption will form in a highly competitive atmosphere.  The unwary programmer might not perceive, in the gentle rolling of Clouds upon each other, the coming fury.  When external Services are commodities, their availability, performance, and characteristics can change rapidly. They must be closely monitored.  When the Clouds become stormy, organizations must be ready to quickly reassemble their applications in calmer skies.  Putting good governance practice in place now will assure that composite applications can weather any storm.

The ability of application developers to sit on the shoulders of earlier programmers, to reach new heights without reinvention, is a foundational principle of modern software development.  Componentized programs makes it easier to reuse inherited code. When components are Services, the programmer need only consume the output of existing code, and need not reuse the code itself. A promise of Service Oriented Architecture is that richer business applications can be built at lower cost by consuming Services that are available from many sources.  A software development team does not have to forge every component of an application.  Their composite applications can use Services that are delivered from inter-operating Cloud platforms, taking advantage of work that has already been done.

When composite applications are built using Services from many providers, however, orchestration of Services requires constant monitoring.  No longer based on static code, locked in the protective vault of the data center, dynamic Service Oriented applications are subject to the vagaries of the marketplace.  A Cloud platform can go out of business.  A Service can be rewritten that breaks both the Service delivery contract and the running application.  Performance can go into free fall.  These eventualities can happen over night.  They need not spell disaster if the composite application has been built with portability and continuity of operation in mind.

Portability seems like a term from another time.  The debate, a decade ago, was whether applications should be built with portability in mind, allowing a program to be written once, but run anywhere.  Sun offered java as the mechanism for writing portable applications.  The alternative was that software components could be written in any proprietary way—making use of any special resources unique to their environments—as long as their functionality could be consumed via standard interfaces.  Microsoft offered up SOAP as a messaging standard to enable such interoperability.  Sharing Services can have rich rewards. The notion of portability, however, is reborn when one evaluates the risk potential of interoperability.  Because unmitigated trust for the Service provider is a bad strategy, a means to pack up the application and head for another Cloud—that is, a way that Cloud applications can be made portable—becomes important again. 

In a mature cloud computing environment, composite applications must be built with a level of discipline that is uncommon among in-house business software developers today. Service delivery managers must review their system development life cycles and governance procedures without delay to assure that their development efforts can survive the coming hurricane of interoperating Cloud Services.  Deployment managers must assure that business applications are packaged as if for commercial distribution.

____________________

Raijin, the Japanese god of thunder. The image is an extract from "Fūjin-raijin-zu" by Tawaraya Sōtatsu, a work in the collection of the Kyoto National Museum


"Ministratio Ecnephias" is Latin for a storm of business services.  Ecnephias references a hurricane which was thought to arise from two clouds clashing.  Ministratio references ministerial services.

2 comments:

Hao Wang said...

Good article and timely for our discussion around Cloud Computing. SOA fundamentally changed the picture of software development. Cloud computing add one more dimension to it. The governance of services in the Cloud is an important factor for success.

Practically, I have been favoring RESTful web services over SOAP protocol because it open the composite services to the Cloud a bit more.

Last thing, it seems we are thinking of the same topics. Pleasure to be the first follower of this blog.

robertvitello said...

It seems to me that we must be ready to use both architectural styles: SOA and RESTful Services. (As a Ruby programmer, I first thought that REST was the only way to go. But even Ruby supports both.) The practical reality is that we should seek to consume the Services that meet our requirements, even if this results in a mix. My only condition is that access be defined by an open standard. Hence, I deprecate Services which are invoked with proprietary messaging protocols.