Cloud Networking
Hubs, Spokes and WANs
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
Recently, we’ve had a number of discussions with enterprises about how they’d like to use the cloud. The basic use case is around capacity on-demand (not surprisingly), but the specifics have raised some interesting issues. The companies have distributed branch offices that need the capacity for a range of applications, including dev/test environments as well as back-office and web apps. Today, these distributed groups are relying on corporate IT to meet their scaling and infrastructure needs, and they are frequently bottlenecked. This is both in terms of overall challenges in getting new capacity approved in a timely way, but also from a network bandwidth perspective. At a panel this week at Interop, Riverbed noted that 2/3 of their enterprise customers have a hub and spoke model that requires the “spokes” to backhaul to the “hub” for connectivity to the internet, and thus to cloud computing services. Only the remaining 1/3 have direct connections. At the same panel, Blue Coat agreed with the stats but commented that the branch sites are trending towards a direct-connect model as new sites are added.
All this is interesting to us at CloudSwitch since we have been hearing more and more frequently from enterprises that want more “edge” computing, and to empower the branch offices to add capacity on-demand in a controlled but self-service way. This creates a set of new requirements around cloud computing, in terms of both networking and security. In the hub and spoke model, corporate IT maintains control over all access to the cloud, which has benefits on the security and permissions side, but creates potential bottlenecks – both in terms of the need for self-service management tools to increase agility, as well as in bandwidth constraints where the backhaul traffic starts to strain the corporate networks. Backhauling also creates strain on the branch offices since it often adds significant latency to their internet connections.
Most of the vendors at the Interop panel (including Akamai, Riverbed, Ipanema and Blue Coat) claimed to be developing or are already offering WAN optimization products – increasingly in the form of virtual appliances and/or software versions – to help alleviate these bottlenecks. These will surely help, but will become even more important as the branch offices start to have more direct connectivity to the cloud. WAN optimization offerings at the “edge” will be increasingly needed, and cloud service providers are focused on building out these capabilities at their end of the network. Security in a more distributed model will also require some new thinking, since users in the branches will want to maximize flexibility and agility, while corporate IT will still need a way to limit potential threats and exposure created by opening these direct connections.
Underlying all these discussions is the fundamental issue of the laws of physics. As enterprises start to embrace the cloud model, they’ve realized that the major choke-point will be their network bandwidth. Innovation around addressing these issues, especially in the virtualized world of the cloud, will definitely be required. At CloudSwitch, we’re staying closely involved in discussions around customer requirements and vendor offerings to increase performance for workloads moving to the cloud.
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.
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
