Blog Post

Do Enterprises Need a Toll Road to the Cloud?

iStock_000007931678SmallThe adoption of cloud services on the part of enterprise IT is still in the nascent stage. Enterprise IT departments continue to see cloud services as more appropriate for applications being written primarily by the Web 2.0 crowd –- if you want to build a new application on Python, Ruby or Perl, then cloud services are for you — but not for those that, say, house the financials of a large corporation or store retail inventory data.  If cloud services are going to move past their current stage, there needs to be a way for enterprises to use them in a manner that guarantees both network performance and security. That could require the emergence a service provider that aggregates dedicated connections to each of the public cloud providers.

Back in the Web 1.0 days, if an enterprise wanted to connect over the Internet, it paid to install a dedicated leased line network connection to a service provider (sometimes called an extranet connection) that was secure and had predictable performance.  If the enterprise had enough of these extranet connections to render them unwieldy to manage or they were housed in multiple distant geographies, it could opt to pay to install a private network connection to a co-location facility, then pay for co-location space and finally, pay to connect to multiple extranet partners with intra-facility LAN connections. Over the past decade, of course, the public Internet has increased in speed and reliability and a number of these private network connections have been replaced by secure virtual private network (VPN) connections.

But cloud services providers don’t currently offer 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.  Also, while an industrious enterprise could pay to install a private connection to a co-location facility where cloud services providers are also co-located, there’s no standard product (at least not that I’m aware of) that allows for a paid intra-facility LAN connection between the enterprise and the public cloud.  In other words, an enterprise cannot pay to install a dedicated link to a public cloud and get the network performance and security it’s so far been accustomed to getting.

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. In order to make network connectivity to the toll road cost-effective for an enterprise, CloudNAP would offer POPs (point-of-presence) in multiple geographies.  Each CloudNAP POP would have dedicated leased lines to the networks of the major cloud services providers such as Amazon Web Services, Microsoft Azure, Google AppEngine, the Rackspace Cloud, etc.

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.

What do you think?  Would a private toll road between the enterprise and the public cloud lead to a faster enterprise IT adoption?

26 Responses to “Do Enterprises Need a Toll Road to the Cloud?”

  1. Very interesting article. In the financial industry, in order to move trading related application to the cloud, there must be a way to get market data into/out of the application with as little latency as possible. For most serious applications, sending data over the internet is simply not an option.

  2. The Local Service Provider who owns the Last Mile and the MPLS functionality, is the key to this Cloud Aggregator service. What is missing is the Major Cloud Service Providers like Google do not allow direct or dedicated Fiber links to their data centers. Google has a development effort under way (or did) called OpenEdge that would have them provide a Local Telco/SP with a Cache Server with a link back to their centers that would effectively position the Telco/SP as a CloudNAP.
    I would imagine Microsoft and Amazon, Limelight, EdgeCast and other Content Delivery Networks (CDN) would eventually come around to the same approach-Local Data Center (Cloud) with Last Mile Connections to SMB and Enterprises.
    The Local Telco/SP has an incentive to provide content over their networks and generate revenues other then their existing wired links.

    Jim A.

  3. Allan,
    Nice post. Many of the comments make good points, but most of them show a disturbing lack of understanding of basic internet network traffic flow.

    Sure, anyone can buy a fat pipe to an ISP, but there are several reasons it’s not enterprise-ready. The first, as you point out, the QoS peering problem hasn’t been solved. I wrote a chapter in a book about cross-provider IP QoS in 1998 but the problem is still here today, not because we don’t have the technology, but because game theory predicts that there is no incentive for ISPs to collaborate to implement it.

    The second reason a fat ISP pipe doesn’t work is called hot potato routing. Basically, this says that if you use an ISP connection instead of a dedicated line, you don’t have predictability of the return path for a packet. A major reason leased lines are still running branch offices for big companies is the predictability problem.

    The third reason a fat ISP pipe is what you could call the clean pipe problem. A leased line doesn’t have problems with inappropriate traffic (hacking, VOIP, pr0n)wasting space on it, but an internet connection does. A lot of companies backhaul internet traffic to their own data centers in order to provide web filtering and malware protection. If they’re already doing this, are they going to want to put datacenter to datacenter traffic on the “dirty internet?” No way.

    The fourth reason is visibility. You can look at your netflow logs a lot more easily on a dedicated line than you can on a “dirty internet” pipe – and you can do it at both ends.

    The fifth reason is control – end to end control matters a lot if you want to differentiate between backup replication (of data to the cloud) vs live transactions, for instance.

    But maybe I’m biased. I was planning to start a CloudNAP-like company about a year ago. I dug into the space and instead decided that Blue Coat Systems (where I’m VP Technology) already had Application Delivery Netowrking – the elements of visibility, acceleration, and control that enterprises need for all networks, including cloud-connected ones. This is not a company pitch – i put my money where my mouth is by joining!

    That said, if a CloudNAP-type business existed, it would be a no-brainer for enterprises to plug their ADN boxes into it, or for the CloudNAP to offer ADN as built in part of the service.

    -Dave Asprey

  4. Andy Johnson

    Interesting article Allan. As the enterprise takes to the ‘cloud’ I think there will be a need for a simple mechanism for switching between cloud providers. Many enterprises will take a single provider to start with but as usage ramps there is no doubt that there will be a need to take on more for resilency or for alternate services. Switching between them will create issues on connectivity with network perfromance differing between them over the same pipe. My thinking is to solve the problem from the peering model, allowing people to direct connect to differing clouds in the same way as the proven IX model. This will give guaranteed bandwidth at layer 2, solving the security, flexibility and performance issues in one hit.

    • Agreed – other than secure and reliable network connectivity, the enterprise needs a way for data stored in the cloud to be portable between clouds. That lack of portability is an important concern for enterprise IT – but that is a different blog post :)

  5. @Ernest Nova – you’re only thinking about network performance and SLAs, not about the security aspect here and I don’t see the natural progression of Tier1 offerings helping either the performance or security aspect. Where can I buy a connection from my enterprise to a specific destination across the Internet (read across multiple Tier1/2 providers) with end-to-end QoS today? That has been “progressing” along with the Tier1/2 providers for over a decade…. We’re in absolute agreement on MPLS being yet another version of 0 CIR Frame Relay.

    I’m contending that if and when a CIO sees a cloud service that delivers a dramatic ROI in terms of storage or compute then this service will become necessary. But, I’ll concede that if this takes another decade to come about then maybe the Tier1/2 providers will have figured out a way to give the enterprise connectivity and security guarantees. I still am not sure if the cloud providers will offer their side of the network connectivity service though.

    • >>not about the security aspect here<<

      Which security are you talking about? Once data is encrypted does it matter if it going on dedicated line or a shared line?

    • Cloud Security. If one uses the Local Telco/SP to be the CloudNAP, with its Last Mile and MPLS links the customer base would feel far more secure then if this services was offered via a new 3rd party (not local). When one considers that the Phone companies (ISP)customers have relied on and had felt secure with it maintaining and securing (for over 50 Years) all their Personal COmmunications (Phone #’s, access to all its Calls, Home Address, SS#, EMail Address and where it has called and to who it communicates), they should be very secure with the Telco/SP maintaining their privacy.
      In addition with the local entity providing and added layer of encryption of the data (in Center and over the MPLS Net) they will be far safer.

      Jim A.

  6. Allan,

    I wouldn’t comment on US domestic telecom market, but here in AUS you can easily purchase anything up to 10G of dedicated Ethernet connectivity between very many locations in Metro and practically anywhere in CBD of all major cities, at *very* reasonable price points. Inter-city is significantly more expensive, but is also readily available at the rates up to 10Gbps (yes, dedicated Ethernet, just as if it was your own LAN).

    For the US market, there’s a nice little web site: , which can help to see if there are Metro Ethernet services available in your area.

      • knujlla

        If you subscribe to the fact that congestion is on the edge and not per se the core, does it matter whether it is AWS today or Azure tomorrow. These large cloud providers have access to big enough pipes and if not then to support their burgeoning business, they will.

        Over-the-top has worked quite well for many other delivery models. The only issue was upstream – if that is ‘fixed’ then, OTT continues to be a viable strategy rather than the vertical integration suggested here.

        That said, Google Global Cache within AT&T POPs is a reality. So some kind of, say, an Azure Premium service where Microsoft ties up with AT&T/VZ/T-Mobile/Sprint could be viable. Telecoms are eager to monetize their networks – Amazon Kindle and eBooks over Sprint network and Smart grid networking over all the wireless networks are two examples that telecoms are ready to make a deal.

  7. What would the next step be – for these ISPs/NAP Providers to start providing cloud services? Or acquire one of the cloud service providers?

    The argument against this might be based on history – vertical integration by ISPs has not been as successful as they had wanted. However, the ISPs have also worried about becoming just “pipe providers”, so such acquisitions might not be as far fetched as we might think. Preferred provider partnerships might be a first step…

  8. Ernest Nova

    Look, if you are big cloud provider you likely have fat pipes to 3 or 4 major ISPs. If you are a large enterprise that is concerned with predictability and reliability, you also have fat pipes to 2 or more large ISPs. Most large companies will find a match -i.e a direct path between their corporate internet connections and that of their cloud providers.

    The burning issue is not that of the network performance between the 2 points, it is the visibility into the cloud service providers operation when things are not working, as well as geographical diversity of their data centers. In case of the major outages of the last year – the dig has been that the service providers did not provide enough visibility into outage status.

    Security itself does not need a dedicated connection – you can encrypt away between your intranet and your servers in the cloud.

    • But the problem here is that just because the enterprise is connected to AT&T and Amazon is connected to AT&T that does not mean that the enterprise has a path through the AT&T network that is secure or has any resemblance of performance guarantees. My connection to AT&T may be in a different geography (or on a different continent) to where Amazon connects. And is that the e-commerce site or AWS – the cloud service I want where I desire the connection? You can use traceroute to solve some of these questions at a rudimentary level but I believe that the network connectivity solutions on the market today are insufficient to solve the enterprise IT cloud adoption issues.

      • Ernest Nova

        Tier 1 ISP Backbones are really not where the issues are and if clouds take off in a big way all ISPs will make sure that they have rich connectivity to them and will compete on that basis. Many of the cloud data centers, have several fiber optic providers, and any one of them could set up a Equinix like network there as a natural growth of their presence.

        As a business opportunity, this new “network” is ultimately a losing proposition – natural progression of existing player offerings will take care of any perceived issues.

        Previously, MPLS has been sold as FUD to people who used to have Frame Relay and ATM backbones and were forced to transition to Internet backbones based on economics. Many of them are just as happy now with software VPNs over their ISP backbone.

        In any event, all this presupposes that network performance is an issue. It may be for some isolated cases but I have not seen that show up in the top reasons holding back cloud adoption. In other words, no CIO will pull out a checkbook to buy another connection till it becomes an demonstrable issue for them.

        The intermediaries in this layering business get squeezed out. There are only so many ways to insert thin slices of value in the stack where everyone is looking to consolidate.

  9. Realistically, I just don’t really see this as an issue. The reliability of the Internet is not the barrier to entry for cloud services. The concern about cloud services is primarily a loss of control over data, and thusly a serious concern about security. With PCI, HIPAA, and to a lesser extent SOX compliancy concerns, these are the true barriers to cloud adoption.

    The other thing to consider is that for most of the larger enterprises that might benefit significantly from cloud adoption in terms of infrastructure costs, etc, they already have large capital investments in infrastructure that would seem like a significant about-face to start moving significant portions of their IT infrastructure to the cloud. Not to mention, the majority of the applications that most enterprises rely on (billing, ERP, etc) have not been rewritten for the cloud. The more I read blogs like this, the more I realize that the hype system of the Internet and the companies involved in internet-facing services (the Twitter’s, Facebook’s, Google’s, etc) completely miss what the enterprise needs and wants.

    If you’re a CIO, are you likely to bet on an Internet company that does business over the web and email, or are you likely to go throw your dollars in with HP, Microsoft, Cisco, EMC, Oracle, etc, who all have representatives pounding on your door and have an office a couple miles from yours that shows they’re likely to be here tomorrow? People offering cloud infrastructure are going to have invest in more than datacenters to start building confidence in the enterprise.

    • It’s not about reliability of the Internet. CloudNAP would be primarily required to address bandwidth and latency limitations of the public Internet.

      @Allan – thanks for the great post!

    • I think we agree more than you think – especially about enterprise adoption of cloud applications. In this post, however, I wanted to focus on the lower-layer connectivity issues.

      Besides network performance and reliability, the two most often cited reasons I hear about why the enterprise is not adopting the cloud is 1) data portability (between the enterprise and clouds) and 2) security and logging around compliance.

    • Elastra is application infrastructure software, CloudSwitch is also a software appliance and enStratus is software that helps you manage your cloud deployments. I don’t think that any of these provide the type of services that I am describing with the CloudNAP concept, but maybe I am missing something here.

      • I agree with Allan, managing resources on multiple clouds is different than providing secure reliable connectivity b/w enterprise internal network and cloud. This is a real need for distributed applications and we recently had to use open source tools to seamless provide connectivity b/w enterprise resources and resources in the cloud. More information about the customer needs, setup, gaps in current offerings can be found at . Whether the existing providers provide this service or not is a different issue, however, someone has to provide these services. For some customers secure network connectivity over internet would be sufficient, whereas, for some other customers we need SLAs around network (bandwidth, latency, etc.) in addition to just secure connectivity. Companies like Akamai provides conceptually similar service for web applications using their own network nodes for routing traffic. For clouds to be successful in the enterprise world we need better solutions for connecting internal data-centers and clouds. For efficient connectivity services the whole network stack from hardware routers to networking software needs to catch up with the advances of cloud computing.