federated cloud
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.
Cloud Expo 2010: Virtualization Steals the Spotlight
By Ellen Rubin
At first glance, cloud computing can appear to be “virtualization taken to its logical conclusion.” After all, if the main benefit of virtualization is to consolidate data center resources and increase the speed of provisioning, then cloud is the ultimate pay-off: don’t own the resources at all and cut provisioning down to a few minutes with instant self-service gratification.
But upon further thought, and as was highly visible at the Cloud Computing Expo this week in NYC, cloud seems to be giving virtualization a return to the spotlight. A recent Gartner study noted that cloud computing is the number 2 priority for CIOs – trumped only by…virtualization. And most of the sessions at the Cloud Expo made some mention of the benefits of extending virtualization footprints within the data center and starting to turn these into internal clouds, or at least “cloud-like” environments.
So is virtualization what’s old but new again? Remember that most enterprises have adopted virtualization in some way, but are only about 20% virtualized so far. So there’s plenty of room left to penetrate, and there’s still lots of opportunity for optimization and better management. Virtualization has primarily been used for consolidation, not for optimizing workload management and self-service. And many companies have large investments in existing hardware and virtualization licenses that they’d like to use more efficiently. In many ways, cloud computing has emerged on the scene as a disruptive force while virtualization is still an evolution in progress.
As at other recent shows, the common wisdom at the Cloud Expo was that “hybrid” environments are key to the emerging IT infrastructure. Some resources will stay behind the firewall and others can be moved to outside cloud environments. Some applications may need to be split between the data center and external clouds, especially where the database needs to stay inside. In this hybrid world, some enterprises will want to focus on growing the internal virtualization footprint and starting to build capabilities for provisioning, charge-back, orchestration, role-based access, etc. This may require significant investment in additional hardware and software. It will also require enterprise IT to develop a new perspective on managing their virt investments, learning from the cloud providers about best practices and from companies like CloudSwitch about how to combine external cloud services with their own environments securely and transparently.
It’s also true that many of the major technology vendors (as well as some IT departments) have a bias towards focusing the cloud revolution on known and existing technologies. It’s still somewhat scary to think about moving things outside the data center and cloud technologies are in relatively early stages. And external cloud services (in particular public clouds) are pushing the envelope in terms of customer expectations and placing new, challenging demands on virtualization.
But virtualization will have to step up to these demands now that the cloud revolution has raised the bar. Many of the emerging capabilities will need to be at the management plane: a broad range of self-service functions, for sure, but also the ability to route workloads to the appropriate environments based on business and technical requirements, and to federate across multiple and diverse environments both on-prem and externally. So maybe cloud computing turns out to be not only the logical extension of virtualization, but the catalyst that helps virtualization move to the next level.
2010 is the Year of the Federated Cloud
In this first post of 2010, I’d like to look at one of the most important cloud issues that enterprises want to tackle: federation in the cloud — across clouds and between the cloud and the data center. Also known as hybrid clouds, the notion of federation has been around since cloud computing began, but as a long-term vision rather than a working solution. This year that gap is going to close.
What Is Cloud Federation?
Federation brings together different cloud flavors and internal resources so companies can select a computing environment on demand that makes sense for a particular workload. It opens the door to a range of useful scenarios that take advantage of cloud capabilities:
- Using multiple clouds for different applications to match business needs. For example, Amazon AWS or Rackspace could be used for applications that need large horizontal scale, and Savvis or Terremark for applications that need stronger SLAs and higher security. An internal cloud is another federation option for applications that need to live behind the corporate firewall.
- Allocating different elements of an application to different environments, whether internal or external. For example, an application could run in a cloud while accessing data stored internally as a security precaution. (We call this concept “application stretching.”)
- Moving an application to meet requirements at different stages in its lifecycle, whether between public clouds or back to the data center. For example, Amazon or Terremark's vCloud Express could be used for development, and when the application is ready for production it could move to Terremark's Enterprise Cloud or similar clouds. This is also important as applications move towards the end of their lifecycle, where they can be moved to lower-cost cloud infrastructure as their importance and duty-cycle patterns diminish.
Enterprise users don’t typically talk about federation per se; they speak in terms of application-specific and general business requirements. While some applications will always belong in their data center, they may have others (possibly hundreds) that could run more cost-effectively in the right cloud. Our customers and prospects tell us that they would love to take advantage of different clouds to get the computing performance they need, along with the desired service levels, scalability, security and price points. And since they aren’t that clear yet on their cloud requirements, and cloud services are in early stages and will continue to evolve, they want the ability to pick up their applications if necessary and move them to other clouds or back to the data center with minimal effort.
The problem is that the cloud is not a homogenous entity, but covers a broad landscape of computing environments, with no consistency between any of them or with the enterprise data center. Federation is the missing link, providing a structure that bridges these disparate environments so enterprise cloud computing can become as seamless and straightforward as it needs to be. Let’s examine some of the key issues and see what CloudSwitch is doing to make federation work.
Bridging the Differences
An application should to be able to run “as is” in any cloud with the resources to support it. But each cloud has its own server platforms, operating system versions, APIs, network settings, storage options—a whole landscape of varied characteristics. Without federation, each cloud deployment becomes a custom “one-off” exercise to meet the requirements of a particular cloud environment. That’s not acceptable internally, and companies are now demanding the ability to leverage different clouds without the underlying engineering efforts required to make it happen.
A unique capability of CloudSwitch is the ability to integrate at an infrastructure level between the data center and different clouds. We sit in the middle of all of these resources and automatically bridge the differences, regardless of variations in virtualization platforms, operating systems, APIs, storage infrastructures or other characteristics of the different clouds. Both internal and cloud resources appear as if they’re running locally, using a common interface spanning multiple clouds and the local environment.
Setting Consistent Rules
Rules and permissions about what employees can do in the cloud must be consistent with those in the data center. Role-based controls are required, for example, to enable a particular individual or group to create servers but not to delete or modify them. However, in these early days of cloud computing, the standard procedure is to allow cloud users access to the cloud credentials; essentially every user has full control and access to the cloud resources. This not only causes control issues but makes auditing and problem resolution difficult since it is unclear who is responsible for any particular action.
CloudSwitch solves this problem by holding the credentials for external clouds and serving as the gateway to cloud accounts. Rather than users accessing their accounts directly, they interact with the cloud through the gateway, which consolidates permissions for all users and multiple clouds for management by an administrator. The approach provides consistent policies governing user and management roles, whether internal or external.
Streamlining Cloud Management
Federation also means that administrators should be able to manage applications running in one or more clouds as if they were running locally, using their familiar tools and processes for application lifecycle management, monitoring, compliance management, etc. But cloud computing involves a wide assortment of isolated environments to keep track of and manage. Adding to the complexity, cloud providers often have their own management tools that users or administrators need to learn, all different from each other and from what enterprises have internally.
CloudSwitch keeps things simple for the enterprise by replicating the existing IT infrastructure and mapping it to the target cloud. The approach allows current management tools to work seamlessly in the cloud, just as if an application were running locally. Using consistent tools and policies, applications and resources can be managed with the same flexibility, security and control regardless of their location.
Bringing the Vision to Life
Federation is required for cloud computing to be successful, particularly as computing needs continue to expand. Enterprise users want to take advantage of all the capabilities available in the cloud, but without the complexity or risk. The ability to federate this heterogeneous ecosystem—to create a uniform environment spanning external and internal clouds—is going to allow IT organizations to meet user and corporate needs with an agility and economy not previously possible. CloudSwitch is part of an emerging ecosystem that’s making federated cloud a reality.
