Cloud Federation
Why Cloud Federation Requires Layer-2 Connectivity
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy John Considine
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.
What to Look for in a Cloud Gateway
Part 2 of a 2-Part Series
By Ellen Rubin
The last post explored why more and more enterprises and technology vendors are making the adoption of a cloud gateway a top priority. This post focuses on the capabilities that all stakeholders should look for.
So what exactly is a cloud gateway? A cloud gateway is technology that extends the enterprise data center or private cloud out to external clouds. It’s a core component of the hybrid model, and when it’s well-architected, it brings simplicity, flexibility, and control to cloud computing. By shielding users and IT departments from the complexity of cloud deployments, the gateway makes applications portable across different cloud architectures, platforms and even different hypervisors. It provides cloud users with easy access to the widest range of resources and services available, and gives technology vendors a platform for delivering high-value services to on-premise and cloud environments. It’s also a platform for innovation around new capabilities that now become available in the hybrid cloud model.
Here’s what a well-designed cloud gateway needs to do:
- Guarantee security: Data needs to be encrypted end to end, from inside the corporate firewall, across the Internet, and within the cloud infrastructure. Encryption keys need to be under enterprise control at all times, and off-limits to everyone else. The cloud becomes an integral part of the enterprise IT environment with data at rest and network communications protected from both the cloud provider and 3rd parties at all times.
- Extend enterprise networking: Every enterprise has a unique network infrastructure for connecting its servers and applications — things like addressing schemes, topology, identity and directory services, and network equipment (firewalls, routers, and switches). Cloud providers have completely different network architectures to support their multi-tenant operations. The gateway needs to enable enterprises to match their current network topologies when they are using the cloud, and have the ability to bridge specific network segments (or LANs) to the cloud in a simple and automated fashion – including both layer-2 (Ethernet) and layer-3 (Internet Protocol) connectivity.
- Deliver enterprise-class network appliances: As more and more network vendors introduce their own cloud versions, customers want to be able to leverage what they already have on-premise and use trusted vendor products for their cloud deployments. These enterprises have made significant investments in the management and operation of these appliances. A cloud gateway should enable the use of these trusted vendors across the various cloud offerings available to allow the enterprise to leverage policies, configurations, and expertise when extending into the cloud.
- Integrate with data center infrastructure: A gateway should be able to tie into existing virtualization infrastructure to allow users to seamlessly combine the cloud deployments with on-premise applications and infrastructure. The gateway should be able to interact with different virtualization technologies (VMware, Xen Server, Hyper-V, KVM) to give enterprises the broadest scope and flexibility in cloud deployments as they evolve their virtualization and cloud strategies.
- Provide seamless visibility and control: The gateway should allow users and administrators to monitor and manage applications running in a cloud as if they were running locally, using existing tools and polices in a single, integrated environment. Cloud resources should appear as part of the corporate infrastructure, with external pools of capacity appearing alongside internal ones.
- Protect roles and access: Dedicated individuals or teams are usually responsible for setting up enterprise networking, storage, virtual machines, applications, monitoring, etc. In the wild west of the cloud, with the paradigm shift towards self-service provisioning and management, these responsibilities fall on the end user — typically the developer or business user as they access cloud resources. These users are often unaware of corporate policies or configurations, and are unsure how to address these requirements. The cloud gateway should preserve the multi-role capabilities required for enterprise control, allowing rules to be created and enforced while letting users access cloud resources on demand.
- Span disparate cloud architectures: All the requirements mentioned above need to span multiple clouds, with their different APIs, hypervisors, storage architectures, etc. The gateway needs to give users access to the widest range of choices so they can take advantage of all the cloud has to offer. The gateway must be designed with a deep understanding of different cloud providers’ capabilities and differences, so it can deliver optimal services and the best price/performance to meet customers’ specific requirements.
A Platform for Innovation
Beyond meeting the needs of customers and vendors today, the gateway is a platform for innovation that opens the door to a new generation of capabilities. The cloud gateway sits at the nexus of new technologies – it ties into the virtualization infrastructure within the data center, tightly integrates into the network infrastructure, and connects with multiple external clouds. The ability to interact with all these key components enables new services and solutions. Here are a few examples:
- Cloud brokerage: Workloads can be moved to the right environment based on business and technical requirements. Users can examine a menu of available clouds and choose the ones that provide the best combination of pricing, QoS, provider flexibility, or other criteria.
- Geographically distributed applications: The cloud provides the freedom to place workloads around the world. The gateway allows simplified network management, multi-cloud support (the ability to choose clouds nearest your consumers), and central control for resource management.
- Data management: The gateway is in a key position for managing data and workload distribution. With ties into both the data center and target clouds, the gateway can facilitate data movement, replication, remote access, and security of data.
- Enhanced security: With access to enterprise resources as well as control of distributed networking and compute resources, the gateway is an ideal place for delivering new security models – including remote access, distributed policies, and advanced virus protection.
The concept of a cloud gateway is capturing mindshare across the cloud industry –from enterprise customers to technology vendors and service providers. It’s a key enabler for their cloud strategies, and they’re eagerly looking for ways to take advantage of it, to meet current requirements and introduce some new paradigms in enterprise computing.
Hybrid Clouds: Private vs. Public, Revisited
By Ellen Rubin
We’ve written extensively about the benefits of hybrid clouds, since it’s a core part of our founding vision at CloudSwitch. For most of this past year, the cloud market has been focused on defining the differences between public and private clouds and weighing the costs and benefits. Slowly the conversation has shifted to what we believe is the central axiom of cloud: it’s not all or nothing on-premise or in an external cloud; it’s the ability to federate across multiple pools of resources, matching application workloads to their most appropriate infrastructure environments.
To reiterate some key thoughts we’ve written about in the past, the idea of hybrid clouds encompasses several use cases:
- Using multiple clouds for different applications to match business needs. For example, Amazon or Rackspace could be used for applications that need large horizontal scale, and Savvis, Terremark or BlueLock 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, the compute tiers of an application could run in a cloud while accessing data stored internally as a security precaution (“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.
CloudSwitch customers and prospects are clear that hybrid clouds are the way to go. Here are some examples of recent conversations:
“It’s going to take our internal IT group more than 18 months to build a private cloud; in the meantime we can use the public clouds now for on-demand capacity and scalability.” – VP of Business IT group at a large Wall Street firm
“We’re highly virtualized and we see external clouds as pools of virtualized resources that are available as extensions of our internal infrastructure.” – IT Director at a large healthcare company
“We have compliance data that will never leave our firewall but we like the idea of scaling out the computing resources in the cloud for peak periods.” – VP of Informatics at a large pharma
We’ve also been tracking some validation from more official sources on the growth of public clouds and the hybrid model. For example, a recent study by SandHill Group surveyed more than 500 IT executives and indicated that the biggest growth in cloud computing will be in hybrid clouds (from 13% now to 43% in three years). Another survey by Evans Data finds an even higher adoption rate among IT developers, suggesting that the hybrid cloud model is set to dominate the coming IT landscape.
It’s also interesting to see the importance of the hybrid model taking hold among industry insiders with many different perspectives. We saw this at VMworld 2010, where there was tremendous interest in hybrid clouds, from Paul Maritz’s keynote predicting a hybrid cloud future through many sessions and product announcements. Veteran cloud watcher James Urquhart points out that the hybrid approach lets you hedge your bets in cloud computing, using technology that allows you to decouple the application from the underlying infrastructure and move it to the right environment so you don’t get locked in. And even private cloud advocates acknowledge that hybrid has an essential role, where public cloud platforms serve as extensions of private cloud deployments.
It’s gratifying to see the CloudSwitch founding vision gain broad industry acceptance, with the hybrid model as key enabler for cloud computing. It’s even more satisfying to seeing the vision coming to life as more and more customers leverage our technology to run their applications effortlessly in the right environment, whether an internal data center, private cloud, or public cloud. Enterprise users and their companies are the real winners.
Networking in Federated Clouds - The L2/L3 Debate
By 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 in a Box" Gets Boxed In
By John Considine
Just a week after our blog post on the telcos, we find another big company joining the cloud computing tsunami – Oracle’s announcement of its “cloud in a box” offering as well as new offerings of Oracle software running on Amazon’s EC2.
For a company whose leader shunned the term “cloud” last year, this is a lot of cloud announcements in one week. Oracle’s new Exalogic Elastic Cloud is perhaps the first 
“cloud in a box” solution that is actually delivered in a box (of hardware). Unlike the offerings we have seen from Eucalyptus, Nimbula, Azure, and VMware, the Exalogic product contains the control software as well as the hardware components to make a virtualized resource pool. The other vendors have focused on delivering a software solution that can be combined with the users’ choice of servers, storage, and networking gear to build a cloud.
Oracle, powered by Sun’s server and system technology, has decided to deliver a complete cloud solution that contains up to 360 CPU cores, 2.8TB of RAM, and 40TB of storage in a single rack of equipment. This big box is reportedly priced at just over $1M. Oracle’s motivation for this box is to deliver on the promise of building an entire stack of both hardware and software that has been engineered to work together to deliver better performance, reliability, and scale. Overall, the Exalogic system has impressive performance characteristics and may be a great solution for data center consolidation, but…
Placing the term “Elastic” in the name of this offering is stretching the accepted definition of the term as it relates to cloud computing. The Exalogic server is a contained set of resources that is purchased, operated, and maintained as part of the enterprise infrastructure. You can scale your applications up and down within this solution, but in the end, you are limited to the number of cores, amount or RAM, and size of the storage you purchased. While you can add more racks to the solution, you are stuck paying for the whole thing independent from what you really use – not exactly elastic or pay for only what you use. My only other problem with Exalogic is the range of supported operating systems – we like the Linux and Solaris support, but a quote from Rick Schultz of Oracle – “There is no demand for Windows at the moment” – makes me wonder who they are talking to. More than half the enterprise workloads CloudSwitch has deployed to the cloud are Windows-based; how can there be no demand for Windows in Exalogic?
The other interesting difference in the Exalogic solution as compared to the big (public) cloud offerings is the design center for the hardware. Clouds like Amazon and Google were developed around “stripped down” servers to act as generic compute components. The redundant components normally used to improve the reliability of a server are removed from the compute nodes to reduce the component cost, and software and other application-level techniques are used to make up for the fail-able components. Each of the servers in the Exalogic solution has redundant power supplies, 2 solid state disk drives, and redundant Infiniband controllers. This more expensive hardware allows the system to survive component failures with minimal disruption to the running applications – a traditional enterprise infrastructure design, with high reliability to support a lot of VM’s packed on a single piece of hardware.
The difference between the two approaches highlights the upcoming battle between architectures in the cloud – stripped down commodity servers versus highly available high-end servers as the basis for cloud computing. The early leader in this space is the commodity server approach because of the types of applications initially targeted to clouds – stateless horizontally scalable web applications. But as we start putting more core enterprise applications into the cloud, the HA architectures become more interesting, and thus we expect this architecture to gain ground. We see these architectures gaining ground already with clouds like Terremark, BlueLock, and Savvis.
The other announcement this week from Oracle is expanded support for running Oracle software in Amazon’s Elastic Compute Cloud. Oracle has provided templates (AMI’s) in Amazon for its database software since 2008, and this week they have expanded the number of applications they will support in Amazon to include Oracle E-Business Suite, Oracle's PeopleSoft Enterprise, Oracle's Siebel CRM, Oracle Fusion Middleware, Oracle Database, and Oracle Linux. In addition to expanding the software supported on AWS, Oracle has taken the step of “certifying” the software for operation in Amazon. This means that customers can now get support from both Oracle and AWS for those applications. Although Oracle’s lead cloud story seems to be about the Exalogic box, I believe that this announcement does more to advance cloud computing for enterprises. Support for these key Oracle products in Amazon’s cloud adds credibility to public cloud computing, as it allows enterprises to really use the cloud for their core applications. This is one of the areas that a cloud provider cannot fix, it is up to the software vendors to expand their horizons to embrace the cloud and Oracle is blazing the trail.
I think the only downside to the Oracle-Amazon announcement is the lack of integration with Oracle’s control software. The FAQ’s from Amazon and Oracle emphatically state that the management controls for Oracle deployments to the cloud is exclusively the Amazon console and tool set. This is a shame since we believe that seamless integration between the data center and the cloud is key to a successful enterprise cloud deployment; creating a disjointed environment just adds work with no value for the enterprise and ultimately leads to cloud lock-in. Our enterprise customers have told us consistently that they want a “single pane of glass” from which they can manage pools of resources both internal and external.
Finally, while I like the architecture of the Exalogic Elastic Cloud, and believe that it could form the basis of a new class of cloud computing offerings, it too may be missing a critical point. If an enterprise decides to deploy their private cloud on this technology, there is no connection or relationship between the applications deployed to the private cloud and those running in the public cloud. This, once again, highlights the importance of cloud federation – you will never break the cycle of buying more hardware and infrastructure if you don’t embrace technology that allows you to access the public clouds.
CloudSwitch Enables True Cloud Federation
By Pavan Pant
As with any transformative technology that is new to the market, both public and private clouds have generated massive amounts of hype, bold predictions, a whole lot of confusion and raging debates amongst the cloud cognoscenti. Opinions vary across the spectrum with some experts claiming that data centers will be rendered obsolete by the public cloud, while others are dismissive of the public cloud but support private clouds. It’s clear to us at CloudSwitch that a more likely scenario lies squarely in the middle of those two extremes. This week at VMworld (where we were exhibiting with our partner, Terremark), we were pleased to hear that VMware believes that “hybrid cloud is the tide coming in.” From Paul Maritz’s keynote through many sessions and product announcements (including the release of the long-awaited vCloud Director), the message was all about hybrid clouds.
One of our previous blog posts discussed the notion of hybrid clouds and the fact that most enterprises will follow such an approach in the future. Amazon, Terremark, Rackspace, Savvis, Blue Lock and other public cloud providers give customers elasticity, better service delivery and low CapEx costs. Meanwhile, there are solutions such as Eucalyptus and VMware’s vCloud Director that provide the interface and management tools to help organizations build private clouds while interfacing with public clouds to create hybrid cloud models.
Both use different APIs for their hybrid models with Eucalyptus delivering tight integrations for EC2 using Amazon’s APIs and VMware vCloud Director working with vCloud DataCenter Services (VMware’s terminology for public cloud providers) such as Terremark that leverage vCloud APIs. However, these technologies do not assist with creating an environment that spans hypervisors and cloud providers without changing the applications. If customers build private clouds that are not using the same virtualization infrastructure as their preferred public clouds then what does it really mean to hybridize their clouds?
Consider a scenario where a customer builds a private cloud using Eucalyptus or VMware vCloud Director. That private cloud still ends up being different from your data center (much like a public cloud) - the networking may be different, versions of virtualization technology may be different and the storage infrastructure may be different. All this means that applications in the data center will need to be changed before moving to the private cloud. As an example, if your QA team runs servers on their own subnet in the data center how can this be transitioned to a private or public cloud without incurring additional costs to change those servers?
CloudSwitch’s core value proposition lies in the ability to securely transport a customer’s existing virtual infrastructure to the cloud provider of their choice, independent of the provider’s underlying virtualization infrastructure (VMware, Xen, etc.). This effectively allows customers to securely move and operate servers from their data center across hypervisors to private cloud providers without requiring them to make any modifications to their application – we maintain the same IP address, MAC address, storage controllers, subnet information, etc. Once customers have moved their servers to the cloud they can operate and manage them just as they would in their data center. CloudSwitch has an intuitive web based interface which gives customers server lifecycle management options such as start, stop and clone.
Similarly, if customers have a private cloud which uses either Eucalyptus or VMware vCloud Director CloudSwitch can speak to those APIs and facilitate the transfer and management from these private clouds to public clouds. This enables a hybrid model where private clouds leverage public clouds for spikes in usage (cloudburst), or lab-on-demand use cases for training and POCs. CloudSwitch does all the work of integrating the environments across these private and public cloud hypervisors, merging networks and transferring servers without modifying them in any way.
Many years ago, I had the privilege to work on the first iterations of RSA’s identity federation product both as an engineer and as a product manager. Federated single sign on enabled the portability of identities across security domains and allowed for the secure exchange of sensitive data outside the firewall without requiring any changes to the identity itself.
While the markets for Identity Management and cloud computing are unambiguously different, the notion of federation to make portability and interoperability easier for enterprises is a common theme. CloudSwitch is in a unique position to help enterprises with true cloud federation by moving workloads seamlessly from the data center to the cloud (private or public), between private and public clouds (hybrid), across public clouds and back to the data center without requiring customers to make any changes to their applications. Regardless of the starting point, CloudSwitch offers customers an easy, effective method to leverage the benefits of the cloud while ensuring portability across clouds.
The New Normal in Enterprise Infrastructure
By Ellen Rubin
As we work with dozens of companies that are actively running pilots and doing early deployments in the cloud, it made me think about what the “new normal” will look like in enterprise IT infrastructure. A recent report from the Yankee Group shows that adoption of cloud is accelerating, with 24% of large enterprises already using IaaS, and another 37% expected to adopt IaaS within the next 24 months. It’s clearly a time of major shifts in the IT world, and while we wait for the hype to subside and the smoke to clear, some early outlines of the new paradigm are emerging. Here’s what it looks like to us at CloudSwitch:
- Hybrid is the dominant architecture: on-prem environments (be they traditional data centers or the emerging private clouds) will need to be federated with public clouds for capacity on-demand. This is particularly true for spikey apps and use cases that are driven by short-term peaks such as marketing campaigns, load/scale testing and new product launches. The tie-back to the data center from external pools of resources is a critical component, as is maintaining enterprise-class security and control over all environments. Multiple cloud providers, APIs and hypervisors will co-exist and must be factored into the federation strategy.
- Applications are “tiered” into categories of workloads: just as storage has been tiered based on how frequently it’s accessed and how important it is to mission-critical operations, application workloads will be categorized based on their infrastructure requirements. In the end, app developers and users don’t really want to care about where and how the application is hosted and managed; they just want IT to ensure a specific QoS and meet specific business requirements around geography, compliance, etc. The cloud offers a new opportunity to access a much broader range of resources that can be “fit” against the needs of the business. In some cases, the current IT infrastructure is over-provisioning and over-delivering production gear for lower-importance/usage apps; in other cases it’s woefully under-delivering.
- IT becomes a service-enabler, not just a passive provider of infrastructure resources: IT is now in a position to provide self-service capabilities across a large set of resources, internally and externally, to developers, field and support teams. This requires a new set of skills, as we’ve blogged about before, but the cloud gives IT the opportunity to meet business needs in a much more agile and scalable way, while still maintaining control over who gets to use which resources and how.
- The channel shifts from resellers to service providers: as noted by Andrew Hickey at ChannelWeb, the opportunities for resellers will need to shift as companies reduce their large hardware and software buys in favor of the cloud. The new focus will be on providing services and consulting with an opex model and monthly payments, and expertise in change management and predictive use models will become core competencies. We’ve already started to see this shift at CloudSwitch with a new crop of cloud-focused consulting/SI boutiques springing up in the market to help CIOs plan their cloud deployments.
For many enterprises, these shifts are still being discussed at a high level as CIOs formulate their cloud strategies. Other organizations are diving right in and selecting a set of applications to showcase the benefits of cloud to internal stakeholders. We’ve been fortunate at CloudSwitch to work with some of the earliest cloud adopters and with our cloud provider partners to help define some of the “new normal.”
At Cloud Connect, the Hybrid Debate Rages On
By Ellen Rubin
While some basic consensus has been reached about the definition of cloud computing (although perhaps it’s mainly exhaustion on the part of the definers), a new debate appears to be raging based on many discussions this week at the Cloud Connect event in Santa Clara. Hybrid clouds were the talk of the show, and the boundaries between private and public clouds are rapidly emerging as battlegrounds for vendors and pundits.
At CloudSwitch, we’ve been evangelists of the hybrid cloud since our founding days, and we’ve spent some time discussing internal/external and public/private trade-offs. The fact is that for most enterprises, a hybrid (or ‘federated’ in my preferred word choice) environment is the most likely computing strategy. This is because different applications require different technical capabilities and are governed by different business requirements. Some will stay behind the firewall (at least in part, if not in their entirety), while others can take advantage of external cloud offerings, be they public or private.
Most sessions at the Cloud Connect event included the hybrid issue, with much debate about the terms used. As with cloud computing, it’s time to put aside discussions about definitions and get down to the pragmatic decisions that have to be made. The key is to stay focused on the applications: which apps are your core competencies, require specialized hardware, or contain compliance/highly sensitive data? Which ones are ‘spikey’ in nature, allowing them to benefit most from cloud economics? Which ones are bandwidth-intensive and tightly coupled to other apps? Which ones have specific SLA requirements to meet customer demands?
These are the right questions to be thinking about – to match the right apps to the right computing environment. In the end, enterprise users don’t care as much about what the cloud offering is called, as they do about provisioning their specific app quickly, protecting it from security threats, and scaling and managing it as required by the business. The ability to move apps seamlessly and securely between multiple environments is a critical part of making this work, and is the linchpin of cloud federation. If you don’t need to worry about the boundaries between cloud offerings, you can embrace them all in the combinations and permutations that meet your needs.
Cloud Federation and the Intercloud
Last week’s post explored federation in the cloud, allowing enterprises to move workloads seamlessly across internal and external clouds according to business and application requirements. Advances in federation are good news for companies considering a move to the cloud since deployments no longer need to be custom projects and applications no longer have to be tightly coupled to a particular cloud.
To follow up, there’s been lots of discussion recently about the concept of the “Intercloud,” a direction for cloud computing that is closely related to federation and ties in with much of our work at CloudSwitch. A term introduced by Cisco, the Intercloud refers to a mesh of clouds that are interconnected based on open standards to provide a universal environment for cloud computing. Like the name suggests, it’s similar to the Internet model, where everything is federated in a ubiquitous, multiple-provider infrastructure.
The primary difference between the Intercloud and federation is that the Intercloud is based on future standards and open interfaces, while federation uses a vendor version of the control plane. With the Intercloud vision, all clouds will have a common understanding of how applications should be deployed. Eventually workloads submitted to a cloud will include enough of a definition (resources, security, service level, geo-location, etc.) that the cloud is able to process the request and deploy the application. This will create the true utility model, where all the requirements are met by the definition and the application can execute “as is” in any cloud with the resources to support it.
What shape the Intercloud will take and what standards will emerge to make it work are part of an ongoing debate. Some industry watchers believe it will happen sooner than later. Others believe that discussion of the Intercloud is premature, wary that embracing standards too quickly will hold back innovation, and therefore the Intercloud will remain only a vision for the foreseeable future. When these debates will be resolved is anyone’s guess, but major progress in cloud integration is already underway, so there’s no need for enterprises to put their cloud plans on hold.
At CloudSwitch, we believe that the Intercloud is likely to emerge organically as the result of continuing innovations throughout the cloud ecosystem. Federation is one of the prerequisites toward that goal, providing ongoing improvements in cloud interoperability aimed at giving enterprises many new options from which to choose. The ability to federate identity, access and dataset migration is also one of the key requirements for Intercloud activity. This interoperability at the infrastructure level has to work transparently in order to launch applications into the cloud environment and manage the integration.
The benefits of the Intercloud are in many ways already a practical reality. A significant part of the Intercloud vision can be achieved with a strong federation technology that provides a gateway between different clouds and the internal data center. Users and their companies can avoid lock-in and run workloads in the environment that best matches their needs, based on cost, performance, security, compliance, geography, latency, etc. In short, some of the most important Intercloud goals can be achieved using technology already coming to market.
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.
