Cloud Networking
Cloud Federation and the Intercloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInLast 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.
Moving to the Cloud: Key Considerations for Cloud Networking
This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.
Every enterprise has a unique network infrastructure for accessing servers and allowing applications to communicate between components. Various layers support the management of network addressing, deliver critical services, and ensure security. The infrastructure includes specific addressing (sub-nets), address services like DHCP/DNS, identity and directory services like LDAP, and firewalls and routing rules – all reflecting the specific requirements and evolution of the given enterprise.
Clouds are not different from the enterprise in this respect; they have unique networking infrastructures that support complex and flexible multi-tenant environments. Remember that the cloud providers have to control their networking so that they can route traffic within their infrastructure. More important, their design is completely different from your enterprise networking architecture, design, and addressing. This is not a problem if you’re doing something stand-alone in the cloud because you don’t care what the network structure is as long as you can access it over the internet. However, if you want to extend your existing networks and use your existing applications, there are serious discontinuities that have to be addressed.
First, you have to deal with addressing. The typical cloud provider will assign you a block of addresses as part of your cloud account. For example, Flexiscale and GoGrid essentially give you get a block of assigned addresses that you can attach to the servers you create. In some cases these are external addresses (meaning that they are public addresses that can be accessed from the internet), while in others, they are internal. In either case, they are not assigned as part of your addressing. This means that even if you manage to connect these resources to your data center, you need to build new routes and alter your services to allow these “foreign” addresses into your system. Amazon originally took a different approach by providing a dynamic system where an address is assigned every time a server is started. This made it hard to build multi-tier applications, requiring developers to design systems able to pass changing address information between application components. The new VPC offering partially solves this problem for connecting to the Amazon cloud, although some key challenges remain. Other cloud providers are investigating similar networking capabilities.
The next major issue with networking in the cloud is data protection. In your data center, there is a secure perimeter defined and developed by your IT organization that is comprised of firewalls, rules, and systems to create a protected environment for your internal applications. This is important because most applications need to communicate over ports and services that are not well protected and certainly not safe for general internet access. Since applications are developed for the protected environment of the data center, it can be dangerous to move them unmodified into the cloud. Under normal circumstances, the application owner or developer has to build protection on a per-server basis and enact corporate protection policies.
The loss of control of the infrastructure mentioned earlier has additional implications – in most clouds you can’t control the physical interface level. That is, in addition to assigned IP addresses, you get MAC addresses assigned to you as well. These addresses can change every time a server is started which means that the identity of the server (and associated IP addresses) cannot be based on this familiar attribute.
All of these networking issues are at play whenever enterprise applications require the support of your data center infrastructure – things like identity services, naming services, and access to internal databases and other resources. Because of this, your cloud resources need a way to connect to your data center, of which the easiest approach is a VPN. In building this solution, you need to design for routing to the cloud and provide a method for cloud applications to “reach back” to the applications and services running in your data center. Ideally, this connection would allow Layer-2 connectivity because a number of services require this level to function properly.
To wrap up this segment, networking, like storage, is a very important part of your IT infrastructure, and the cloud adds a number of interesting new variables to the design and operation of your data center environment. What’s needed is a well-constructed architecture and a good understanding of the limitations imposed by the cloud if you want to integrate successfully with the public clouds. Today, this can be a major barrier to cloud adoption since enterprises are understandably reluctant to re-architect their network environments or become knowledgeable about the complexities of each cloud provider’s underlying infrastructure. When designing your cloud strategy, make sure to select a migration path that addresses these issues and protects you from costly engineering projects and cloud risks.
Next: Key Considerations for Cloud Management
RSS Feed