The Antikythera mechanism was discovered on 17 May 1902, when archaeologist Valerios Stais noticed that a piece of rock recovered from the Antikythera wreck had a gear wheel embedded in it. Examination revealed that the "rock" was in fact a heavily encrusted and corroded mechanism that had survived the shipwreck in three main parts, and dozens of smaller fragments. It was inscribed with a text of over 3,000 characters, most of which have only recently been deciphered. These were part of a manual, which describes how to set up the instrument and how to use it for observations, with references to the Sun, the motion of the planets (stationary points), Aphrodite (Venus), Hermes (Mercury), and eclipses.

It is evidence that the ancient Greeks of 100 B.C.E. had access to mechanical clockwork technology not rediscovered until the 1700s. It is considered the “first computer.”

And now, the story of the Antikythera Network, with equal parts fact, historical accuracy, and pizza.

Dr. Tim Wu has recently penned an editorial to the New York Times entitled “OPEC 2.0.” which argues that we need an alternative source of bandwidth much like we need alternative sources of energy.

It’s the sort of editorial which causes other tech columnists and blog editors to immediately loathe themselves because it’s obvious in retrospect, but Dr. Wu thought of it first.

Just as the industrial revolution depended on oil and other energy sources, the information revolution is fueled by bandwidth. If we aren’t careful, we’re going to repeat the history of the oil industry by creating a bandwidth cartel.

Like energy, bandwidth is an essential economic input. You can’t run an engine without gas, or a cellphone without bandwidth. Both are also resources controlled by a tight group of producers, whether oil companies and Middle Eastern nations or communications companies like AT&T, Comcast and Vodafone. That’s why, as with energy, we need to develop alternative sources of bandwidth.

Pointing out that the average American spends roughly the same amount of money for bandwidth of some form or another, whether on their cellphones, land-line phones, cable TV, broadband Internet, etc., as they do on heating, cooling, electricity, and gasoline, Wu makes the case that we need the data equivalent of the compost garden, rooftop solar panel, and electric scooter.

The difference, of course, is that while rooftop solar panels have recently started to be affordable on a per-wattage basis, Wu’s suggestion of “running your own fiber to your home” isn’t. Even if you did put down your own last-mile fiber, you still need some place to connect it to… the whole point is that the value of a network is equal to the number of end-points on the network, squared.

The other solutions Wu suggests: re-allocation of the EM spectrum, municipal fiber as a public utility, and increasing the amount of competition are all more practical ideas, but they require significant changes in governmental policy – the same government elected from a two party system where the two parties are both heavily influenced by broadband providers and telecommunications companies.

But Wu is not wrong in identifying a significant problem – especially since e-mail, telecommuting, and teleconferencing are all considered important ways to reduce energy expenditure. It is disheartening to believe that we’re simply switching from one artificially overpriced commodity to another.

Damn. Well, I guess there’s no way around it then. Looks like we’ll have to recreate the Internet from scratch by hooking up everyone to self-installed network connections. So what do you say, you lay the fiber if I use the backhoe?

Earlier today, Network World hosted a live chat with Jim Metzler, of Ashton, Metzler, and Associates on implementing WAN acceleration. They’ll have the full transcript up tomorrow on their site, but I attended and wanted to bring back a few highlights. 

-----

Question: What is the one question that should be asked when evaluating products that you don't see people asking?

Jim Metzler: One thing that I think that people should ask: What has gone wrong in previous deployments?  We have all been around long enough to know that things do tend to go wrong at least occasionally.  For example, some people have found that once they deploy a WAN optimization controller (WOC,) that they lose management visibility.

Question: We are constantly battling latency across our MPLS network.  We have retail stores that connect to HQ data center.  How do we improve WAN performance?  Do we need to implement QoS?  Or should we use a different WAN protocol for our Cisco routers?

Jim: MPLS comes along with service classes that promises a guaranteed latency.  For example, a given service class may promise that latency will not exceed 50ms.  If your problem is that you are not getting what you were promised, that is an issue to take up with your vendor, or, based on your contract, to possibly change vendors.  If the issue is that the latency that you are promised is not good enough, I need to know more about what the problem is.  For example, if the issue is that you are running chatty protocols over the WAN, then a WAN optimization appliance might be helpful.

Question:  How do WAN optimization technologies fit into a more VIDO oriented desktop/branch and/or more XML oriented apps?

Jim: The movement to implement virtual desktops is a bit behind the movement to deploy virtual servers.  As we deploy more virtual desktops, that will mean more traffic from the data center to the branch which will most likely need optimization.

Question: How does WAN accellerationfit into scenarios with heavy ICA traffic or Notes replication traffic?

Jim: WAN acceleration is a very broad topic.  Some applications (CIFS traffic that results from server consolidation) scream out for optimization.  Other traffic (VoIP) requires QoS so that other traffic (bulk file transfers do not interfere with it.

The bottom line is that there are differing traffic types and they often require different techniques.

Question: Is there any company that has the best all-around solution?

Jim: No.Okay, my answer was intentionally brief.  Your question goes to one of the key challenges facing IT organizations today.  A given supplier might have a great solution for data replication but not so great for CIFS.  Another vendor may have a great solution for CIFS, but not so much for data replication.

This presents IT organizations with a challenge - what problems are they trying to solve today?  Next year? You have to decide.  Do you choose the best solution to today's problem knowing it might be sub-optimal for tomorrow's?

The good news here is that over time the differences between the suppliers on common functionality (compression, caching, protocol acceleration) will diminish.

Question: What question do you hear the most about this product category?

Jim: “How do I get started with evaluating these products?”  “What new directions are the gear vendors taking these products?”

With regards to WOCs: Adding support for specific applications such as share point or SAP.  Creating templates to make it easier for IT organizations to configure the device to support key applications.  Embracing virtualization.

With regards to Application Delivery Controllers (ADCs): Offering virtualized solutions, adding security functionality, adding functionality such as XML processing, Integrating with Business Intelligence tools. 

Question: Do you see distinct advantages to implementing QoS in a WOC rather than the router level? 

Jim: This is a really fundamental question.  I believe that one of the reasons that we have not implemented WOCs more broadly is that we have not answered some basic questions such as what functionality should be done where.

The question is further blurred by the fact that WOCs are being integrated into routers making it tough to say where QoS was implemented.  Bottom line: I think you can make either approach work.  It comes down to factors such as how rich is the QoS functionality in the WOC and how easy is it to configure and manage the QoS functionality in the WOC or the router.

Question: Some users claim that acceleration claims made by the vendors are bogus, that claims of 400% improvements are marketing garbage (as you can’t improve speed faster than the original base speed) What are your thoughts on speed claims by vendors?

Jim: The acceleration claims made by the vendors represent a test done in a laboratory.  While these might give some insight into how the devices will perform in production networks, they are not definitive.  IT organizations must test the devices in their network to understand what types of improvements they will realize. 

Question: Any thought on masking poor application architectures with WOC or ADC products?

Jim: This is a hot button to me!

For example, most IT organizations do not spend much attention on how apps will perform over the WAN during development or acquisitions.

A lot of our current problems would go away if apps were designed to run better over the WAN.

For example, one company I worked with found out that the browser in the branch offices were downloading a 3MB file just to open it up and extract a 10 digit ID.  Talk about a badly designed application!

Question: Where is the next big thing: security, storage, or--?

Jim: I think that there will be a lot of next big things.  I recently wore a series of articles for Network World in which I described "The Perfect Storm." 

Let me explain.  Today over half of the outages occur based on ineffective change or configuration management.  once we move to an environment with a virtualized desktop, routers running VMs running all kinds of things, communicating with a virtualized application delivery controller (ADC) that front ends a Web server, app server and database server, all of which are virtualized and which use virtualized storage, then the situation gets very thorny. 

Can you imagine how much many more outages will occur in a fully virtualized environment?

Sticking with this: Today when an application is not performing well it is difficult to identify the root cause.  That will be much more difficult in a fully virtualized environment. 

SOA really worries me.  By SOA, I mean Services oriented architecture.  Some think SOA is the precursor to an SOB and they may be right.

With an SOA, an application is comprised of multiple web services - for the sake of example - say 8.  Now, these Web services are running in different data centers - say 5.

Now the WAN impacts that application performance many more times than it does in today's n-tier applications.  This will be a huge challenge, but it gets worse - these Web services are reusable.

That means that multiple apps are using the same web services at the same time - that drives the need for QoS for Web services

This is all extremely demanding. 

Then there is Web 2.0 and mashups. With a Mashup your app is using apps designed and managed by other entities.  You have no control or visibility into those other apps.  This will be extremely challenging.

This blog post is about the integration of metrics from multiple F5 devices into the NetQoS Performance Center. When researching this article, I found out that this means that NetQoS Performance Center can import performance metrics from F5 Networks BIG-IP Local Traffic Manager and BIG-IP Global Traffic Manager, which provide services for managing application security, application acceleration, and network availability. However, I was disappointed to learn that this integration has nothing to do with F5, the heavy metal band that features former Megadeth bassist Davide Ellefson and drummer Jimmy DeGrasso.

Instead of logging into individual F5 devices for performance information, IT personnel can get visibility into f5 metrics through a single console without needing f5 administrative capabilities or a bowl of M&Ms with the brown ones removed.

By integrating with F5, NetQoS can help simplify the increasingly complex challenge of monitoring network and application performance across an organization. For joint customers this means a single view into an unlimited number of F5 devices and detailed performance metrics delivered in real time through the NetQoS Performance Center.

So while this integration will help more quickly address network problems and improve application delivery – with the Performance Center’s analysis and alerting capabilities combined with the F5 reporting – it will not, by any stretch of the imagination, produce a technically expert melodic bass solo at any time.

The combination enables IT professionals to better plan investments in new content delivery hardware, accurately size and configure new IT deployments, verify the impact investments have on application delivery, and solve performance issues in complex data center environments, but will not be included on a compilation CD with Rob Zombie, Queensryche, Metal Church, et. al.

NetQoS demonstrated the integration at the F5 Partner Summit (not to be confused with Ozzfest) yesterday in New Orleans.

Popular Mechanics recently published an article talking about one of the things that frustrates knowledgeable HDTV owners and merely confuses not-so-knowledgeable ones. There is no standard for the amount of acceptable compression on an HDTV signal.

As it turns out, television bandwidth (in the electromagnetic spectrum sense) is very closely related to television bandwidth (in the throughput sense.)

Compression is used to deliver multiple HD channels – the higher the compression, the more channels you can fit either into your slice of the EM spectrum, your satellite bandwidth, or your cable service, you know, whatever multi-billion dollar communications infrastructure you have lying around.

The problem is that in order to deliver more HD channels, some companies apply a level of compression that is destructive to image quality, reducing fine detail and introducing compression artifacts – those magic rectangular blobs you would get from, say, an overcompressed XviD.

In fact, there's no real regulation over high-definition picture quality at all—"none whatsoever," one industry consultant told me. … After all, 1080 lines of poor-quality pixels may technically be "high-definition," but that doesn't mean it looks very good.

One of the most important factors in determining picture quality is bit rate, or how much video and audio data is being sent down the pipe for each program. The technology behind digital television relies heavily on digital compression, and the ATSC specifies that digital TV use the MPEG-2 compression standard, which is also utilized by DVDs, although some satellite broadcasters use the more efficient MPEG-4 advanced video coding (AVC) standard. These compression technologies are necessary in order to deliver a large number of channels to consumers. Without these codecs, an uncompressed HD video stream could require as much as 1 gigabit per second of data capacity—that's 52 times the capacity of the average broadcast channel. With compression, the same stream can be shrunk almost infinitely. But compression is often used overzealously, and picture quality suffers as a result.

In fact, the end picture quality can be so poor that it defeats the very purpose of broadcasting in HD to begin with, as poster “Bfdtv” showed through a series of screenshots on the AVS Forum.

The problem with determining the point at which compression significantly degrades the “quality of television experience” is a highly subjective measure, and differs not only from person to person, but from content to content – high compression is probably fine for talking-head news shows with little movement, but not very good for sports, for example. Crime drama shows might fall somewhere in the middle. Some measure of compression is obviously acceptable, otherwise YouTube, iTunes shows, and yes, pirated movies and TV shows wouldn’t be popular.

I asked Robert Zitter, HBO's chief technical officer, what his company's requirements were. "We do a contractual relationship with all of our distributors, and one of the items that's addressed in there is what they can and cannot do with our signal," he says. "But much of it cannot be quantified. There's not a device that's made that can look at a picture and say pass or fail. We all wish we had it—it would make the negotiations a lot easier. Ultimately, it winds up being more subjective than quantifiable."

I think Zitter may be wrong, however. While this is a difficult problem, it is not necessarily an unsolvable one. We already have a system in place for measuring another “subjective” thing in a “quantifiable way” - voice call quality.

Voice call quality, which is also a “subjective” measurement, is now something that is calculated in VoIP deployments as a Mean Opinion Score [MOS]. Today we can derive the MOS and the subjective end-user experience by tracking all the packet drops, latency, jitter, and general network quality of a VoIP call. MOS for picture quality determined from the amount of macroblocked pixels, the compression rate, and the effective level of detail isn’t far off into the future.

You could say that San Franicsco had a network security issue, but that’s really not accurate. San Francisco’s network was secure. It’s just that it was secured against the wrong people.

Though the San Francisco story of Terry Childs is nearing a conclusion, it’s important to look back at this and see what lessons we can learn from it. Quite frankly, being able to learn something from it seems the only upside to this debacle.

If you’re not familiar with the story, Terry Childs was a network administrator for the City of San Francisco. He built the network from the ground up, maintained it, and was the sole rights manager for the network. But Childs supposedly felt so protective of his network that he allegedly decided not to give out those root passwords, configuration changes, and documentation after he was dismissed to colleagues that his lawyer claims: “had in the past maliciously damaged the system themselves, hindered his ability to maintain it, and shown complete indifference to maintaining it themselves.”

In other words, the network was Childs’ baby, and he wasn’t about to give it up to people he thought incompetent.

According to ComputerWorld, this situation is not rare in IT:

"Unfortunately, it is not that uncommon to come into a situation where one or two people have created a situation where not only are they the only ones that know what is going on, but they are the only ones that can do anything," said Lou Michael, director of network and infrastructure services in Virginia's Arlington County department of technology services.

The issue isn't just control over passwords, but also over documentation relating to configurations and changes. Often in situations such as this, "requests for access, passwords and documentation are frequently taken as hostile acts by those that have been holding the keys to the kingdom," he added. "In my experience, I have encountered this type of situation on more than one occasion," he said. In one incident, a mainframe systems programmer had to be fired for changing access rights because he disapproved of others' activities on the system, Michael said. In another case, the individual resigned when he "realized that the pressure to follow processes and procedures was not going to go away despite the protesting," Michael said.

In IT we do have a tendency to form attachments to the tools of our trade. It can be difficult, as network engineers know themselves to be artists and the maintainers of a complex system, one in which balance and perfection are key.

The grand irony is that much of what IT does is invisible to most people in the company, and the rest of what IT does is incomprehensible to most people in the company. Even if they see the grand opus, they don’t recognize it for the masterpiece that it is. Pigeons crapping on sculpture.

We’ve mentioned before the mistrust that occurs between network and application engineers and management, and how it can be a hard sell to give management even high level visibility into network performance. But network engineers need to also realize their role of supporting the business and help break down the silos between them and everyone else.

Otherwise, you end up with situations like the one that happened in San Francisco.

Kim Shorb, Product Manager at NetQoS, and Jeff Hicks, NetQoS VoIP Architect, will be hosting a live Webcast on Tuesday, August 12^th at 10:00 a.m. Pacific time.  They’ll be talking about how to obtain metrics on call signaling and setup protocols, how to gauge the quality of VoIP voice calls, how to show the impact of VoIP on existing applications (and vice versa) by looking at response times, and ensuring adequate bandwidth for VoIP traffic and other business critical applications by determining the volume of VoIP traffic across the WAN. 

As most of you probably already know, VoIP deployments demand optimal network performance to ensure an acceptable quality of experience for the end-user.  I mean, we’ve grown up with telephones our entire lives, and we know how they work, how they sound, and above all, what to expect from them.  Matching the expectations of traditional phone service is daunting because VoIP is sensitive to latency, jitter, and packet loss.  Compound that with the fact that phone service is extremely business critical for any business in the world.

Introducing VoIP apps on your network presents specific challenges. In addition, VoIP can starve out other key business applications and impact productivity. These challenges are best addressed with network-centric performance tools – yet, few VoIP applications offer integration with those tools.   

The transition from analog telephony to VoIP is unlike any upgrade you've ever performed. A VoIP deployment is a major initiative that demands optimal network performance to ensure an acceptable quality of experience for end users. There are many reasons why VoIP is so demanding.  Unlike most data applications, VoIP is sensitive to latency, jitter, and packet loss. However, few VoIP applications offer integrated management tools - the metrics and visibility required to deliver a superior VoIP quality of experience while ensuring network performance. The introduction of VoIP applications on your enterprise network presents specific challenges that can best be addressed with network-centric performance monitoring products.

Join NetQoS experts to learn how VoIP applications have evolved and why they demand optimal network performance. Find out how to take a performance-first approach to the network, and learn why this approach, based on deep insight into end-user quality of experience, will help you ensure optimal call quality.

Additionally, attendees will receive a free copy of the VoIP eBook, "Do You See What I'm Saying? Managing VoIP Quality of Experience on Your Network". This eBook details how VoIP applications work, as well as how to ensure that the applications perform on your network at the highest levels to provide optimal quality of experience to the end-user.

Recently, we did an unscientific (and really, I cannot stress that word enough) but real-world test of performance using the Ono plugin for BitTorrent client Vuze/Azureus. Our results were inconclusive.

David Choffnes, the author of the Ono plugin, responded to the test in our comments section of that article:

Regarding your results, it is difficult to run controlled experiments because even when you download the same torrent, you're doing it at different times with necessarily different swarms. My research group's evaluation is not limited by this, and we showed that performance improves *on average*.

Also note that if Ono doesn't find any nearby peers, it can't help your performance. You can see if Ono found nearby peers (and is using them) in the "Ono" plugin view … Also, the plugin's effectiveness is limited by the fact that "only" 180,000 users have installed Ono. The more people use it, the more likely you'll find nearby peers.

One last point -- even when Ono doesn't dramatically improve performance, it encourages better "Internet citizen" behavior. Why transfer data from halfway across the world when you can get the same data and (potentially better) performance from peers nearby? Ono makes it easier to do the latter, which should eventually help everyone using the Internet.

Ono is part of Aqualab, a Northwestern University computer science project researching large-scale distributed computing. Choffnes, a doctoral candidate, will present his findings at SIGCOMM next month, and his paper on the subject can be found here – which is great if you like trigonometric functions in your technical literature.

There’s also a telling paragraph which may explain why we got the results we did for our tests (other than just the random variability of different BitTorrent swarms), instead of a massive throughput boost.

In our analysis, we compare statistics from peers located by Ono (referred to as Ono-recommended peers) to those from all peers selected at random by the BitTorrent protocol, which also includes those located by Ono.

In Network Performance Daily's analysis, we compared statistics from peers located by Ono combined with peers selected at random from the BitTorrent protocol, against only peers selected at random from the BitTorrent protocol.

To determine the cosine similarity value for a peer, Ono must be able to compare its ratio maps with those of other peers. The latter information can be obtained in a number of ways: through direct exchange between peers, from distributed storage and from trackers. Ono currently supports the first two options. With direct exchange, when two peers running the Ono plugin perform their connection handshake, the peers swap ratio maps directly… Though Ono enjoys a large user base, it is still a small fraction of the total BitTorrent population. Thus Ono also attempts to perform DNS lookups on behalf of other peers that it encounters, to determine their ratio maps. This enables Ono to perform biased peer selection over a much larger set of peers, including those not running the Azureus client. From both direct exchange of ratio maps and DNS lookups, our Ono clients locate over 180, 000 peers per day using our CDN-based approach.

When Ono determines that a peer has similar redirection behavior, it attempts to bias traffic toward that peer by ensuring there is always a connection to it, which minimizes the time that the peer is choked. Due to limitations of the Azureus plugin API, we are currently unable to bias other aspects of peer connections, e.g., the bandwidth allocated to each connection.

In addition to Ono, Aqualab also does other projects that are designed for improving Internet performance in a number of other areas. Choffnes’s advisor, Dr. Fabian Bustamante, has been working on "sustainable scalability in distributed systems,” called the 3R project. Many P2P and internet VoIP systems are built in a way that routing is controlled at the application layer, and that in order to identify better paths and faster throughput, the application probes the network environment repeatedly, as the application has no quick way to determine whether a particular peer or node is performing well except by trying to connect to it. The 3R project seeks to decrease probing by re-using the view of the network gathered by long-running, ubiquitous services.

While enterprise networking and Internet networking are two different beasts, performance advances in one usually lead to advances in the other, and with cloud computing promising to make enterprise networking a hybrid of LAN, WAN, and Internet connectivity, these advances remain important.

According to this recent article in ComputerWorld:

IT staff jobs are at increasing risk -- both for contractors and in-house workers -- according to a survey of top CIOs by Goldman Sachs & Co. released last week. Global services companies will also feel the pinch because of the slowing economy.

My reaction:

According to the article, the study showed that CIOs are:

• Looking to cut resources from contracted IT staff


• Not looking to start or fund “discretionary IT projects”


• Looking for solutions with a “high and fast ROI.”


• See the “greatest potential for cost reduction in IT in the area of networking equipment”


• See server virtualization and server consolidation as their top two priorities, with data center consolidation an additional priority.


• Do not see cloud computing as a priority

Let’s talk about a couple of these. First, the “high and fast ROI.”

It is notoriously difficult to prove IT’s return on investment. There is some truth to the idea that IT is a utility to big companies despite the fact that they do see it as a necessity. They don’t consider electrical power a profit generator either, but without it, the business grinds to a halt.

And unless you work in a software company, chances are that IT isn’t a “profit-generating center.” Troubling.

However, what IT can do is lower costs for the company as a whole. (Indeed, the theory of having all those newfangled computers in the first place is that it saves a fortune on cross-country pneumatic tubing and hundreds of thousands of file clerks sitting on typewriters. Not to mention all the wite-out you’d need). The trick is having a way to prove that you’re lowering costs and to quantify exactly which costs you’re lowering. For that, you need a way to baseline performance and a way to determine what the effect of each IT project and change was.

Additionally, being able to detect and track detrimental changes to the network before people start calling into the help desk shows in a more anecdotal sense the utility and power of a well-functioning IT department.

This is especially important when you consider server consolidation – powered by virtualization, running many servers on one box decreases costs but certainly increases complexity. Being able to rapidly detect problems as they occur not only can decrease mean time to repair, but helps isolate problems. In a complex system, little problems early in the chain tend to cause big problems later on down the chain.

With server consolidation comes data center consolidation – seen as a major cost-cutting measure. But what that does is increase the amount of traffic that’s traveling along low-bandwidth WAN links instead of high-bandwidth LAN links. All things are relative – as you bring the servers closer to home, you’re also moving the users farther out. Being able to monitor end-to-end performance in these conditions – and figure out ways to improve performance on the WAN, is critical.

The one big silver lining in this is that cloud computing is not yet a priority – meaning that there’s still room for in-house IT even as belts get tightened. Focus will be, it seems, on the LAN, WAN, and DAN, er, if you are a network engineer named Dan, for example, our Dan in our IT department. (I suppose that you could worry about LAN, WAN, and BILL, or LAN, WAN, and LAURA but neither of those rhyme.)

Guest Post
by Josh Hinkle
Manager, Network Management & Security,
American Heart Association

As the youngest of three siblings I recall my brother hating to give my sister a ride to and from school. Even worse, he despised having her butt-in when he was hanging out with his friends.  After all, he was cool and his little sister was well…his little sister.

For my parents this was a great solution because they didn’t have to be the full-time taxi service anymore. Older siblings despise this role as chauffer because their younger siblings end up riding the coattails of older siblings to after school social activities.

At first glance I felt like Web 2.0 was that younger sibling tagging along on the years of hard work by global IT – built on an existing infrastructure while showing the ability to become popular seemingly overnight.

I spent the last 12 years in Information Technology with an emphasis in network management, eight of those years at the American Heart Association.  Most recently, I’ve served as Manager of Network Management & Security at the AHA the last two years. Like most corporate network managers I have a vested interest in enterprise application delivery. Our business, like many others, depends on enterprise applications being access by thousands of staff in hundreds of locations. At times our staff has been challenged with latency and remote connectivity. It was then we turned to NetQoS to measure, alert, report and trend our network traffic in an effort to take operations to the next level. As those processes recently began to mature our attention shifted to the free-riding sibling Web 2.0.

While Web 1.0 paved the way for networking billions of people, Web 2.0 is stealing the thunder. In a matter of months everyone has seemed to get LinkedIn, gotten poked on Facebook or Twittered someone. Web 2.0 is now carpooling with enterprise traffic across the same infrastructure competing for the same popularity of bandwidth.

AHA revolves around providing information to reduce cardiovascular disease and stroke, and Web 2.0 has increased the demand on AHA’s infrastructure.  It provides a low investment to a large audience.  Certainly, Web 2.0 has the potential inform and collaborate with millions, but the background costs of infrastructure and man hours concern me.

Web 2.0 apps are not representative of the traditional enterprise applications.  First, they exist outside the bounds of the enterprise infrastructure, yet we manage them on the same WAN. Second, the interactive nature of Web 2.0 apps require additional bandwidth.  And third, Web 2.0 applications are not unlike a “human machine” that grows with every click.

Right now, the American Heart Association is engaging  in a Social Media Evaluation project to determine where and how we can further leverage this new platform;  currently we are leveraging an application in Facebook to reach new audiences interested in the American Heart Association's Start! Walking Movement. The American Heart Association’s “You’re the Cure” Network has a Facebook site coordinates volunteer efforts to inform public officials.  Our TCS (Technology and Customers Strategy) Department started an AHA Technology Blog to discuss the technology we use and the organizational accomplishments achieved using technology.  Most recently, we posted a story about how a customer Googled symptoms he was having, which led him to our site on heart attacks.  His doctor told us that he called 911 immediately and survived because of it.

What I’m currently proposing to senior management is for AHA is to manage our network as if it were two separate networks – one network for our two very different needs.  The first network would use MPLS and provide managed bandwidth prioritizing queues for enterprise applications, and the second would offload all Internet bound traffic from the first. 

Not too long ago this type of infrastructure investment would appear to be unjustifiable, but given new trends in Web 2.0 as a platform and evolving cost structures it may very well be a business driving reality. We need a network as flexible and adaptive as the business demands.

This will increase our costs for transport but we are now able to guarantee Enterprise traffic on one network and adapt to evolving trends like Web 2.0, video conferencing, etc. on the other.  Even with the added costs, by negotiating more volume into our transport cost contracts, we can lower our per MB costs. 

Not all of the changes are measured in the bottom line however.  Our applications should see great gains in performance, and our network will be fully redundant for each site as the MPLS will failover for Internet traffic, and vice-versa. 

I must admit, at first I considered Web 2.0 an (admittedly exciting) nuisance in my network and a menace to my plan for enterprise application delivery.  But recently I created my own blog, linked my social network sites, posted you tube videos and started speaking a second language of Web 2.0 terminology.  I matured in my thinking as a network manager and now I embraced the qualities of web 2.0 much like my siblings and I matured in our appreciation for each other.

Web 2.0 may be the sibling that is bumming a ride but it has its qualities to appreciate; it may even mature into a traditional enterprise operations model.  Fasten your seatbelt and make the most of the ride.