Networking in the (Storm) Clouds

How do we connect to SaaS, IaaS, StaaS?

Johna Till Johnson wrote a very good column this week on cloud computing and networking; something that's been on my mind lately as "Cloud Computing" gets more and more buzz not just in the industry, but also at my IT shop. As many of you are aware, "cloud" means many things. I tend to define it as three things:

  • SaaS - software as a service. Using a cloud to run a specific application, let's say SAP.
  • IaaS - infrastructure as a service. Large compute farms you can "rent out" section of to run whatever you want. Amazon's EC2 falls in this category.
  • StaaS - storage as a service - hosting your storage infrastructure (NAS, SAN, etc) in a cloud. I call this one out separately from IaaS since it is inherently different from compute (IaaS) and has much bigger bandwidth impacts. Obviously, it can be provided as part of IaaS, but can be separate too.

To a CIO and application groups, cloud computing sounds like nirvana. To them the words are: - Turn fixed costs (which you can't get rid of in a bad economy) into variables costs (which you can get rid of in a bad economy). - Reduce software capitalization costs on new projects and installations. - Reduce the time to get new infrastructure resources (servers) for applications from weeks to hours. - Eliminate a big chunk of the staff you have running all this stuff in house (app developers, support staffs, sys admins, network engineers, etc.). - Eliminate the time spent on capital investment budgeting and planning (this takes up a significant portion of an executive's time). - Stop wasting real estate (maybe office space) on data centers. - Require the cloud to maintain operating system levels and patches under SLA. The problem is the devil is in the details. The network is one of those details. But, since most CIOs are worried about business process issues, budgets, and applications they understandably don't have time to care about the network. He/she just wants it to work. But, us network engineers get to "make it work".


First, a cloud could require a lot of bandwidth. Clouds replace, or augment, current data centers. Current data centers are where the biggest links are because all the users are going there for the data. In a theoretical world, one might say this is a wash. As stuff moves from the current data center to the cloud it's a one-to-one move of bandwidth. Yeah, sure. Bandwidth it sticky and hard to reduce without strong metrics. For the foreseeable future, you will pay for bandwidth in full at your current data center and to the new cloud. Moving a few apps to SaaS or hosting a compute environment is not going to reduce the bandwidth need in a quantifiable form. Furthermore, I would argue clouds could take more bandwidth. In all enterprise data centers there is a huge amount of application integration traffic - SAP CRM talking to Oracle Financials which updates the sales application. None of this leaves the data center to a user. Currently, all that integration traffic runs over an overprovisioned 10 Gbps LAN. No problems there. But, now move SAP CRM to SaaS. The integration is still required, but now the 30 TB SAP database is over the WAN in some cloud. Finally, there is the storage component. Whether you are using IaaS with its inherent storage infrastructure or StaaS, the data has to be backed up. Do you trust your brand new cloud provider to completely backup all of your data, with simple restoration, following all laws and data retention policies? Probably not. You're going to copy a lot of that cloud data back to your own data center for safe keeping. So, we end up with:

Total Bandwidth = User Bandwidth to the Cloud + Integration Traffic to the Cloud + Backups.

In a 10 Gbps LAN, this is not a problem....over the WAN to a cloud......uh huh.


After you solve the bandwidth issue, you have the network security issues. As Johna points out a lot of this cloud integration is over the Internet. First, that means encrypting all of this traffic, possibly from many end-points if your users communicate directly with the cloud. Next, and more difficult, are the network security traffic policies for the integration traffic. Let's be honest, application teams do not know the 36 TCP ports their applications use to communicate with each other. To them, it just works in the non-firewalled, internal data center. Why wouldn't it work with a cloud over the Internet? Ugh. Getting the bi-directional firewall policies done correctly, with the required encryption, will be a major pain. Also, don't expect to own the firewall on the cloud end (this is a "service" after all), so you will be working with cloud IT teams to get the firewall policies correct on both ends. This is often one of the hardest and longest issues we deal with when connecting to partners via our current extranet. And, any mistaken changes while in production can cause harmful outages. But, let's say you get lucky and buy cloud services that can connect via your private WAN service (MPLS based IP VPNs let's say). Do you still trust that cloud provider enough to not use firewalls? In a shared compute environment, how do they segment and isolate different customers? What is the cloud providers own security policies that you are signing as part of the contract? Even in these private networking cases, I still a lot of network security infrastructure required.


There are four more areas to address in this rant...err...list of issues about networking and cloud computing. I'll cover them next week.

More >From the Field blog entries:

How to Save Some $$$s - Keep Competition in Your Network

You Knew I Had to Comment on the Cisco Certified Architect Program

Happy 2-Year Anniversary - A Reminder to Focus on What's Really Important in Network Engineering

Using FCAPS for IP Telephony Management

Not a Lot of Excitement for Networkers This Year?

Cisco ASA IP Phone Proxy - My New BFF

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)