when something goes wrong? I understand the reduced risk in the "diversification", but at some point your stuff is in the cloud, but you have no idea where. That may be an unsettling thought.
I do understand however the parallel to the banking system; you have no idea where your dollars are either. Maybe federal regulation would be required to allow authorities to step in and not let creditors hold your data hostage to get paid.
This guest BriefingsDirect post comes courtesy of Jason Bloomberg, managing partner at ZapThink.
By Jason Bloomberg
The essence of cloud computing—what makes a cloud, well, cloudy—is the fact it’s an 
abstraction. The cloud hides underlying complexity while presenting a simplified interface to the consumer. Of course, abstractions are nothing new in the world of IT: compiled languages, graphical user interfaces, and SOA-based Business Services are all examples of abstractions. After all, everything we’re doing in IT boils down to zeroes and ones in the end. Layers of abstraction are how we deal with this never-ending stream of bits.
The business service abstraction in the SOA context provides flexible, loosely coupled access to application functionality and data. The cloud abstraction, on the other hand, delivers a shared pool of configurable computing resources of various types (processors, storage, etc.) that can be dynamically and automatically provisioned and released. The two approaches solve different problems, but nevertheless both simplify the underlying technical complexity while providing greater agility to the consumer of the respective abstractions.
It doesn’t matter how resilient your provider’s infrastructure is if they go out of business, or a denial of service attack takes them off the Internet.
Another critical benefit of both abstractions is increased fault tolerance. If something goes wrong beneath the abstraction, then it should be possible (at least in theory) to fail over to a backup or route around the problem without adversely impacting the consumer. In the case of business services, the intermediary (typically an ESB or XML appliance) handles this routing, while the underlying cloud provider infrastructure handles failover within the cloud.
That is, unless the problem is with the cloud provider itself. It doesn’t matter how resilient your provider’s infrastructure is if they go out of business, or a denial of service attack takes them off the Internet. Think of cloud providers as baskets. Do you really want to put all of your eggs in just one?
Enter cloud brokering
Cloud brokering is the capability that addresses this eggs-in-one-basket problem. A cloud broker provides cloud service intermediation, aggregation, and arbitrage across a set of cloud providers. The need for such cloud brokers, of course, is not lost on the community of cloud startups. Today, if there’s even a hint of a niche you’ll find several entrepreneurs jumping on it, and the nascent cloud broker market is no different. However, there is a twist to the current state of the cloud broker market: as far as I can tell, all the players in this space today include cloud brokering as an extension of their existing business model, rather than a pure play model in its own right.
In fact, most of the vendors offering cloud brokering are in the cloud management space. RightScale and Kaavo, for example, provide template-based cloud deployment. Build the template, and the tool will deploy your fully configured cloud instance in any of a number of cloud environments by following the template. CloudSwitch takes the template idea down a few notches to layer two of the OSI stack, which means your cloud instances will be identical down to the IP addresses and even the MAC addresses, independent of the cloud environment. A fourth player worth mentioning is enStratus, who touts cloud independence as part of cloud governance.
All the players in this space today include cloud brokering as an extension of their existing business model, rather than a pure play model in its own right.
There is another angle on the cloud brokering marketplace, however: as an extension of the cloud storage/sync market. This niche is already quite crowded, with players like Dropbox, Jungle Disk, Box.net, Wuala, and several more. A closely related market niche is the cloud backup market, featuring vendors like Mozy, Backblaze, Carbonite, CrashPlan, and Livedrive, to name a few. It’s not clear, however, if any of these vendors support cloud brokering. Instead, they all rely upon a single underlying cloud environment for each of their offerings. The inherent fault tolerance of each vendor’s chosen cloud infrastructure may be sufficient for many users, especially in the consumer and small business segments, but enterprises may require a higher degree of resilience.
One vendor, however, has apparently carved out a niche for themselves: Oxygen cloud. Oxygen cloud focuses on cloud-based sync and shared storage, but they have also taken the extra step to build cloud brokering into their offering. As a result, customers who want the benefits of sync and storage in the cloud without having to rely on a particular cloud provider have few if any options other than Oxygen cloud.
The ZapThink take
The ability to select among several public clouds is only one benefit of cloud brokering. It also 
supports the ability for an organization to move application instances or data between private and public clouds. In other words, cloud brokering is at the heart of dynamic hybrid clouds.
When we talk about the various cloud deployment models—public, private, community, and hybrid—it’s the hybrid model that elicits the most head scratching. People wonder under what circumstances would it ever be worth the trouble to mix private and public clouds together. And they have a point: hybrid clouds sound like a huge hassle. Without cloud brokering, managing a hybrid cloud may be more trouble than it’s worth.
Cloud brokering, however, abstracts out the deployment model altogether, creating what we might even call a “cloud of clouds.” From the perspective of the consumer, all clouds might as well be hybrid clouds, because the decision whether to leverage on-premise or off-premise resources is simply part of the dynamic provisioning benefit of the cloud of clouds. The notion of a cloud of clouds that brokering enables, however, is a temporary phenomenon. Today we require visibility into the selection of individual cloud providers. Tomorrow, the brokering-based cloud of clouds will simply be the cloud.
ZapThink has no business relationship with any of the vendors mentioned in this ZapFlash. We’re simply calling ‘em like we see ‘em.
This guest BriefingsDirect post comes courtesy of Jason Bloomberg, managing partner at ZapThink.
SPECIAL PARTNER OFFER
SOA and EA Training, Certification,
and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
You may also be interested in:
