As Halloween approaches, I’ve got a bit of a horror story to keep you up at night. 

There’s an interesting quote that’s somewhat appropriate now.  Well – song lyrics anyway.  “Did you feel you were tricked / by the future you picked?” Which, I’m told, are part of a Peter Gabriel tune for a Pixar movie, but which I only came across when reading speculative fiction about quantum AI computers running 419 scams.

The thing about the future is that by the time it gets here, it’s already the present. Wait, I’m sounding like Criswell there… what I mean to say is that only a couple years ago, the big story in technology was how IT departments were becoming centralized due to advances in virtualization technology that cut down on hardware requirements and power consumption.  Now the next level is cloud computing; an idea, fundamentally, that you can centralize data centers even further by centralizing them with the data centers for other companies via a third-party provider. 

Taken to an extreme, it’s easy to think of a day when even these cloud computing centers become even further consolidated – perhaps one on each inhabited continent.  “A world market for maybe five computers” indeed…

Except, it’s not quite that easy.  The transition from in-house architecture to cloud computing resources is just about as difficult as the transition from real servers to consolidated virtual ones, and the big problem is ensuring network performance – that data gets where it needs to go quickly.  

Much as the server consolidation/virtualization problem was helped with better virtualization technologies and advances in WAN optimization, the current rush in IT tool development is in the cloud computing area (not that we still don’t have a-ways to go with virtualization and consolidation).  And some of these cloud-computing tools are starting to appear – for example, self-managing environments…

One of the newest approaches is the concept of the "dynamic infrastructure." Rather than a simple collection of humming boxes or cards designed to push data this way or that, the dynamic infrastructure brings together virtual networking, automation and resource management with tools like application management, security and policy management to create a self-managing environment that can react to changes in workloads and other needs with minimal human interference.

Lori MacVittie, technical marketing management for application services at F5 Networks is one of the prime movers of the concept, which she says will be the inevitable result of the transition to the cloud. 

"When the entire data center is founded on a dynamic infrastructure, the infrastructure can react itself to changing network and application conditions and needs," she says. "When the entire ecosystem is sharing status and information about performance, every component can adjust itself dynamically to what’s needed now to improve performance or maintain availability. And it happens automatically, based on the specific needs of the business and IT."

Virtualization has underscored the need for performance management; back when everything was run on actual servers, you could almost always fix a problem by finding out where the bottleneck lied and increasing the amount of stuff.  Not always, but almost always.  But with virtualization, you’re essentially managing an interconnected ecosystem of stuff and… well, stuff that’s not stuff.  “Unstuff,” to borrow a bit of NewSpeak. 

And this management is so complex that it has increased the demand for network engineers, yes, but it’s also increased the demand for software to come along and replace the more tedious tasks of network engineers, automating the processes where possible.

But what if there is no upper limit?  What if self-managed cloud computing software is exactly that – with computers calculating exactly what needs to be done to preserve performance and then automatically fix it? 

And that network monitoring software…. WAS ME THE WHOLE TIME!!!!!

AAAAAAAAAHHHHH!!!! 

Virtualization is a good news/bad news technology. The good news is that you can consolidate your servers onto one piece of hardware, but the bad news is that you lose visibility into the overall network. Jim Metzler, of Ashton, Metzler & Associates, and Ben Erwin of NetQoS discuss how to preserve visibility into application delivery in this short Whiteboard Series Video

One of the top stories on Network World’s front page today is Colt Mercer’s post on iCloud and G.ho.st – two cloud-based “Web OSes.”

If you’re not familiar with the concept, a WebOS is essentially a computer in a Web browser; a complete operating system virtualized inside your Web browser, allowing you to access specific cloud-based applications.

Don’t get me wrong – running a computer inside a Web browser inside a computer is an amazing technical feat, and one which is pretty cool. But that’s all that it is. The problem is applications.

That is, in order to access the applications – word processing, spreadsheets, photo cataloguing, etc. – you have to A) Use your computer’s OS to B) use your Web browser to C) Use the Web OS to D) use the application you really wanted in the first place. Compared to most cloud applications which take three steps, (Computer OS to Browser to Web app), or desktop applications which take two, this seems to be a woefully inefficient way of doing things.

The advantage of a unified operating system on the Web, of course, is interoperability – being able to copy spreadsheet data and put it in a word processing document, etc. However, Google seems to be able to do this without the Web OS intermediary. Gmail integrates with Google Docs, which integrates with Google Spreadsheets, etc.

So right now, any so called “Web OS” is less useful than no Web OS at all. It’s just another thing getting in the way to the application you really want.

There is still potential in this model, however. The problem is that these Web OSes are very limited in what types of applications will run on them. The main selling point of OSes on the desktop is that, say, Windows will let you run any Windows software that exists. Mac OSX will allow to run any OSX app. Linux will let you run any Unix app.

Why would you use a service that allows you to run, maybe, 15 applications, when you can use a service on your desktop that allows you to use millions?

Cloud computing has already accomplished an amazing feat. About 80% of our computing can be done on the Cloud – and about 80% of computer users can use cloud apps exclusively day-to-day. The 80/20 rule, if you will, strikes again. The trick for cloud computing apps now is reaching that “long tail” on the 20% - creating the app for the minority of users, rather than the majority.

I can see Web OSes solving this problem one of two ways. The hard way would be for all these little startups to standardize on a single platform for app development, and create millions of Web apps, to rival commercial desktop apps. At the same time, they will be competing with Google and Microsoft, who plan on developing Web apps – or have already developed Web apps – without those standards. Again – this is the hard way.

The easy way would be for a Web OS as “middleware” to make already developed desktop applications work on the cloud. A Web OS that came with some basic features, but which allowed me to run, say, anything that is featured in Debian’s APT packaging system, by recompiling it for the cloud, and running as a cloud app. Sure, some apps would be too “chatty” to be worthwhile on an Internet connection, but those apps can be recompiled in later versions to be less chatty and more responsive over longer-latency links. (Until then, monitoring how many round trips each app takes is a good policy.)

Or – and this may blow your mind – what if we could run Windows apps on the cloud? Microsoft may be working on this in their labs somewhere, but if they’re not, there’s always Linux+WINE or ReactOS.

There are advantages to such a setup – running Web apps is less bandwidth intensive than more traditional remote desktop virtualization (where you run the entire output of the screen and everything down the network tubes) and there’s certainly an advantage in providing app support only through a Web interface, and take no liability on the client’s end for the desktop OS.

There’s an article on ZDNet talking about a video where Sun Microsystems CTO Lew Tucker talks about how future cloud computing applications will be able to know exactly how much demand there is for the application, and requisition the appropriate amount of computing power. During high demand, the application could grab more resources, preventing application-based slowdowns, and during low demand, the application could release resources back into the cloud, saving the company money.

Of course, ZDNet’s title for the article is “Future Cloud Apps won’t need humans” which conjures up frightening images.

If it’s any indication, dynamic allocation of the needs of information will cause anxious consternation about the continued necessitation of the IT occupation, and frantic desperation. (Of course, that’s just idle speculation.)

But it might be more accurate to suggest that “Future Cloud Apps won’t need humans to babysit them.” That is – all that Tucker talks about is the idea of taking what used to be a manual process – deciding how much processing power any particular application needs – and having the computer make that determination on the fly based on the actual processing power needs. Certainly, humans will be involved in determining how much power is “too much,” how much slowdown is “acceptable,” and – most importantly – how much performance that the end-users can actually use.

This has two main impacts on the networking side of IT – that is, if an application can dynamically allocate more resources during times of excess need, application performance may be limited on the server or on the network, but it eliminates one of the main causes of application performance problems – not assigning enough resources to the application.

Additionally, application performance becomes important independent of the network, as a poorly coded application might need more resources and therefore require more money to operate.

Secondly, when you essentially remove the limits on application performance by simply allowing it enough resources to do the job at any time of the day, you have to continue to look for other bottlenecks. If you have the capacity to do more with what you’ve got, it makes sense to do everything you can to take advantage of that capacity.

Now, before this possibility becomes a reality, cloud computing standards need to be developed, agreed upon, and used in order to have multiple applications cooperate in any dynamically scaling environment. That may be very soon, or a long way off, but it will probably happen, because there’s just too much money to be missed out on if there isn’t a cloud computing interoperability standard.

One of the things holding back the rollout of new applications (like VoIP, Video, and Unified Communications) is the fear that the new applications will cause network performance problems; according to Network World’s Denise Dubie, citing a survey from Apparent Networks.

Nearly 61% said that they had delayed a VoIP implementation due to network performance concerns. Some 35% postponed a video rollout for the same reasons and 26% put a unified communications project on hold. The survey also showed that network managers can’t always validate their service-level agreements (SLA) with external service providers. More than one-quarter of respondents don’t have the capability to validate SLAs.

It would be instructive to know if decision makers are “concerned” that new apps will reduce their performance because they have baselined performance and know that the network cannot handle new application rollouts… or if they’re concerned because they have no idea whether the network can handle it or not.

It’s the difference between being stopped by practicality and being paralyzed by fear.

And if you’re being paralyzed by fear, it’s costing you money.

For example, Cisco decided to “eat it’s own dogfood” and estimated that they saved $277M from bringing in their own virtual office telecommuting technology – a new application (based on their “Cisco Virtual Office”) for the network that leads to cost savings. If Cisco didn’t know that their network was capable of supporting the CVO application, they would have been out $277M.

Of course, the reason you don’t roll out an application that might save you millions when you don’t know whether those applications will negatively affect network performance is that poor network performance can cost more than whatever you’d save by the rollout.

You can know, or you can be paralyzed by fear of the unknown. I know which I’d rather be.

We’ve produced a follow-up to our earlier “The Network Company” video, this time looking at LAN vs. WAN application coding, TCP Slow Start, and WAN Optimization. Instead of giving you a detailed run-down, I’m just going to go ahead and embed it right here.

I love any day when I get to smash citrus with a large blunt object at work...

Ben Erwin, Technical Marketing Manager at NetQoS, comes back for another Whiteboard Series video to explain how NetQoS’s integration into the Cisco NAM means that you need fewer data collectors and can lower your costs by leveraging your existing infrastructure.

He also, for some completely non-sequitur reason, plays ping-pong.

A high definition version can be found at the NetQoSVideo YouTube Channel, here.

We talked a bit about the SuperAgent/NAM integration earlier.

Today we just put out a press release and went live with a Web page announcing our integration of SuperAgent application response time monitoring into the Cisco Network Analysis Module (NAM). The integration combines NetQoS SuperAgent’s ability to baseline and analyze application performance across the entire network with the NAM’s high-resolution troubleshooting capabilities and data collection capabilities.

Or in short, instead of having a NAM and an external SuperAgent collector(s), you now have the ability to have both in the same box. Isn’t that swell?

The NAM monitors and analyzes network traffic, and provides Layer 2 to Layer 7 visibility into the network traffic. The benefits of combining Cisco NAM with SuperAgent are summed up by Paul Hoyle of the California Department of Transportation WAN Management team, which has already tested the combination. Hoyle said:

“We will be able to combine the data from our multiple NAMs with our other SuperAgent collection sources and view it all in the NetQoS management console, which will help us better understand how applications are performing across our organization and quickly drill down to any NAM for efficient troubleshooting. Plus we get the benefit of monitoring more applications without having to deploy additional SuperAgent hardware.”

As a tag-team, Cisco NAM provides visibility into network and application performance to help ensure the consistent and efficient delivery of applications and services. SuperAgent then takes that information, and delivers an enterprise-wide view of performance, volume, and availability metrics across all of the NAMs (plus SuperAgent’s own collectors) in the network, as well as the ability to drill into each NAM user interface for high-resolution diagnostic reporting. SuperAgent also automatically investigates the cause of problems in a way that augments the NAM diagnostics. For example, SuperAgent can immediately launch a trace route investigation when network latency increases above a normal baseline.

Ben Erwin concludes his three-part Whiteboard Series installment on how to manage QoS in your environment. In this episode, Ben shows you how to use NBAR in the NetQoS Performance Center to manage QoS policies in your environment. 

Below you’ll find the embedded video, now in widescreen YouTube HD. A low definition version can be found here.

Update: Texas PI Law

Benjamin Wright, (an advisor to an electronic-discovery firm Messaging Architects) posted a comment to our coverage of the Texas law that requires companies which “investigate” computers (which could possibly mean PC repairmen, although that wasn’t the original intent of the law) to have investigative licenses – the “Texas PI law” for short.

He pointed out that already there is one unintended consequence – and that is that those caught in red-light traffic cameras are suing the manufacturers because even though the red light footage is “evidence of a crime,” some (most?) traffic-cam organizations are not licensed to act as a private investigator, and therefore it is illegal for them to present that computerized evidence in court.

When the Texas PI law first came out, we were concerned about “unintended consequences,” and those consequences striking computer repairmen, network engineers, sysadmins, and others. This, on the other hand, seems to be the intended consequence; the red-light camera company was doing forensic work to be used in court dealing with computers. (Let’s ignore the merits and drawbacks of red-light cameras for right now.)

It is, however interesting to note that the company named in one fine appeal, American Traffic Solutions, is based in Arizona, which explains, partially, why they may have not gotten a PI license in Texas.

The American Bar Association has weighed in on this issue [PDF], arguing that computer forensics experts should not need PI licenses for forensic work.

Update: Respecting the Network Engineer

Yesterday, we published Chandra Hosek’s column on how Network Engineers often get less respect than they deserve. Thomas Nolle at Network World has published a column suggesting some of the reasons why.

Nolle notes that since the first Tech bubble burst in 2000, computer systems and software have gotten larger than average shares of investment, while networks have gone down since then. From the article:

The question we might ask is why networking couldn't capitalize on the attention it received. The answer, I think, lies in the stuff that binds networks to applications. The pivotal point in that critical issue came in the early 1990s, when IBM's Systems Network Architecture was supplanted by TCP/IP. SNA network equipment was just too expensive, and enterprises went to the lower cost of TCP/IP instead. The critical thing was that SNA was an application architecture as well as a network architecture, and TCP/IP vendors didn't present application tools… Networking won hearts and minds in the '90s, then lost them again because it didn't offer the whole solution. The application connection to the network was never made by the network vendors, and so IBM and other system and software players continued to control that critical linkage -- and still do today.

This brings new perspective on the idea that, as Jim Metzler put it, in IT you either develop applications or deliver applications.

Update: Australian Internet Fliters

Computerworld reports that the Australian-based Electronic Freedom Project is organizing protests on the 13^th of December to protest Internet content filters mandated by the government. At the same time, the Minister for Broadband, Communications, and the Digital Economy, Sen. Stephen Conroy, has given his explanation of the ISP filtering plan; but ultimately, “Teh Moges” at Slashdot pretty much sums it up with: “Any efficient filter won’t be effective, and any effective filter won’t be efficient.”

Sen. Conroy earlier tried to place pressure on Mark Newton’s employer to keep the Australian network engineer’s criticism quiet.

Update: Groups push for Net Neutrality legislation in Obama’s administration

During the 2008 presidential campaign, then candidate Barack Obama pledged support for Network Neutrality principles and regulations. Now that he’s President-Elect, the Open Internet Coalition is calling on Obama to follow through, according to Network World.