hybrid cloud computing
Networking in Federated Clouds - The L2/L3 Debate
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy John Considine
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.
Legacy Apps Make the Case for the Cloud
By John Considine
We often talk about CloudSwitch moving legacy applications to the cloud in a simple and secure way; this raises the question of what exactly we mean by “legacy.” To be more specific, we mean a broad range of apps—including third-party, custom and customized off-the-shelf applications—basically any application that has been developed in your current environment without specific design for a cloud.
It turns out that these existing applications are very important in cloud computing. When we started building CloudSwitch, we were focused on the hybrid cloud computing model; that is, some components must stay in the data center and other applications and functions can move to the cloud. However, it became apparent that “stretching” applications between the data center and cloud only works for certain types of deployments due to the added latency between the data center and the cloud. For this reason, we recommend moving as much of a multi-tier application to the cloud as you can. This allows the application to continue to run with low latencies between the different components. Sounds obvious, but this is where a whole new set of problems arise, and it’s what causes people to start talking about the challenges of moving legacy applications to the cloud.
In order to operate a multi-tier application in the cloud, you need to be able to control the application(s), infrastructure, and operating system, including things like a database tier, middleware, and custom applications. This also means that you have to “cloudify” each of these components. Suddenly you are looking at a lot of work, and potentially facing failure because some of those tiers can’t be modified to run in the cloud.
We saw a great example of this when Microsoft’s Azure service first launched. The initial release of Azure allowed application developers to build .NET applications and run them seamlessly on their local machines or in the Azure cloud. However, people trying to use this cloud usually had other applications/databases/etc. that were part of their solution, and there was no way to run these in Azure. This meant that there were a lot of things that could not be moved to Azure since “stretching” the application caused unacceptable latency and there was no way to connect the Azure deployment to the data center-side applications. Microsoft has since expanded the capabilities of Azure, but there are still many types of applications and services that cannot run in their environment.
Given all the challenges, why is it worth bothering to move legacy applications to the cloud? For most enterprises (as opposed to new ventures and SMBs), legacy apps by definition occupy the majority of the existing IT footprint, far more than newer applications, let alone those designed specifically to run in a cloud. In many of the companies we’ve worked with, legacy apps are well over 75% of the data center footprint, and they’re constantly expanding and creating needs for more capacity. Legacy apps tie up internal processing and storage resources, sometimes continually, sometimes in a “spiky” way to meet occasional massive needs. Their demand for computing power is usually growing (or skyrocketing), and contending with other applications. The enterprise then has to make tough choices about whether to buy more equipment or put up with degraded performance.
By providing access to virtually unlimited resources on demand, the cloud can bring a new level of elasticity and efficiency to a company’s IT environment. Legacy apps are often the best candidates for moving to the cloud, especially in cases where they’re infrequently used, or only need to scale for new releases or for seasonal/marketing-driven events. One of the best use cases for the cloud so far is the ability to offload this type of resource-consuming set of apps to a lower-cost cloud infrastructure, freeing IT to focus limited internal resources where they’re needed most.
