Simplifying Private Cloud Delivery

Private Clouds

Simplifying Private Cloud Delivery

One aspect of successful technologies is they are easy for customers to understand. There may be supporting complexity, but it is hidden from the end user. Today, public cloud services are popular not only because they are inexpensive and efficient, but because they are easy to buy and use. Private cloud services (those reached directly by carrier Ethernet E-Line services) need to adopt the dynamic and easy nature of public cloud services. However, this means that delivery of private cloud services needs to be standardized, simplified and automated.

Everybody loves choices, options and features. The most popular TVs and smartphones have the most features. How many of these do we actually use? 

With flexibility comes complexity, but with standardization comes simplicity. In particular, simplification can enable automation. In short, to simplify the delivery of private cloud services we need to remove some of the complexity due to configuration options.

Today, delivery of a private cloud service means that an enterprise, a service provider and a cloud provider must agree on a dizzying number of options and parameters to establish a service. These choices include:
 

  • The creation of a UNI for the Enterprise
  • Definition of the VLAN tags used for the service
  • Determination of the Class of Service (CoS) model
  • Agreement on the IP addressing model and subnets

These choices complicate the ordering, slow down deployments and may chase away potential buyers.

An example of today’s private cloud delivery is shown in Figure 1, which shows two enterprises connecting to a pair of cloud providers. The connections are delivered over a carrier Ethernet network using Ethernet Virtual Private Line (EVPL) services.

  • Enterprise A connects to
    • Cloud provider 1 using CE-VLAN 101 and IP subnet 1
    • Cloud provider 2 using CE-VLAN 102 and IP subnet 2
  • Enterprise B connects to
    • Cloud provider 1 using CE-VLAN 101 and IP subnet 3
    • Cloud provider 2 using CE-VLAN 102 and IP subnet 4

All of the above items have to be coordinated between the enterprise and the cloud provider. In addition, each cloud provider requires one UNI per Enterprise, and the routing model needs to be coordinated, typically using BGP. This model is simple and straightforward, but it is highly static, lacking the efficiencies to scale to address the needs of the cloud provider.

Figure 1: Today’s Private Cloud Connect

Keep it Simple, Stupid

The next step is to scale and simplify the delivery of private cloud services to the cloud provider. The service provider acts as an intermediary to simplify the coordination activities. The details of the handoff can be hidden from the enterprise and the cloud provider. An example is shown in Figure 2.

Figure 2: Enhanced Private Cloud Connect

With the Private Cloud Connect, the service provider is supplying a Carrier Ethernet EVPL E-Line with a VLAN swap at the cloud provider UNI to decouple the CE-VLANs at each end of the EVC (or in MEF (News - Alert) terms “CE-VLAN Preserve” set to no). As a result, an enterprise could access more than one cloud provider, and the cloud provider could serve multiple customers on a single multiplexed UNI interface. The benefits of this approach include:

  • It allows an enterprise to standardize on a CE-VLAN scheme facing the UNI e.g. 101, 102, etc.
  • It allows each cloud provider to have a separate CE-VLAN scheme on the UNI.
  • The service provider takes care of CE-VLAN normalization between the enterprise and cloud provider.
  • The CoS is standardized using 802.1 (rather than DSCP).
  • Service policing per EVC performed by the service provider.

This is all just a private cloud starting point. Your own research and future Cloud Computing Magazine articles can help fill in the blanks.  




Edited by Stefania Viscusi
blog comments powered by Disqus