Last week Citrix announced OpenAccess and OpenBridge, two new offerings for cloud computing.  OpenAccess focuses on single sign-on and identity management while OpenBridge is designed to allow connections between local resources and cloud resources.  The OpenBridge announcement highlights an interesting debate occurring around hybrid cloud computing – how should cloud networks be connected?

The debate centers on layer-2 versus layer-3 connectivity.  Traditionally, network topologies for remote data centers, co-location facilities, and managed services have been built with layer-3 (routed) networks.  This made sense since you were creating separate networks for each location and then creating rules for communication between the different locations.  Setting up these networks requires lengthy planning and re-configuration to enable the organization’s core network to communicate with the new external resources.  In addition, the rules and services for servers deployed both in the data center and remote facilities have to be updated. Although deploying layer-3 networks is time-consuming and complex, it’s the way things have always been done by the service providers.

Interestingly, most of the new cloud solutions are also following this layer-3 model because it’s so established and familiar.  Amazon introduced their VPC offering last year that enabled connectivity between the customer’s data center and their cloud over a layer-3 network.  VMware has released vShield Edge services that use layer-3 networks to connect between virtual data center (VDC) networks.

So where is the debate?   Enterprise IT is discovering that the attributes and configuration of layer-3 networking work against some of the most powerful concepts in cloud computing. Most enterprises are looking to the cloud for dynamic applications and deployments.  They want to be able to scale resources on demand, rapidly provision new resources for development and testing, and enable self-service models.  If, for each new environment, they had to get permission to alter the core networking or edge devices and then actually get someone to do it, much of the advantage of the agility of cloud computing would be lost.

The layer-3 approach has two fundamental issues that make it problematic for cloud use cases: (1) layer-3 is location-dependent, and (2) changing configurations in the cloud involves changing core or edge services to match.  If each cloud resource is an independent network with its own addressing scheme, then applications and services deployed to the cloud have to be updated relative to their location.  Further, applications that want to interact with the cloud also have to be updated.  Yes, this can be mitigated with DNS and other techniques, but that just leads back to problem #2.

Because of this realization, we looked for an alternative as we designed our CloudSwitch software that would allow enterprises to access the full power of cloud computing.  With respect to networking, the answer was support for layer-2 connectivity between the cloud and the data center.  Layer-2 networking allows for position independence since the network in the cloud is a direct extension of the network in the data center.   This means that all servers have the same addresses and routing protocols and thus become location independent (from the user and application level, the location of the server cannot be determined).  With this solution, users can select where they want to run their applications locally or in the cloud, and do not have to reconfigure anything.

Of course, creating a layer-2 connection between the data center and a cloud can be challenging.  The actual bridging part is not too hard since the networking technologies have existed for quite some time.  The challenges lie in two factors: cloud provider control and security implications.  In terms of cloud provider control, for a layer-2 bridge to work, the cloud provider must allow the customer to control the networking within the cloud offering.  This means that the cloud provider must allow customers to specify the addressing for each server they deploy in the cloud.  Most public clouds do not have this capability; they assign addresses (either in ranges or per server) and almost universally, these will not align with your internal addressing schemes.  This means that a “standard” layer-2 solution is not compatible with most public clouds.  Because we believe that having a layer-2 option is critical for enterprises looking to embrace cloud computing, we have worked hard to support this in all clouds, even when the native cloud doesn’t.  This is one of the strengths of our Cloud Isolation Technology™ – adding value and capabilities to each cloud we support.

The more major challenge of extending your networks to the cloud is of course security.  By bridging your networks to the cloud, you have to trust the cloud provider and their security measures.  This can be difficult because as a customer, you have no control over what the cloud provider implements or changes over the course of operation.  This is another reason we built our CloudSwitch software around our Cloud Isolation Technology.  If you really want to create a hybrid cloud computing environment, you need the confidence to integrate tightly with the cloud.  CloudSwitch enables this confidence by allowing the customer to separate their environment from the cloud provider’s infrastructure in a highly controlled fashion.  This means that not only do we protect your network and storage traffic from being accessed by the cloud provider, but we prevent any traffic from outside our isolation layer from entering your data center.

In the end, we believe that to achieve true hybrid cloud computing, a solution must support both layer-2 and layer-3 networking, and that is what we have built.  Our customers can choose to interact with their servers in the cloud utilizing an automated layer-2 connection, or create specific rules and routing to access via layer-3, and because of our Cloud Isolation Technology, we can support this even in clouds that don’t natively support full control over network addressing.

It is great to see that a major player like Citrix has embraced the idea of layer-2 bridging with their CloudBridge offering as it helps highlight the importance of this network technology.  Of course, there is a lot more to cloud federation than networking. Full security control, resource allocation and management, application migration, and lifecycle management are other key elements that are essential for a successful deployment, all automated and simplified by CloudSwitch.

• Cloud Federation and the Intercloud
• Great Beaches of The Isle of Wight
• In the Cloud Era, Do We Have Free Speech or Free Beer?