Do We Need CloudNAPs? It’s A Virtually Certain Maybe.
Allan Leinwand from GigaOm wrote a really interesting blog the other day titled: “Do Enterprises Need a Toll Road to the Cloud?” in which he suggested that perhaps what is needed to guarantee high performance and high security Cloud connectivity is essentially a middleman that maintains dedicated aggregate connectivity between “…each of the public cloud providers:”
One solution would be for cloud services providers to offer dedicated leased line connections to their clouds. Though for many enterprises the cost of these leased lines over large geographies would be enough to eat into any savings they’d be getting by using the cloud in the first place. Another solution would come in the form of a service provider that aggregated dedicated connections to each of the public cloud providers.
This new provider — let’s call it CloudNAP (Cloud Network Access Point) — would solely be in the business of providing a toll road between the enterprise and the public cloud providers. The business of selling connectivity to the Internet, or transit, is a common ISP offering. The CloudNAP transit service would be different, however, in that it would be focused on delivering connectivity solely between enterprises and cloud services providers and not between enterprises or between clouds.
The CloudNAP network could guarantee performance between the enterprise and the cloud by working with the service providers to enable the use of quality-of-service techniques that are not available over the public Internet such a Multiprotocol Label Switching (MPLS) classes for WAN connections or IEEE 802.1p priorities for LAN connections. Perhaps CloudNAP could even restrict the use of connections to cloud service protocols and services like REST (representational state transfer) or HTTPS (Hypertext Transfer Protocol Secure) -– thus preserving the network for its intended use by the enterprise.
While I have many opinions on multiple points within the article, I’ll focus briefly on just a couple, starting with the boldfaced section (emphasis is mine) above. Specifically, monetizing connectivity between providers as a sole value add seems quite limited in terms of a business model. Furthermore, I really see that this is just another feature of what the emerging class of service brokers will offer.
As to the notion of privatizing transport for the purpose of applying QoS, that’s really just a fancy way of describing private Cloud peering and interconnects on the backside of Public Cloud service providers. The challenge will come when these service providers (with the SP’s directly or brokers) end up managing what amounts to massive numbers of “extranet” connections in current-day parlance; it’s simply taking the overlay architectures of DMZ’s as we know it today and flipping it outward. I’m not going to tackle the issue of Net Neutrality in this piece because, well, I’m on vacation in Hawaii and I want to keep my blood pressure down 😉
The blog mentioned many times about the lack of a “…standard products that allow enterprises to install private network connections (either paid, dedicated leased lines or VPNs) that would provide predictable network performance and security,” but I’d suggest that’s wholly inaccurate — depending upon your definition of a “standard product.”
In the long term the notion of an open market for hybrid Cloud connectivity — the Inter-Cloud — will take form, and much of the evolving work being done with open protocols and those in the works by loose federations of suppliers with common goals and technology underpinnings will emerge.
In the long term do we need CloudNAP’s? No. Will we get something similar by virtue of what we already do today? Probably.