Set the wayback machine for 1996 – the year of the Intranet. Sometimes I feel like we have gone back in time (“Life on Mars” fans, anyone? Bummed that it was cancelled, but I digress…). Back then I wrote a research note titled “The Top 10 Intranet myths”. The Internet wave had crested and companies were atwitter about the use of the concepts and technologies internally. The term intranet (which still is in popular use) emerged to describe the phenomenon and the resulting hype was deafening. Kind of like today’s hype over ‘private clouds’, which are analogous to intranets in that they are supposed to mean some kind of use of public cloud concepts and technologies internally.
In the 1996 note, myth number 10 was
“The existence of ‘the intranet.’ While ‘the Internet’ certainly exists, use of the term "the intranet" is misleading and indicative of the level of hype the term has generated. In fact, by YE96, we would not be surprised to see some well-meaning person write, "With the success of corporate intranets, we may see them connected someday." Presumably into “the Internet”.
I wrote that somewhat tongue in cheek. I don’t think that it ever happened, but an analogy is happening today.
A few weeks ago, Cisco’s James Urquart told me about their cloud strategy and use of a term ‘the inter-cloud” as the evolution of private clouds connected together. My mind flashed back to 1996. While doing my daily skim of the interblogs today, I came across A Hitchhiker’s Guide to the Inter-cloud and the flashback recurred.
I do not mean to diss James or Cisco – I believe they are indeed, well meaning, and indicative of a view of cloud computing that evolves from the infrastructure/data center perspective. And it is yet another example of why terminology matters and why we talk about there being one cloud ( a euphemism for an abstraction ) and frown upon use of “clouds”, in the plural sense. The world of cloud computing has become so cloudy and the terms are becoming so confusing that I have to wonder if we will ever get past it.
Maybe if I fast forward to the year 2020. At least my vision would be perfect.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
I think you misunderstand our use of the term “Inter-Cloud”; we use it in a way that is completely parallel to the term “internet”, not “intranet”. Let me break it down for you:
– Today, people are creating individual online services that can be accessed “at scale” over a network on an on-demand fashion. These are “clouds”
– The world of public clouds is growing rapidly to include many offerings across the SPI model–SaaS, PaaS, and IaaS.
– Enterprises are building (and will continue to build) “private clouds”–clouds in which they maintain control of resource usage and trust boundaries across both internal and external resources from a single management system. Initially private clouds will be made up of almost entirely internal resources. “Private clouds” are a good analogy to “Intranets”, to be sure, and there will be many of them.
– At some point in the not horribly distant future, some service providers will offer “virtual private cloud” services to allow “private clouds” to consume resources in the service provider infrastructure, while maintaining the illusion of being a part of the customer’s private cloud. This is simply extending “intranets” to consume services over the Internet without exposing the content to the general public–kind of like VPN? (Not a perfect analogy, to be sure.)
– In the meantime the set of public cloud services evolves, standardizes, and becomes a more open market. Not all will be virtual private clouds services; there will be other forms of interoperability. These sets of interoperable, interchangable clouds could be thought of as “open clouds”.
– In the early stages, however, there will be relatively tight coupling between the enterprise and any individual public cloud offering chosen; not necessarily lock-in, but the time taken to make a change is still somewhat onerous and involves direct agreements between the customer and the vendors involved. So “open clouds” are not yet the most elastic markets they could be.
– The network technology to enable the linkage of enterprises to all forms of public cloud offerings (not just virtual private clouds) in a way that takes the unique nature of cloud computing and running IT workloads in mind is called “cloud internetworking”.
– The final phase–many years from now–includes the introduction of publicly shared core services–very much like DNS and peering–into the carrier networks that enable a more loosely coupled relationship between customer and cloud vendors. This serves to greatly increase the elasticity of the cloud market, and creates a single public open cloud internetwork–the Inter-Cloud.
To be sure, we are still in the very early stages of envisioning both the nature of the Inter-Cloud, and the technologies required for its formation. We do not, however, confuse “private clouds” with the Inter-Cloud.
Thanks for taking the time to respond and clarify.
I should probably as well.
I didnt think you were confusing private clouds with the internet and i did see that you were using the term “inter-cloud” as analogous to the internet. technically an additional interpretation would be that you are using it like ‘extranet’, and therefore could call it ‘extracloud’.
The possible confusion in what i wrote probably stems from me quoting exactly what i wrote in 1996 starting with ‘the intranet’, . what i meant then to say was that because of the hype around the intranet term, someone would say ‘wow, these intranets are so cool, we could actually connect them together and get something even better’. ‘the intranet’ was a possible name i thought could have been used, but it was meant to mean the internet in any case.
the analogy i saw in your terminology was similar as in that someone might say “wow, these private clouds are so cool, we could actually connect them together and get something even better.
Thanks for your clarification.
You bring up a good point, and I agree that “linking” private clouds at random is bad, bad, bad–especially to some large, untrusted body of such clouds.
That being said, federating *trusted* private clouds can increase the available resource pool for each private cloud that participates. I see now reason not to federate in this way, especially within an organization, or with trusted suppliers, partners, customers, etc..
However, the core concept of “private cloud” is that the owner of said cloud maintains at least the illusion of complete control of all resources “acquired” by said cloud. To open the trust boundaries of a private cloud willy-nilly, allowing it to be linked to a public network would be just as detrimental as opening an Internet to general Internet traffic. Not smart.
A “virtual private cloud” is a service that is targeted at extending private cloud trust boundaries to the provider’s infrastructure. It is not expressly about linking private clouds together in any way.
Good conversation. Thanks for posting your thoughts.
By 1996, there was a mature body of Internet protocols (developed by IETF) with 20-30 years of inter-networking in the DoD/university networks. There is no such CETF – Cloud Engineering Task Force – yet that can help rationalize all these cloud modifiers. So, unlike the “Internet”, I suspect we will have many clouds, not just the “Cloud” or the “Inter-cloud”.
When considering the inter-networking terminology for inter-cloud, perhaps we should look to today’s transport service providers who do have well defined interfaces: user-to-network interface (UNI) and network-to-network interface (NNI). For clouds to seamlessly interact with each other, perhaps user-to-cloud interface (CNI) and cloud-to-cloud interface (CCI) would need to be defined.
Also, like network ACLs that enable segmentation of networks into outside Internet, DMZ, extranet, intranet, etc. one could envision cloud ACLs to enable public and private clouds to interact with each other while maintaining independent trust postures. Cloud ACLs could be policy based and perhaps additionally include Layer-7 constructs (e.g. identity, attributes, application & protocol parameters, environmental variables, …) so that much tighter controls can be implemented when exposing private clouds. Enterprise’s MS Exchange email is a proof point today of exposing intranet resource to Internet – when appropriately configured, Outlook or Entourage client can access Exchange email directly over HTTPS (without the need for corporate VPN tunnels).