Cloudstreams: The Next Cloud Integration Challenge
In his new post Benoit Lheureux writes that cloud computing is more than just
... massive proliferation and promiscuous consumption of Cloud services. Innovation. Mashups. Cloud sourcing...
In his opinion:
Cloud services consumption delivers to business it is still very technical, fraught with non-trivial regulatory and compliance issues, and - at the end of the day - at least some companies are going to want and need help (think: services).
As a result:
Governance. Integration. Security. Just a few of the issues companies must address when consuming Cloud services (not the easier browser-based services, the more sophisticated API-based Cloud services.
According to Daryl C. Plummer solving the cloud service integration problem requires cloud services brokerage, which:
... represents the single biggest revenue growth opportunity in cloud computing and that it is built on markets totaling near one trillion dollars in IT spend.
To better describe the issue Plummer introduces a new term - Cloudstreams, which:
... focuses on the integration, governance, and security impact points... The cloud has made the need for integrating between services... more evident than ever. Companies want to connect from on-premises apps to cloud services and from cloud services to cloud services. And, all of these connections need to be secure and governed for performance. In short, what they want are flexible, well-defined, integrations of services at the API level using policies to orchestrate the data, messages, and invocations associated with those services. That is a Cloudstream.
According to Plummer, SOA vendors have created:
... a dizzying array of terminology for basically the same things. They talk about SOA gateways and XML appliances and providing security or management for SOA and now for the cloud. The products are delivered as on-premises appliances, software, or even cloud services... The reason for all these different terms is that the customers these companies serve all talk about their problems in different ways, even though they mostly face the same issues. These customers want to talk from internal systems to external services (SOA or cloud) and they want to manage, secure, integrate, and generally enhance the access they get to those services. The problem is, they all talk at the purely technical level when specifying their need; and, the vendors come back with similar technical language to address those needs... So, unless you get down into the details, it is hard to understand why you would choose one of these vendors over another.
In Plummer’s opinion, a new term will allow to "up-level" discussion of service integration for both cloud and SOA. Instead of considering support for specific APIs/technologies it considers streams of information (with its policies and key metrics) that can be opened and closed between cloud-based services and between cloud-base services and companies:
This is the only way we will ever get to a consistent way to describe the interactions between cloud services. This is about interoperability for the rest of us, not just the engineering geniuses in the basement... The idea of packaging up cloud integrations (CIs), as Cloudstreams, is one which opens the gates (pun intended) to many streams of opportunities for the vendors who do this type of intermediation. As long as they remember that the cloud (and by association, SOA) should be about abstracting away from the technical details of how you interact with services and providing a way to think of those interactions as part of the business use of a solution, there will be a place for Cloudstreams. Let’s focus on the resulting integration that is part of the solution, not just on the appliance or the specific technology assertions that have to be upheld.
Reacting to Plummer’s post, K. Scott Morrison notes that:
The problem Daryl identifies is that so many companies... lead with technology to solve what is fundamentally a business problem. Tech is a game of detail... But when faced with seemingly endless lists of features, most customers have a hard time distinguishing between this vendor and that. This one has Kerberos according the WS-Security Kerberos Token Profile - but that one has an extra cipher suite for SSL. Comparing feature lists alone, it’s natural to loose sight of the fact that the real problem to be solved was simple integration with Salesforce.com. Daryl intends Cloudstream to up level the integration discussion, but not at the cost of loosing the configuration details that the techies may ultimately need.
One of the reasons for SOA demise was an attempt to solve business problems with technology, vendor-driven ones. Let’s hope that a more holistic approach with the Cloudstream will be able to escape this trap.
Daryl I am not convinced that one needs to have a separate appliance of service gateway or brokerage to deliver improved governance in any metered service integration.
Costicity.com – A Blueprint for Cloud Service Metering & Monitoring
I would prefer to see work done on standardization of contractual service exchanges. Here is a starting point for such discussions.
Metering in the Cloud: Visualizations Part 1
We see activity based costing plus metering (ABC/M) providing an universal solution that can be applied at high level service interactions as well as within the various containers and runtimes at the programming language level. This is markable different that proposed solutions you've listed. A bigger vision with a much greater (potential) impact on the software industry.