Think network architecture, not more bandwidth
More bandwidth is always beneficial, but it is no longer a networking panacea.
At last week's Interop shindig, Cisco Systems annual walk-about keynote presentation focused on "Web 2.0 creep" and its impact on the network. According to Chambers, enterprises will adopt Web 2.0 tools like blogs, wikis and Web video and bring today's networks to their knees in the process.
While I believe that the enterprise Web 2.0 trend is in its early genesis phase, I tend to agree with Mr. Chambers' hypothesis.
Enterprise networks have grown organically over the past 15 years--a switch here, more port capacity over there, add a wireless access point, etc. The design criteria were simple: extend the network and move packets as quickly as possible. Any problem along the way was easily solved by adding more bandwidth.
This formula was effective in the old client/server days, but it doesn't cut it anymore. Why? Applications are designed across multiple loosely coupled tiers and delivered over IP-based protocols to users anywhere in the world. We've already seen the performance problems that poorly written applications can cause across WAN links. Large IT organizations now have "application delivery" departments, while A10 Networks, Citrix, F5 and Packeteer are making tons of money in the fast-growing WAN optimization market. Multiply today's problems with a whole bunch of rich content and everything could come to a grinding halt.
In effect, Chambers is saying that today's network architecture problems are just the tip of the iceberg and although Cisco stands to benefit greatly, his message isn't hype. Now that "the network is the computer," enterprises need to think long and hard about how those networks will accommodate a whole bunch of burgeoning services and applications.
More bandwidth is always beneficial, but it is no longer a networking panacea. If we want to add complex network-based applications, we better be ready with an appropriate network architecture.