CloudSwitch Enterprise Gateway to the Cloud

CloudSwitch on Ulitzer

Subscribe to CloudSwitch on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get CloudSwitch on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

CloudSwitch Authors: RealWire News Distribution, Elizabeth White, Jeremy Geelan, Liz McMillan, Kevin Jackson

Related Topics: Cloud Computing, Cloud Data Analytics, CloudSwitch on Ulitzer

Blog Post

Why Cloud Federation Requires Layer-2 Connectivity

Hybrid clouds are achieving almost universal buy-in

Hybrid clouds are achieving almost universal buy-in as the way enterprises use the cloud. As we’ve described previously, the hybrid model federates internal and external resources so customers can choose the most appropriate match for workload requirements. The approach is already transforming enterprise computing, enabling a new generation of dynamic applications and deployments, such as:

  • Using multiple clouds for different applications to match business needs
  • Allocating components of an application to different environments (e.g., compute vs database tiers), whether internal or external (“application stretching”)
  • Moving an application to meet requirements at specific stages in its lifecycle, from early development through UAT, scale testing, pre-production and ultimately full production scenarios
  • Moving workloads closer to end users across geographic locations, including user groups within the enterprise, partners and external customers
  • Meeting peak demands efficiently in the cloud while the low steady-state is handled internally

While everybody’s talking about the hybrid cloud, making it work is another story. Enterprise deployment can require extensive reconfiguring to adapt a customer’s internal environment to a given cloud. The result, when it’s finally running, is a hybrid deployment limited to the customer’s internal infrastructure and one particular cloud, for one particular application.

Most cloud architectures are built with layer-3 (routing) topologies, where each cloud is a separate network with its own addressing scheme and set of attributes. This means that all address settings for applications deployed to the cloud have to be changed to those assigned by the cloud provider. It also means that applications and services running internally that need to interact with the cloud have to be updated to match the cloud provider’s requirements. The result is lots of re-configuring and re-architecting so the organization’s core network can communicate with the new external resources – exactly the opposite of the agile environment that cloud computing promises to deliver.

In our discussions with enterprise customers and technology leaders, we’re now seeing a broad recognition that cloud federation requires layer-2 (bridging) connectivity. We’ve always believed that layer-2 is the right way to enable cloud federation. This week’s announcement of Cloud Bridge by Citrix is a confirmation that tight network integration is critical for successful cloud deployments.  Although it’s great to see others now starting down the path of better cloud networking, it is critical that enterprises realize that this level of network integration also requires heightened security for cloud deployments – remember that you are now blending the cloud networks with your internal networks.  This is why CloudSwitch has developed a comprehensive solution that not only provides full network control independent of what networking gear the cloud provider has chosen, but also secures and isolates customers’ data and communications completely through our Cloud Isolation Technology™.

In contrast to layer-3, layer-2 networking is location-independent, allowing the network in the cloud to become a direct extension of the network in the data center. It does this by preserving IP and MAC addresses so that all servers have the same addresses and routing protocols, wherever they physically run. Users can select where they want to run their applications, locally or in the cloud, without the need to reconfigure their settings for different environments.

Don’t Change Anything
CloudSwitch is unique in providing layer-2 connectivity between the data center and the cloud, with innovation that resolves previous addressing and security challenges. Our Cloud Isolation Technology automatically creates a layer-2 overlay network that encrypts and encapsulates the network traffic in the cloud as a seamless extension of the internal environment. The customer has full control over the cloud network and server addressing, even in clouds that don’t natively support this capability. No configuration changes are required. You don’t have to update router or firewall settings for every subnet or cloud deployment. You don’t have to change address settings, or keep up with changes in the cloud providers’ networks – everything “just works.”

While layer-2 connectivity is essential for full integration of the hybrid model, some companies and applications will still want to use layer-3 routing for their cloud deployments.  Some practical applications for layer-3 connectivity include:

  • Cloud-only networks – providing access to the tiers of an application running in a cloud-only network
  • Remote access to cloud resources – VPN services for remote developers or users, branch office integration with the cloud resources where different network settings are required
  • Protected networks – for cases where the enterprise wants to centrally control who can access a specific network (utilizing their core switches and routers)

Keep in mind though, that most of these layer-3 deployments have use for layer-2 connectivity in the background as well.  For the cloud-only networks, other network tiers in the same deployment can benefit from a layer-2 connection back to the primary data center for application and database tiers.  For remote access deployments, management, operation, and maintenance for the cloud resources is greatly simplified by having a layer-2 connection to the data center in addition to the layer-3 access for remote users.

The CloudSwitch recommendation, and the way we’ve architected our product, is to offer layer-2, with support for layer-3 as an option. Our customers can choose to interact with their servers in the cloud using an automated layer-2 connection, or use layer-3 to create specific rules and routing to match their application and even infrastructure design.  We believe that enterprises should have the freedom to create arbitrary networks and blend layer-2 and layer-3 deployments as they need, independent of the networking gear and topologies selected both by the cloud and their own IT departments.

Making Federation Work
For hybrid computing to succeed, the cloud needs to appear like a resource on the customer network, and an application running in the cloud needs to behave as if it’s running in the data center. The ability to federate these disparate environments by mapping the data center configuration to the cloud can only happen at layer-2 in the networking stack. With innovations that make the cloud a seamless, secure extension of the internal environment, CloudSwitch helps customers turn the hype around hybrid cloud into reality.

Read the original blog entry...

More Stories By John Considine

John Considine is Co-Founder & CTO of Cloudswitch. He brings two decades of technology vision and proven experience in complex enterprise system development, integration and product delivery to CloudSwitch. Before founding CloudSwitch, he was Director of the Platform Products Group at Sun Microsystems, where he was responsible for the 69xx virtualized block storage system, 53xx NAS products, the 5800 Object Archive system, as well as the next generation NAS portfolio.

Considine came to Sun through the acquisition of Pirus Networks, where he was part of the early engineering team responsible for the development and release of the Pirus NAS product, including advanced development of parallel NAS functions and the Segmented File System. He has started and boot-strapped a number of start-ups with breakthrough technology in high-performance distributed systems and image processing. He has been granted patents for RAID and distributed file system technology. He began his career as an engineer at Raytheon Missile Systems, and holds a BS in Electrical Engineering from Rensselaer Polytechnic Institute.