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.
/Hoff
Every Enterprise will want to connect to different things differently. Many today still don't understand MPLS or Optical Ethernet. Some love using IPSec over the Internet (i.e. your "IP transit") for everything, from simple ptp configs to crazy DMVPN or whatnot configs. Some do some horrible combination of these three key technologies (MPLS, OE, Internet VPN) or similar antiquated ones.
Since every Enterprise is different, it is unlikely to converge to a single or multiple providers that claim connectivity to a central "NAP" (as you call it). More likely, providers are just going to scale their "used-to-be-called-`best effort'" bandwidth in the same way that they've been scaling it for years now. They'll tell Enterprises "traffic is secured to X standard via this path costing you Y dollars upfront and Z dollars every month". Quality-of-Service, or Guaranteed Bandwidth, will also be sold, but in much smaller quantities.
Those who build locally for local cloud services may be able to reap some benefits, but this is usually not contractually obligated past normal SLA ranges that are typically found in provider agreements of either the near-best-effort IP transit variety, or the classically over-expensive QoS/GB services. Whether or not one can fail a certain cluster dependent on VLWHDBs (very large, write-heavy databases) across a metropolitan city is a very difficult question to answer. Usually it's best to guarantee such activities while in the same building, or across the street.
Even still, this only shows that some Enterprise apps are wildly different and have different needs. The ones moving into the cloud are less likely to require any strict SLA requirements — thus, I do also see the concept of a CloudNAP to be dead via every angle. Do I see service providers pushing MPLS-VPN/GB/QoS solutions over IP transit or Optical Ethernet because of the desire for many Enterprises to move more apps into the Cloud? Yes, but it's not going to be a single MFN POP like the old days. There's more competition, more fiber, and more "network everything" in our world today.
Thanks for the thoughts and comments. I agree that monetizing the interconnection between the enterprise and the cloud service providers may seem like a thin value proposition, although there are many companies doing this same type of service without the focus on a specific set of service providers (InterNAP and Terremark come to mind).
With that said, if the enterprise can be provided with a secure and high performing connection to the cloud using a VPN, MPLS-VPN, GigE or something similar at layer 2, then that could solve the problem. I can't seem to find that product that connects the enterprise to the cloud in the marketplace today.
Allan:
CohesiveF/T's VPN Cubed.
/Hoff
Cool – VPN Cubed looks like a start although it only supports EC2 and does not appear to have any performance or quality-of-service capabilities as it rides over the core Internet IP infrastructure.
@Allan Leinwand
VPN-Cubed supports more than just EC2 but
I'm interested in your comment regarding performance and QoS over the "core Internet IP infrastructure" <– can you please tell me what that is, exactly?
You mean at peering points? At Interconnects? Between providers? Where is this mythical core of which you speak?
In terms of QoS/Performance/end-to-end encryption…that's what IPv6 is for. "Products" aren't going to give you this in an open/standard implementation, open/standard "protocols" will.
/Hoff
@Hoff
What I mean is that just because you can setup a VPN from an enterprise to an EC2 instance that does not help the underlying problem on xSP IP networks (the mythical core, so to speak :). VPNs will suffer the same performance problems as the networks on which they traverse – and that is often multiple networks and multiple public peering points.
IPv6 is not going to solve the performance issues on the Internet. It will solve the addressing problems and give xSP providers a way to implement QoS but it will not guarantee QoS end-to-end between providers.
But, back to the point on my original post on GigaOm – I think that enterprise IT wants a secure and reliable (== guaranteed performance in terms of latency, packet-loss and jitter) way to reach the cloud. This is the model that the enterprise has used to reach other outsourced services in the past and one they can wrap their heads around for the cloud. I grant you that there are other technical ways of doing this, it is just that enterprise IT is used to buying services in a different package. I was focusing on giving the enterprise what it wants to see in order for them to accelerate their use of the cloud.
@Allan Leinwand
Note on VPN: VPN over IP transit or over other networks can avoid performance problems by utilizing Traffic Engineering (TE), whether MPLS-TE (or other constrained-based / policy routing) or Smart BGP. Obviously, perhaps the best way is to just establish a peering policy (including performance policy and performance event response/repair) with the Cloud provider directly. You mentioned Internap and Terremark — isn't this exactly what they are doing?
Note on IPv6: Yeah, I agree. I wonder what Hoff was referring to?
Note on GigaOm: As I said, "I see service providers pushing MPLS-VPN/GB/QoS solutions over IP transit or Optical Ethernet because of the desire for many Enterprises to move more apps into the Cloud". However, I think this almost has to be existing providers. I don't see room for a newcomer in this space, but please correct me if I'm wrong. From my perspective (early opinion on the matter), VPN-Cubed just doesn't understand IP (as the provider slang/slander would say it).
@Andre Gironda
Agreed on VPN – but would it not be easier for there to be a service where the enterprise could get TE and symmetrical BGP routing done for them? Yes, INAP and Terremark are close to this but not focused on connectivity to the cloud and traversing cloud protocols only.
@Allan
Note that the below paragraph is simply playing devil's advocate and may or may not be a full-on strawman argument. In any case, I'm sure I'd prefer it be addressed.
So why focus on cloud connectivity and cloud protocols? I'm kind of a Jericho Forum follower, so please don't even try to use the word "firewall" or "stateful packet filtering" around me. Save it for your white papers. VPN works fine into and out of any network, cloud or not. Why reinvent the wheel for cloud? If anything, a single (or even a handful) cloud provider would suffer from connectivity issues and network diversity problems.
What? A lack of a standard product for delivering private networks to cloud providers? This is absolute non-sense. I know this because my company relies on exactly such a product that is provided by multiple transport providers (Verizon, ATT, Sprint, twTelecom, Level3, etc). I sense a blog post coming real soon. SLAs and QoS are tied to the deliver of customer's private networks into our datacenter.