Cory Doctorow, one of the lead authors of Boing Boing, writes in the technology section of the British newspaper “The Guardian” his thoughts on cloud computing. And those thoughts, summed up, are:

The main attraction of the cloud to investors and entrepreneurs is the idea of making money from you, on a recurring, perpetual basis, for something you currently get for a flat rate or for free without having to give up the money or privacy that cloud companies hope to leverage into fortunes.

We talk about cloud computing upsides a whole lot. And for companies, being able to essentially outsource your IT needs to an external company is an option that may reduce costs under certain situations. It may increase costs over the long term in others. Knowing which is which – which apps benefit from “cloudification” and which are better left in-house, is a big part of IT management and budgeting these days.

Can you live with the performance downgrade? Cloud computing typically isn’t a solution for “doing more with less,” it is often a solution for “doing less with less” – but that may be all that your company needs. It comes down to knowing what your requirements are, and monitoring your networks to make sure that you can meet them.

But Doctorow points out that the main difference between cloud services and traditional IT is that cloud services are designed to get you to pay-per-X, where X could be Gigabytes, CPU Cycles, storage size, virtual server deployments… and to pay-per-X repeatedly through a rental, rather than ownership model. In other words, what were once capital costs are now being shifted to operational costs.

To the average person, however, Doctorow points out that cloud services are a reversal of the trend that we had been seeing throughout most of the 21^st century so far – the idea of charging per service giving way to ownership of software and dumb Internet pipes bringing you the services you chose to access. Even if that “charge” is indirect – for example, through on-screen advertising – the idea is that you pay something for the cloud service every time you use it.

Personally, cloud computing has its place, but network access has a performance price that I sometimes don’t want to pay.

As I’ve mentioned before, I’m writing a non-fiction book in my spare time, and have gotten 30,000 words done so far. I started out using Google Docs, as I could access Google Docs from anywhere with an Internet connection – my laptop, my work computer, or my desktop, and have access to the most current version of the document.

But around that 30,000 word mark, the document started to slow down, with noticeable lag when I typed. My performance suffered, so I did what, I suppose, was inevitable. I now edit the document in the OpenOffice.org desktop application, using Google Docs more as a storage platform than an editing platform.

It is important to remember that despite the wonderful advances – and they are wonderful – that cloud computing gives us, cloud computing is just one option out of many.

Google’s E-mail was down yesterday for 100 minutes – annoying many, and hurting the productivity of a number of companies that rely on Gmail.

You could chalk this up to the danger of relying on cloud apps… but, Google is supposed to be the cream of the Cloud providers. What happened? Well, according to the Google Blog:

Here's what happened: This morning (Pacific Time) we took a small fraction of Gmail's servers offline to perform routine upgrades. This isn't in itself a problem — we do this all the time, and Gmail's web interface runs in many locations and just sends traffic to other locations when one is offline.

However, as we now know, we had slightly underestimated the load which some recent changes (ironically, some designed to improve service availability) placed on the request routers — servers which direct web queries to the appropriate Gmail server for response. At about 12:30 pm Pacific a few of the request routers became overloaded and in effect told the rest of the system "stop sending us traffic, we're too slow!". This transferred the load onto the remaining request routers, causing a few more of them to also become overloaded, and within minutes nearly all of the request routers were overloaded. As a result, people couldn't access Gmail via the web interface because their requests couldn't be routed to a Gmail server. IMAP/POP access and mail processing continued to work normally because these requests don't use the same routers.

The Gmail engineering team was alerted to the failures within seconds (we take monitoring very seriously). After establishing that the core problem was insufficient available capacity, the team brought a LOT of additional request routers online (flexible capacity is one of the advantages of Google's architecture), distributed the traffic across the request routers, and the Gmail web interface came back online.

On one hand, Google didn’t understand their network well enough to know the effects that the change would have. On the other hand, Google did some things right – their monitoring software alerted them to the problems before the users started calling Google, they were quickly able to diagnose the problem, and that lead to a simple and direct solution to get up and running relatively quickly. 100 minutes may seem like a long time, but from the problem to the repair, it’s actually relatively short.

Here’s a cool little thing coming out of VMWorld this week in San Francisco. WYSE technologies, which makes the other half of the virtualized desktop equation that most people don’t think about - thin clients and thin client software – has developed an iPhone app which allows you to access a virtualized Windows desktop on your iPhone. 

Hey, who wouldn’t want to be able to access their PC from anywhere? Although, this presents a problem when you lose your iPhone, or, if current cellphone trends continue the next few years as thin clients and virtualized desktops mature and are adopted as mainstream enterprise tools, your iPhone is accidentally swallowed. 

But what got me thinking about this is the idea of more traditional mobile thin clients – laptops.  (Yes, WYSE makes those too).  One of the biggest problems that enterprise laptops have produced is a lack of security.  The very thing that makes them valuable, portability, makes them easy to lose.  And a stolen laptop can have all sorts of compromised data on it – data that your company might not want on the loose. 

Operating over a thin client means that, if a laptop or cellphone was lost, the personal data remains inaccessible to the thief, and still accessible to the user.  A change of password and you’re done.  In fact, the advantages of virtualized desktops are pretty much the same advantages of cloud apps.

There are disadvantages of virtualized desktops as well, of course.  There’s the issue of network coverage. You would need to be connected to the Internet in order to use even the basic functions of the computer, and that means either WiFi or 3G or better connection – mostly available but not yet omnipresent; and certainly a problem for international travelers. 

And of course, even the biggest and best companies have problems maintaining relatively simple cloud apps, so monitoring dozens or hundreds of virtual desktops will be a challenge.

And I just want to leave you with this thought: I can now theoretically run a virtual Windows OS on my iPhone, but I can’t run a virtual Mac OS on my iPhone…

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.