Think network architecture, not more bandwidth
At last week's Interop shindig, Cisco Systems CEO John Chambers' 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.
John Chambers
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.
Jon Oltsik is a senior analyst at the Enterprise Strategy Group. He is not an employee of CNET.
All of these things are affected similarly by the nature of Web 2.0 applications. How can you provide for reliable, fast and secure transmission of data when you don?t control the date itself? No matter what you do to your bandwidth, your security or your availability to the outside world if the service you want/need isn?t architected with the same goals, your mash-up will suffer; and multiply that by the number of service objects in your application. To make matters worse, you don?t even necessarily control the protocols used. Sure you can make a request using XML, but can you be sure the response will be in the same format? Did you account for that format when you were doing all of your application delivery architecture?
Lastly, if you look at that last paragraph you?ll see that we are dealing with another mash-up in this whole business; applications and networks are now inseparable. You can?t even pretend that they aren?t. Anyone who doesn?t acknowledge that should simply be dismissed and not invited to the party. So I would modify your comment about ?network architecture? to suggest that it fully includes application architecture as well. Maybe ?Application Delivery Architecture?; or ?Application Network Architecture?; how about ?AppWorking??