BACKGROUND IMAGE: Maxiphoto/GettyImages

Buyer's Handbook:

Now data center interconnect lets traffic ride the cloud

Get started Bring yourself up to speed with our introductory content.

What cloud data center interconnect technologies can do

Data center interconnect technologies and services now use cloud. Learn how CDCI improves traffic delivery and how to choose the right equipment and services.

The foundation of data center interconnect technologies is what it says on the label: the equipment used to interconnect data centers and move high-volume, high-speed traffic. It is routing or Layer 3 switching, generally either using metro Ethernet or using optical interfaces and either dedicated fiber or wavelength services. Cloud data center interconnect technologies extend the concept to the cloud: CDCI comprises the equipment and services used to connect enterprise data centers to the cloud resources they interact with.

What cloud data center interconnect is

Today, the internet is the default method data centers use to connect to a cloud service. But when an enterprise has back-end traffic flowing back and forth between data centers and strategic as-a-service applications, the internet can become a significant impediment. Internet traffic is subject to greater and more variable latency than private networking, in addition to greater and less predictable packet loss. These problems are amplified by newer microservices architectures. These rely on a complex web of communications among system components. This means a single transaction can sometimes require dozens of round-trip journeys among internal and external components. The result is poor performance for the system as a whole.

To mitigate these problems -- and to tighten security and reduce risk -- the enterprise can choose to implement a form of cloud data center interconnect, in the process taking the internet out of the loop.

How CDCI works

There are two basic models for a CDCI: direct cloud connection and WAN-cloud exchange (WAN-CX). The former is do-it-yourself for most enterprises, although it can be purchased as a service as well. The latter is exclusively acquired as a service.

Direct cloud connection. A direct cloud connection is established by creating a direct, physical network link between the customer network and the cloud service provider (CSP) network. In other words, the enterprise pulls cable from a router or switch port it controls to a port the CSP controls. This requires both the enterprise and the cloud provider to have some infrastructure in the same facility -- called the meet-me. The enterprise may have all its infrastructure in colocation there, or it may have no more than a pair of routers or switches. It may even lease a pair of ports on someone else's equipment, usually its WAN provider, and extend its WAN to those ports. (A pair is recommended because redundancy is a key safeguard against service interruptions.)

Pulling the cables is only part of the proposition. The other part is to contract with the CSP for permission to establish the direct network as well as to obtain the network configuration information necessary to pass traffic. Amazon calls this service Direct Connect; Microsoft calls it ExpressRoute; and Google, IBM, Oracle and other CSPs have their own names for it. Some are configured at network Layer 2 (switched) and some at Layer 3 (routed).

Usually, staff in the meet-me do the actual stringing of cable. The rest of the required configuration can usually be handled by the enterprise itself, although any kind of managed network service provider can handle this task instead.

With the direct connect in place, traffic can now flow reliably, predictably and at high speed, from the enterprise data center to the cloud provider's data center.

WAN-CX. An alternative to a direct cloud connection is the WAN-cloud exchange. A WAN-CX provides a level of abstraction and virtualization. The enterprise sets up a connection to an exchange, directly in a meet-me or by linking the exchange to its WAN -- for example, via MPLS. The exchange is connected to multiple CSPs. To establish a "direct" connection, the enterprise spins up virtual links to CSPs; it still has to get permission and key provisioning information, but there is no dedicated physical link per provider.

The WAN-CX offers three key benefits:

  1. Aggregation. The enterprise can provision a single high-bandwidth pipe to the exchange and slice it and dice it as needed, creating as many smaller links as necessary. This is preferable to, for example, paying for a 1 Gbps port to each CSP, even when only 10 Mbps of traffic is expected to flow.
  2. Ease. If a CSP is on the exchange, a connection can usually be provisioned in minutes -- once permission is arranged with the CSP -- either via a phone call to account support or by provisioning a virtual circuit directly via a portal.
  3. Agility. Virtual connections are easy to tear down as well as to set up. So for any individual CSP, the upfront cost of linking networks is very small. The enterprise can try private connectivity with little per-CSP investment, allowing it to try more potential partners and to experiment with more services and more application architectures.

On the other hand, using a WAN-CX approach does have a few drawbacks, chief among them is that none connects to every CSP, and only the largest customers can exert enough influence to get new ones added. Also, connectivity can cost more through an exchange than a direct cloud connection.

Taxonomy of provider types. Nemertes divides the exchange market into three groups: carrier-based, colocation-based and independent.

CDCI technologies and services offer better options to enterprises when the internet is no longer ideal.

Carrier exchanges tie the exchange to the customer's WAN via the carrier's service cloud. In other words, a carrier exchange requires the enterprise have a WAN from the carrier itself. AT&T NetBond, for example, will connect a customer's MPLS WAN to Amazon or Microsoft, enabling direct flows not just to the data center but to any MPLS-connected site. Costs may be based on the number and size of pipes, or volume of bits moved, and may include site- or distance-related fees on top of other charges.

Colocation exchanges are, as the name implies, tied to specific data centers. The enterprise has to be a customer of the provider, or a customer of a customer. Equinix Cloud Exchange is a good example of a colocation-based exchange. Payment tends to be by physical port and by the number and capacity of virtual circuits. Sometimes providers offer a "buyout" price; enterprises charged that flat monthly fee can create unlimited numbers of virtual circuits.

Independent exchanges -- among them companies like Megaport -- are built in the data centers of multiple colocation providers and interconnected using the provider's own backbone or capacity on multiple peered networks. To connect to the exchange, the enterprise connects to the provider's nearest point of presence or colocates gear there. Fees are based on consumption, but pricing models vary by provider and by location.

Features to look for

In a direct cloud connection, if buying as a service, enterprises should look for the following:

  • the capacity to meet their needs;
  • path redundancy, where in a given pair of link cables, the two cables traverse different paths in the data center;
  • support for configuring the network, whether Layer 2 or Layer 3; and
  • participation in software-defined networking (SDN) control on the enterprise side, possibly in the context of a cloud management platform, where the direct cloud connection can be managed by the SDN controller and the link fully integrated into the service delivery control framework.

On a WAN-CX, IT staff should look for the following:

  • granularity in virtual port speeds down to 10 Mbps;
  • a buy-out option on the exchange link, to allow unlimited virtual circuits;
  • real-time provisioning, de-provisioning and modification of virtual circuits;
  • portal- and API-based monitoring and performance and usage reporting; and
  • SDN integration or an API to allow cloud management platforms, SDN controllers or cloud service brokers to spin up virtual links or tweak their characteristics.

Bottom line

Although the internet has been the backbone of cloud service delivery, it is not always the best choice. Cloud data center interconnect technologies and services offer better options to enterprises when the internet is no longer ideal.

Enterprises connecting their data centers to cloud data centers usually see a dramatic increase in performance and reliability. CDCI can also make cloud costs more predictable and manageable, in addition to reducing threat surfaces.

Whatever strategy you might take in integrating your cloud services, it makes sense to mix and match cloud data center interconnect technologies and service options. If your relationship with your cloud services providers is strong and likely to endure for three or more years, commit to a direct cloud connection. If your cloud provider relationship is shorter-lived, experimental or generates lower volumes of traffic, WAN-CX might be a better alternative.

This was last published in March 2018

Dig Deeper on Data Center Network Infrastructure

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which of the two approaches to CDCI -- WAN-cloud exchange or direct cloud connection -- do you think would work best for your enterprise, and why?
Cancel

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close