Cloud Networking
Blended Cloud Environments – A Financial Services Use Case
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Damon Miller, Director of Technical Field Services
One of the most interesting trends in cloud computing is the emergence of “hybrid” solutions which span environments that were historically isolated from one another. A traditional data center offers finite capacity in support of business applications, but it is ultimately limited by obvious constraints (physical space, power, cooling, etc.). Virtualization has extended the runway a bit, effectively increasing density within the data center, however the physical limits remain. Cloud computing opens the door to huge pools of computing capacity worldwide. This “infinite” capacity is proving tremendously compelling to IT organizations, providing on-demand access to resources to meet short and long-term needs. The emerging challenge is integration—combining these disparate environments to provide a seamless and secure platform for computing services. CloudSwitch provides a software solution that allows users to extend a data center environment into the public cloud securely without modification of workloads or network configurations. I’d like to discuss a specific example of how CloudSwitch delivered a solution which spanned environments in a corporate data center and external cloud.
A large financial services company approached us some time ago with an ambitious plan to leverage cloud computing as a strategic initiative within the organization. Their goals were to reduce operating costs, improve responsiveness to the various business units, and differentiate themselves within the industry through technological innovation. Security was a fundamental requirement and a number of risk assessment groups were involved throughout the design and evaluation phases of the engagement. Finally, this company also wanted to leverage a traditional colo environment from their cloud vendor to provide high-speed access to shared storage while also supporting their traffic monitoring equipment. After a period of technical diligence, we established a reference architecture which satisfied all internal security requirements while remaining true to the fundamental goal of moving to a dynamic cloud environment. The result was a true realization of the hybrid model.
In the customer’s reference architecture, there are three primary components:
- Internal data center environment hosting the CloudSwitch Appliance (CSA)
- Private colo environment hosting the CloudSwitch Instance (CSI) and CloudSwitch Datapath (CSD) as well as shared storage for cloud instances
- Public cloud environment hosting customer workloads
The CloudSwitch Appliance is deployed into the customer’s data center environment to allow central management of one or more colo environments. Each of these environments supports an isolated cloud deployment, for example for a particular business unit. CloudSwitch’s virtual switch and bridge components are implemented for high-speed connectivity between cloud servers and shared storage. Finally, the public cloud environment is used to host actual customer workloads (operating systems). Network communication and local storage are protected through CloudSwitch’s secure overlay network and transparent disk encryption functionality.
This approach yields several benefits:
- Multiple instances of this dedicated environment can be independently deployed to support different business units
- High-speed access to the enterprise cloud environment is available since the colo environment is physically located in the same facility
- Physical infrastructure can be deployed into the colo environment in support of cloud servers—for example, shared storage devices
- Dedicated firewalls can be deployed and traffic inspection is possible, satisfying the security groups’ requirements
The reference architecture supports the organization’s high-level goals while remaining compliant with all existing security and regulatory requirements. Cloud servers have high-speed access to shared storage as a result of the colo deployment alongside the public cloud environment. All network traffic and storage is encrypted automatically through CloudSwitch’s security capabilities, and through CloudSwitch’s role-based access controls (RBAC) the security team has centralized control over who is able to access each cloud environment. The end result is a deployment model which truly implements a hybrid environment combining resources from the public cloud with traditional colo resources to deliver a secure, scalable platform for dynamic computing.
Top 5 Questions Asked by CloudSwitch Customers
By Dave Armlin, Director of Customer Support
New CloudSwitch customers and prospects are coming up to speed every week and there are a number of questions that show up frequently enough that I thought it would be helpful to cover them in a blog. When we work with customers, our goal is to make their experience getting started in the cloud fast and easy, and to make sure they feel comfortable with the ongoing simplicity and security of the CloudSwitch model.
Here are their top 5 questions:
1. How do I move applications to the cloud?
CloudSwitch literally makes moving an application to the cloud a simple drag-and-drop operation. A virtual machine (or group of VMs) is selected from a VM location (vCenter,ESX machine, or CIFS share) in the CloudSwitch user interface, the target public cloud region/zone/location is selected, and the machine is moved over a secure tunnel to the cloud. Storage for the virtual machine in the cloud is automatically allocated and encrypted, and keys are kept under the customer’s control.
Virtual machines that are moved to the cloud retain their MAC and IP addresses, since the CloudSwitch appliance acts as a layer-2 bridge allowing these machines to appear as if they are running in the data center behind your firewall.
2. What applications should I move to the cloud?
A wide variety of apps are good candidates to be moved to the cloud. As Ellen Rubin blogged about recently, legacy applications are certainly great candidates for offloading from your internal data centers. Web servers and web applications like SharePoint, .NET, J2EE/SOA, Drupal, Wordpress, Wikis, corporate intranets, or batch processing applications are all good candidates as well.
When selecting applications for the cloud, you need to be aware of latency between the data center and the cloud. Latency is a function of physical distance between the data center and the cloud region you’ve selected. For instance, a data center on the East Coast in the US should see around 20ms latency between the various public cloud regions on the East Coast.
Select applications and place them in closest proximity to the virtual machines and data center services that are accessed most by these applications. For instance, a web application that utilizes a database heavily may perform best if the web tier and the database are both deployed to the same cloud and region. A web application that utilizes a database infrequently and caches results may perform well with the database in the data center and the web tier in the cloud.
3. What changes to my network do I have to make to use CloudSwitch?
Minimal. Outbound port 443 to the Internet has to be opened for the CloudSwitch appliance to create a secure encrypted connection to the cloud. This is outbound traffic only, nothing inbound. There are no changes to your network configurations.
The CloudSwitch appliance requires promiscuous mode and forged transmits set to “Allow” on the Virtual Switch or Port Group for the network adapter assigned to CloudSwitch in your virtual environment. For more information, check out this blog article on networking and ESX.
4. Can I get a virtual physical console to my machine in the cloud?
Yes. CloudSwitch provides a virtual console accessible from the CloudSwitch user interface via a browser that allows you to interact with the base system to make network changes or other tasks one might perform at a physical console. Access to this console can be secured to specific users or groups using Role-Based Access Controls (RBAC) in the CloudSwitch user interface.
5. Can I allow traffic from the Internet reach my machines in the cloud directly as opposed to going through my corporate firewall?
Yes, CloudSwitch supplies a cloud firewall that allows you to assign a public IP to a virtual machine and control access to VMs in the cloud from the Internet. Pavan Pant, our Director of Product Management, blogged about this a while back. You have full configurability for permissions/access to all cloud resources through this firewall.
In-Path WAN Optimization for your Cloud Deployments with CloudSwitch and Riverbed
By Pavan Pant
As our enterprise customers embrace the cloud, we’ve been hearing a growing demand to help them optimize enterprise network connectivity as they scale their cloud deployments. At CloudSwitch, we’ve been thinking about the issue of network optimization for quite some time now and working with partners like Riverbed to tackle network performance in the cloud.
Today we are pleased to announce our support for Riverbed’s Cloud Steelhead® to help customers optimize their hybrid cloud deployments. Many of our existing customers have already invested in Riverbed infrastructure in their data centers, and want to extend these trusted resources into the cloud. The primary drivers for WAN optimization in hybrid cloud architectures are twofold:
- Improving network performance between data centers and the cloud for better end-user experience
- Reducing bandwidth between the data center and the cloud, thereby reducing cloud costs
In a hybrid model the public cloud acts as a remote data center, making infrastructure resources available to distributed teams of users, but requiring connectivity back to corporate data center resources. Riverbed’s WAN optimization technology can reduce bandwidth requirements and accelerate a number of applications and protocols including Windows file shares, NFS servers and Oracle forms. Riverbed’s innovations in data compression, de-duplication, and other techniques enable much more efficient data movement between customer data centers and the cloud, while freeing up bandwidth for other applications. In our testing we have seen anywhere from a 5 to 100x improvement in your application’s performance, and 60-80% reduction in bandwidth costs.
Simple and Secure Deployment in the Cloud
Our joint solution allows customers to easily select Riverbed’s Cloud Steelhead from CloudSwitch’s network library and launch it unmodified in the Amazon EC2 and Terremark clouds. The user can simply select the cloud networks they would like to optimize, and the Riverbed appliances will take it from there – automatically selecting the network traffic and applications to optimize.
Once Riverbed’s Cloud Steelhead is running in the cloud on CloudSwitch’s isolation technology, customers simply enable automatic peering through Riverbed’s user interface. This ensures that network traffic is optimized as soon as servers in the data center try to communicate with servers in the cloud or vice-versa. In addition, CloudSwitch ensures that all communication and data are automatically encrypted so that your extension of infrastructure into the cloud is always protected, end to end.
CloudSwitch allows Cloud Steelhead to be deployed in-path so that all network traffic on the optimized LAN for your servers in the cloud runs through Cloud Steelhead. This allows the WAN optimizer to accelerate cloud traffic automatically without requiring any additional modifications (no agent installations, no drivers, no changes) to your servers in the cloud. This is the unique advantage CloudSwitch offers– simplicity, security, and the ability to offer WAN optimization with full configurability and control by the enterprise.
Our mission at CloudSwitch has always been to make it easy and secure for customers to launch virtual machines in the cloud. Last year, we enabled public IP access to cloud resources by adding an open-source firewall to our network appliances library. As we learn more from our customers about their requirements, we continue to build our library of partner offerings, demonstrating the strength of our platform and our ability to act as a cloud gateway. We’re excited to support Riverbed’s Cloud Steelhead and are hard at work integrating with market-leading firewalls, load balancers, storage appliances and other devices. Our software lets joint customers easily deploy these virtual appliances in the cloud with secure, in-path configurations to enable much more efficient data movement and scalability in the cloud.
To learn more about how enterprise customers are optimizing the cloud today, please join our upcoming webinar with Riverbed, “Optimizing Your WAN Connectivity for Hybrid Cloud Deployments.”
CloudSwitch + Amazon's VPC = Full Encryption and Isolation in the EC2 Cloud
Today, Amazon announced a new version of their Virtual Private Cloud (VPC) offering. This move reflected the learning and requirements from enterprise customers who have tested or deployed VPC over the past year. Initially, VPC was developed to provide a secure tunnel (layer-3) from the customer’s data center to EC2, to make it easier to receive the approval of internal security groups for cloud deployments. Customers had noted that there were many aspects of VPC they felt could be enhanced, primarily around making the networking options more sophisticated and flexible. As Jeff Barr noted in his blog on the new release, a major focus was to enable public-IP access through a cloud-based firewall/load balancer to the cloud VMs. We’re glad to see this new set of capabilities, since we had definitely heard this requirement from customers as well, and responded to it last year.
We’re excited to support customers and prospects who are interested in evaluating the latest version of VPC and integrating it into their EC2 deployments. We believe that together, CloudSwitch’s award-winning software and Amazon’s VPC offering deliver enterprise-class security and integration with customers’ internal data centers and private clouds. CloudSwitch provides full encryption of all data and communications, and lets you extend your enterprise network topologies into the cloud without modifications. This means that your entire cloud deployment is secured end-to-end, and remains completely under your control, as if it were running locally behind your firewall.
It’s great to see Amazon’s ongoing commitment to innovation and to work with joint customers who want to make the cloud a truly secure extension of their internal environments.
Provisioning in the Cloud with Point-and-Click Simplicity Using Your Existing Data Center Tools
By Pavan Pant
Releasing CloudSwitch 2.0 was a great way to close out 2010 and build momentum for 2011. As part of that announcement we discussed some great new capabilities and improvements in Enterprise 2.0 that were driven by our customers’ use cases as they move to the cloud. It was no surprise to us that amongst all the great features in 2.0, the most popular by far has been our ability to provision virtual machines in the cloud. We have heard about many cases where customers have expressed an interest in provisioning applications in the cloud just as they would in the data center using their gold images as opposed to being constrained by a cloud provider’s options, which did not always meet their specific needs.
The clear message we heard was that customers wanted to be in control of the virtual machines that were provisioned in the cloud while making sure their servers were secure and connected back to the data center to communicate with their DHCP infrastructure, DNS, identity management, etc. They wanted the ability to create a virtual machine from scratch and provision their application stack on it by using their gold ISOs, or by booting from a PXE server. There were also a handful of customers who were interested in saving bandwidth when migrating to the cloud by creating servers directly in the cloud.
With CloudSwitch Enterprise 2.0, customers can now provision virtual machines in the cloud following the same process that they would in the data center using tools they are familiar with. Our user interface allows customers to provision in the cloud with point-and-click simplicity by configuring virtual machine parameters such as the operating system, memory, number of disks, storage controllers, network settings and boot options to provision your application stack in the cloud.
We have designed an intuitive, wizard-based process to provision virtual machines in the cloud. You could start off by booting a provisioned server using an ISO from CloudSwitch’s library which includes popular Linux and Windows distributions, or upload your gold image and boot from that. Other options include booting from a network source such as a PXE server, and referencing an ISO image from a HTTP server such as a mirror server.
Figure 1: Specify Boot Source
Much like the process of provisioning virtual machines in your data center you can set your SCSI controller types for the guest operating system, and even specify the boot order for your virtual machines in the cloud. As an example, if you wanted to provision from a PXE server CloudSwitch allows you to set the boot order as CDROM followed by Hard Disk and Network so that once you have booted from the PXE server the next time the server restarts it will simply boot from the hard disk.
Figure 2: Specify Boot Order
You can provision as many virtual machines as required, add as many NICs as necessary, generate new MAC addresses for them, and map those NICs to networks. The final step in the provisioning wizard uses our CloudFit™ function that allows customers to select any combination of a cloud provider’s instance sizes to customize the cores, memory, storage, compute capacity and region before you provision in the cloud. CloudSwitch also provides console access to the keyboard and display of your server in the cloud so you can administer systems just as you would in your data center.
Figure 3: Networking Configuration (click image to enlarge)
All these features give you the freedom to create new virtual machines in the cloud without having to change other data center services such as DHCP, DNS, networking configurations, identity management, etc. Once you have provisioned your application stack in the cloud using CloudSwitch you can also move these workloads to the different regions and zones your cloud provider offers, across cloud providers or back to your data center without making any changes to the application or to your existing data center tools.
It’s as simple as a few clicks in our user interface to configure your server parameters, provision as many servers as you need, use them as long as you want and then shut them down. That’s the flexibility the cloud offers, and CloudSwitch is committed to helping customers handle hybrid cloud scenarios seamlessly and securely without requiring any changes to their applications or underlying infrastructure while using their existing data center tools. Provisioning in the cloud is yet another step towards that goal so go ahead and get our enterprise trial version today to get started. We’re continuously enhancing our software to ensure everything “just works” transparently for enterprises in the cloud.
After Security, Network Bandwidth is the Next Cloud Bottleneck
By Ellen Rubin
Security concerns (real and imagined) have long dominated much of the cloud conversation and caused many companies to deliberate about getting started in the cloud. Slowly, the security issues are being addressed--through the adoption of corporate policies for cloud usage, maturing cloud provider offerings, and by technologies such as CloudSwitch which isolate and encrypt all cloud resources to meet the requirements of the CSO. But while the focus has been on cloud security, another potential bottleneck is on the horizon as companies start using the cloud in more substantial ways.
In our discussions with IT executives and their teams, we’ve been hearing about a new concern: the ability of corporate networks to handle cloud traffic. Network performance is a lurking issue that hasn’t yet received the attention it deserves. That’s understandable, since bandwidth is rarely a problem for companies exploring the cloud in a small way, where they may deploy a few experimental VMs in order to understand the process. But as they start expanding their cloud footprint and running production-oriented applications, data movement takes on a completely different scale. As enterprises start to move real workloads out to the cloud (or to straddle internal and external clouds), look for network performance to become top of mind.
IT professionals and developers often assume they have huge network capacity, and it’s probably ample for their current Internet usage or the small cloud projects they may have tried so far. But what will happen, for example, when you have dozens of developers all trying to use cloud resources? Or if you put high-transaction processes in the cloud that need to “talk back” to your data center? What if you are trying to move a lot of video or graphics between your business users and the cloud? Network usage is about to get much more demanding, and the traffic will need to flow without bottlenecks (or saturating the network) for an organization’s cloud strategy to work.
Thus potential cloud users will have to do some back-of-the-envelope analysis of the maximum bandwidth they might need and how much additional traffic the network can handle. While the data center (or internal network) is running at speeds of 1Gb and even 10Gb, the connection to the Internet is lagging behind. Today, a “good” Internet connection is considered to be in the 100Mbps range. Some companies have more, and many have less than this capability, so when extending services to the cloud, you have to consider what impact this lower speed could have, and how to deal with it.
This is actually a two-part problem. You have to consider initial data movement: how long will it take to move a terabyte of data over the Internet and into the cloud? What impact will that have on current users and your business? You also have to look at ongoing updating of that data: how much traffic will be flowing back and forth, and what will that mean for your steady state? Will you have to buy more bandwidth for the cloud to be viable? Obviously, any major new capex requirements would be a challenge for cloud adoption.
Fortunately, technologies are emerging that can help optimize your current network and avoid an expensive upgrade. For example, CloudSwitch has a public IP address capability that provides direct access to cloud resources without having to go through the enterprise data center, avoiding what could otherwise be a huge bottleneck. Rather than relying on the Internet connection to the data center, cloud deployments can take advantage of the aggregate bandwidth of end users. This CloudSwitch feature also allows enterprise firewalls and load balancing capabilities to run in the cloud so traffic can flow smoothly and securely. In addition, companies like Citrix, F5, Riverbed, and Cisco are developing software versions of their WAN optimization technologies that can be deployed in the cloud. Their innovations in compression, de-duplication, and other techniques will enable much more efficient data movement so you can make better use of the network you already have.
If you’re the head of IT or Application Development looking ahead to 2011, you probably have some great cloud pilots under your belt, and you’re evaluating moving into the cloud in production mode. Just remember that bandwidth is something you’ll need to think about and prepare for.
CloudSwitch has been thinking about these issues, and together with our partners we’re working on solutions to ensure optimum bandwidth for the cloud. Emerging technologies will allow you to meet the bandwidth demands required by production applications, so you can scale out your cloud footprints without building out your corporate network, leveraging the investments you’ve already made.
Hubs, Spokes and WANs
By 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
