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.

One of the big concerns that companies have when setting up IT departments is how much freedom to give to the workforce when it comes to the Internet.

There are two major philosophical ideas on the subject. The first is that employees are paid to work, not paid to surf the web, and that as such, any possibly distracting Internet sites that are not required to do the job should be off limits – or at least, harshly discouraged. The second is that if you treat your employees like robots, they’ll resent it, leading to on-the-job unhappiness, lost morale, loss of top talent, and therefore, overall loss of productivity.

It’s hard to find hard numbers supporting either theory though – until now. As it turns out, Dr. Brent Coker at the University of Melbourne studied the effects of “Workplace Internet Leisure Browsing” (or “Recreational Traffic” as we’ve come to call it here), and found that “employees that surf the Internet for fun at work are more productive by about 9% than those who don’t.”

The attraction of WILB, according to Dr Coker, can be attributed to people’s imperfect concentration. “People need to zone out for a bit to get back their concentration. Think back to when you were in class listening to a lecture – after about 20 minutes your concentration probably went right down, yet after a break your concentration was restored.

“It’s the same in the work place. Short and unobtrusive breaks, such as a quick surf of the internet, enables the mind to rest itself, leading to a higher total net concentration for a days work, and as a result, increased productivity.”

This result is similar to an effect noted by Jackie Andrade, a professor of psychology at the University of Plymouth – people bored in meetings often “doodle” – because the brain needs to constantly process information, and doodling provides just enough brain-juice during a boring task to prevent the mind from running off into a full-scale daydream.

"You wouldn't want the brain to just switch off, because a bear might walk up behind you and attack you; you need to be on the lookout for something happening," Andrade says.

A point of clarification – Andrade was talking about the evolutionary basis of doodling. No one has any reason to fear bear attacks during business meetings… yet.

Now, there may be security related reasons why one would want to not give desktop administrator access to employees, though this can be a pain, and reasons why you might block certain harmful Web sites and domains. But beyond that, there really isn’t a gain in blocking the distractions of the Internet; Facebook and IM and blogs and the like.

Reddit.com has the story of “Lou” whose company blocked instant messaging, using the line that IMs could spread viruses. (This is technically, possibly true, because IM clients are executable files… but plaintext? Not so much.) So, to stay in contact with other people at the company where he worked, he wrote a proxy page and hosted it on his own external Web server.

“I was the information systems intern, with the web design experience, so I hacked together a script hosted on my own server that allowed us to chat with each other and with any friends that wanted to visit the link. It worked because it was browser based and no one had to install anything. But I messed up. The script would refresh the page every 10 seconds… and the IT guy in charge of the network soon noticed that certain computers were making hundreds of requests to my server per day. When he found out what we were doing, he logged into the script just long enough to say "There is no chatting allowed on the company network. Goodbye."He then banned my domain for the rest of the summer.”

So instead of providing a new way for inter-departmental communication, the IT department just shut down that avenue and prompted resentment among employees. In fact, Lou goes on to write:

I'm glad I don't work there anymore, and since then I've only worked for smaller firms that don't do this kind of crippling to your computer usage.

Which really is the whole point – employees don’t want to feel like children – like they can’t be trusted, and have to be kept away from anything interesting. So the smart people – that is, the people who are worth the most to your business – are less likely to work for you, rather than your competitors, if you treat them that way.

So if locking down the computers isn’t a good idea, how do you handle performance problems related to recreational network traffic? Monitor it, and make sure that it doesn’t interfere with business critical traffic by placing it in lower QoS priorities.

As for us, our preferred distraction? Ping-pong. Which really isn’t a distraction at all, as this video we created earlier this year shows:

In the Wall Street Journal, Scott Austin, writing for the Venture Capital Dispatch blog talked about how quickly tech companies grow – specifically, what makes a tech company a “rocket ship,” “hot company” or “slow burner.”

The difference being the answer to one simple question: “How long did it take the company to reach $50M worth of revenue?” 

And it may take longer than you’d think – a lot of tech companies considered “fast growers” by human standards took 10 years – or longer – to reach that $50M mark.  For example, Oracle reached $50M in 10 years – Microsoft in 8. 

NetQoS – not mentioned in the WSJ article, took 9 years to pull off the same feat, a “hot company” by Austin’s standards.   To qualify as a “rocket ship,” a tech company needs to reach $50M in 6 years – which include companies like Activision, Adobe, Autodesk, Blackboard, Cadence – well, actually, there’s a whole chart of them on the WSJ site, so it’s probably a good idea to look them up there. 

Some tech industries promise quicker growth.  Video game companies Activision, Electronic Arts, and Take Two are all “rocket ships,” network/infrastructure companies (like NetQoS) tend to hit right in that “hot company” area, and vertical applications companies tend to be slow burners (with notable exceptions like Blackboard and Intuit.)

Boy, did we have fun with this one…

One other thing: That news ticker on the bottom? Well, I wrote some of them, but I asked the entire company for some ideas – some of them were used pretty much verbatim, others were edited, and still others inspired other news ticker lines. I’d like to thank everyone at NetQoS who participated, including: Alex Malone, Jason Roeber, Joe Sanford, Jesse Najera, Susan Pearsall, Ryan Leatherbury, Loyde Hales, Lindi Horton, and Mary Greening

I’d also like to thank J.R. Ghaddar for the generous use of his chromakey screen, and Kevin MacLeod at Incompetech.com for the music.

The Gartner Group is on our short list of organizations not to tick off, a list also populated by our customers, our business partners, and the Mafia. They are very influential in the IT management industry, and as such, it would be stupid if we did. (Er, the Gartner group, not the Mafia.) So, we're going to keep this short and to the point.

There's a post gathering a little bit of attention after appearing on the comp.os.linux.advocacy newsgroup and from Reddit, regarding a post two and a half weeks ago on Network World's Cisco Subnet, where Larry Chaffin writes about how he was given an e-mail from Gartner asking for him to take down all blog posts containing the name “Gartner.”

This is the link: http://www.networkworld.com/community/node/44252

Gartner issued a mea-culpa in the comments page of the blog, and apologized for the letter. This is the link to that comment: http://www.networkworld.com/community/node/44252#comment-214815

TechDirt also has coverage: http://techdirt.com/articles/20090821/0427405958.shtml

(Speaking more generally, reporters in the tech media can generally feel free to use NetQoS's name, quote our publications, and write anything they'd like, positive, or negative, about our company.)

Joana Till Johnson, leading the Nemertes research team, recently wrote in Network World that “less than 40% of organizations are doing direct, regular assessments of application performance at the desktop.”

This is a problem, she notes, because VoIP and other Unified Communications applications are becoming a core part of the IT environment and crucial to the enterprise – and while most enterprises monitor servers and networks, they often overlook the end-user’s desktop.  The only “monitoring” going on is when users call the help desk, which is a rather inefficient and expensive way to monitor performance.

Figure 1.

NetQoS actually makes a unified communications monitor, called “NetQoS Unified Communications Monitor” in order to monitor unified communications… Darn, I think I let that last sentence get away from me there unified communications.

Okay, I’ll stop now.

Of course, for whatever reason you may not like the idea of using an application suite to track quality of experience and network response times.  Luckily, that’s not the only option. There’s also NetQoS Option B.

NetQoS Option B consists of the NetQoS End User Brainwave Frustration Monitor, mounted on each end-user.  When unified communication problems cause sufficient frustration, they send signals to the NetQoS Unified Shock Collar System, worn by all NOC staff.  This sends out an uncomfortable but not harmful reminder to the NOC staff that there’s a problem with communications, and they will hurry to fix the problem. Or they will be eaten by a dinosaur. 

See Fig. 1.

Back during Cisco Live, we did a co-presentation with NBC Universal, which talked about how they built and managed the network that delivered live coverage of the Beijing Olympics to not only millions of television viewers, but also to online and mobile viewers as well.

We now present to you this video of the engineering team responsible, explaining how they did it, (and how they employed NetQoS to ensure optimum network performance – hey, there’s a reason you’re reading about it on our blog!)

If you’re not up for watching the 5-part, 45 minute video, here are some interesting tidbits to take away from it:

• In 1996 Atlanta, NBC had 172 hours worth of coverage. In 2000 in Sydney, they brought CNBC and MSNBC on board and covered 442 hours. In 2004 for the Athens games, with the addition of USA, Bravo, Telemundo, and Universal HD, they covered 1,219 hours – 70 hours of programming content for any 24 hour period in Athens. But in Beijing, they covered over 3,600 hours, using online distribution, for 211 hours of coverage for any 24 hour period in Beijing. This included clips and highlights, as well as live streaming on NBCOlympics.com.
  
• There were 1.3 billion pageviews, 50 million unique visitors, 31.5 million hours of videos viewed, 35 million mobile views, 130,000 peak streams and 3.4 petabytes of video delivered. In context, if you stacked 3.4 petabytes in data on 1.44M floppies, then laid the stack down on the ground, you’d reach from New York to L.A. “Simply put, it was the largest media event in television history.”
  
• The cameramen were in Beijing, obviously, but the editors were in New York, who got low-rez proxy copies of all of the footage as it came in, chose the shots they wanted, then got high resolution video (at 300Mbps!) of those shots for broadcast.
  
• The network didn’t just handle video but also allowed on-air commentators and producers in both Beijing and New York information on how athletes were performing in the games as that information came in – that is, as each goal was scored and each lap was finished.
  
• Finally, the production on-air was “flawless,” the ratings came in above estimate, and advertising sales were $50M higher than expected.

Brett Winterford at ITNews.com.au recently reported on a group of digeridoo-gooders at the Universiity of New South Wales, who asked a question that many of us were wondering – how do cloud apps perform under stress tests, and are they up to the tasks that modern enterprises typically throw at their in-house networks?

Testing Amazon, Google, and Microsoft’s cloud offering, they simulated 2000 concurrent users connecting to each of the cloud services, “measuring response times and other performance networks.”

What they found was that the Web-based cloud services could scale up to meet the demand… but not reliably.  Response times varied depending on the time of day, what features were added and dropped, and… well…

"Using Google AppEngine, none of your data processing tasks can last any longer than thirty seconds, or it throws an exception back at you," [Researcher Anna Liu] said. "This is very consistent with the Google business model - they want to enable simple web applications to thrive on the Internet. AppEngine is there to enable the rapid development of simple web applications that don't include intense computing at the back end."

According to Liu, the company most poised to accept migration of in-house enterprise apps is Microsoft.  Still…

"None of the platforms have the kind of monitoring required to have a reasonable conversation about performance," she said. "They provide some level of monitoring, but what little there is caters for developers, not business users. And while Amazon provides a dashboard of how much it is costing you so far, for example, there is nothing in terms of forecasts about what it will cost you in the future.”

Cloud computing applications may eventually replace many of the traditional IT applications, but the limitations inherent to Web based computing will mean that it is not an acceptable fit for many enterprise apps.  The opportunity to save money lies in knowing which apps will work best with cloud computing, if moving to the cloud will save you money in the long term, and how well those applications will perform when they’ve been moved to the cloud.

Perhaps the solutions that show the most promise (and this is idle speculation here) is an application that is based in the in-house datacenter but, if it should need additional processing beyond what in-house resources can provide, dynamically requisition additional computing power from the cloud.  Such an application would probably require cloud computing interoperability standards that are still in their nascent stages however – and you still need to monitor performance to know when more resources are needed, and if adding resources from the cloud actually improves the performance of the application. 

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.

A Texas judge has ruled that Microsoft is not only in patent violation against a company called i4i, which, apparently, owns the ability to create custom XML documents, but must also halt sales of Microsoft Word 2003 and 2007 within 60 days.

ZDNet said that i4i’s patent “sounds a bit generic,” but the court ruled in their favor, granting them $200M in damages.

Did anyone else notice that the name of the company is a homonym with “Eye for (an) Eye?”

Anyway, Microsoft probably has workarounds and legal avenues to pursue before it stops selling Word, but if need be, Microsoft may just have to offer a “Texas Edition” of Word without the XML capabilities.

So if they’re going to do that anyway, allow me to suggest some other improvements to the Texas edition.

• Standard Font: Calibri at 13 points, rather than 11. Everything is bigger in Texas.


• When a program crash happens, instead of giving up, Texas Word will fight off thousands of kernel panics and memory errors to give Sam Houston time to save his documents.


• Texas Word will come in two editions: Mild and Extra Spicy.


• Clippy will run for Governor, and get at least 12.43% of the vote on a platform of “It looks like y’all are trying to run a state.”


• Texas Word doesn’t worry about overheating CPUs. After a few years, you get used to the heat.


• Finally, I was going to suggest “Y’all” should no longer trigger spell check, but it actually doesn’t. Try it out. However, a truly Texan Word would include “Ahma,” and “Dija” as in, “Ahma goin’ to the store, Dija need anything?”