If public, private, hybrid, cumulus, stratus wasn’t enough, the ‘Inter-Cloud’ concept came up again at the Cloud Connect gathering in San Jose last week. According to the Wikipedia entry, it was first introduced in 2007 by Kevin Kelly, both Lori MacVittie and Greg Ness wrote about the Intercloud last June and many reference James Urquhart in bringing it to everyone’s attention. Since there is no real interoperability between clouds, what happens when one cloud instance wants to reference a service in another cloud? Enter the Inter-Cloud. As with most things related to cloud computing, there has been lots of debate about exactly what it is, what it’s supposed to do and when it’s time will come.
In the ‘Infrastructure Interoperability in a Cloudy World’ session at Cloud Connect, the Inter-Cloud was referenced as the ‘transition point’ when applications in a particular cloud need to move. Application mobility comes into play with Cloud Balancing, Cloud Bursting, disaster recovery, sensitive data in private/application in public and any other scenario where application fluidity is desired and/or required. An Inter-Cloud is, in essence, a mesh of different cloud infrastructures governed by standards that allow them to interoperate. As ISPs were building out their own private backbones in the 1990’s, the Internet needed a way to connect all the autonomous systems to exchange traffic. The Network Access Points (NAPs) and Metropolitan Area Ethernets (now Exchange – MAE East/MAE West/etc) became today’s Internet Exchange Points (IXP). Granted, the agreed standard for interoperability, TCP/IP and specifically BGP, made that possible and we’re still waiting on something like that for the cloud; plus we’re now dealing with huge chunks of data (images, systems, etc) rather than simple email or light web browsing. I would imagine that the major cloud providers already have connections the major peering points and someday there just might be the Metro Area Clouds (MAC West, MAC East, MAC Central) and other cloud peering locations for application mobility. Maybe cloud providers with similar infrastructures (running a particular hypervisor on certain hardware with specific services) will start with private peering, like the ISPs of yore.
The reality is that it probably won’t happen that way since clouds are already part of the internet, the needs of the cloud are different and an agreed method is far from completion. It is still interesting to envision though. I also must admit, I had completely forgotten about the Inter-Cloud and you hear me calling it the ‘Intra-Cloud’ in this interview with Lori at Cloud Connect. Incidentally, it’s fun to read articles from 1999 talking about the Internet’s ‘early days’ of ISP Peering and those from today on how it has changed over the years.
ps
Related:
- Now is the conference of our discontent…
- Cloud Federation and the Intercloud
- The Inter-Cloud and The Cloud of Clouds
- Pursuit of the Intercloud Is Premature
- Improving service delivery in cloud computing
- Blueprint for the Intercloud - Protocols and Formats for Cloud Computing Interoperability
- The Three Reasons Hybrid Clouds Will Dominate
- Intercloud: The Evolution of Global Application Delivery
- The Intercloud makes Networks Sexy Again
- Here Comes the Intercloud
- The Inter-Cloud and internet analogies
Technorati Tags: MacVittie, F5, infrastructure 2.0, integration, collaboration, standards, cloud connect, Pete Silva, F5, security, application security, network security, business, education, technology, application delivery, intercloud, cloud, greg Ness, context-aware, infrastructure 2.0, automation, context, web, internet, blog
No comments:
Post a Comment