According to InfoWorld, Microsoft has announced, (or more accurately, has announced that they will announce) an operating system called Windows Cloud. Supposedly it’s intended for developers of cloud-computing applications, much like Google’s App Engine allows you to develop and run a Web app, built in Python, on Google’s hosted servers.

What makes this particularly interesting is that the whole point of cloud computing is that it really doesn’t matter what OS you run it on. It doesn’t need to be compatible with a particular client OS, so long as it’s compatible with a standards-compliant Web browser. The back-end is also as agnostic – run it on Linux, Windows, BSD, or Plan 9, so long as it works and it performs well.

This is a new area for Microsoft. Microsoft is used to selling operating systems in a market differentiated by hardware compatibility, public adoption and brand awareness, with “killer apps” for each platform. (Apple has Final Cut Pro, Logic, and Shake. Microsoft has Exchange, Direct X, and uh… Solitaire?) But cloud computing apps usually just require raw processing, not hardware compatibility. The public never sees what’s going on the back-end. And killer apps can be designed for any platform, not just specialized ones.

In short, unless Microsoft can find some other way to differentiate itself, Microsoft is entering a commodity market.

Now, one of the ways Microsoft can distinguish itself is by optimizing performance beyond its competitors. They could try developing a Web application development framework that enables app developers to reduce the number of round trips that need to be taken, but that’s not really an OS issue. More likely they’ll be focusing on processing power, queuing, and massively multiprocessed threads. Here they might be able to make some gains by processing different threads on cores that are closer to each other, physically (shaving nanoseconds when you have multiple apps running multiple times a day can add up.)

Even so, it’s hard to imagine a way that Microsoft could improve Web app performance or flexibility by coming to the market with a cloud application OS. But then again, it’ll be a month before it’s revealed, so maybe there’s something that we overlooked. Anyone from Microsoft want to comment?

In the meantime, I’ll be dreaming of a Web app that allows me to feel true emotional contentment. In the meantime, I’ll have to settle for icanhascheezburger.com.

First off, congrats to Nick Carr – we’ve talked with him (and disagreed with him!) often on the blog and we’re thrilled that he managed to go toe-to-toe with Stephen Colbert on last night’s show.

And, thanks to the Colbert Report’s online presence, here’s an embedded player with that interview.

Although the book plugged is “The Big Switch,” the majority of the interview talks more about the implications of dwindling attention spans due to the Internet’s “hyper” hyperlinked nature – a topic not covered in “The Big Switch,” but instead in the cover article Carr wrote for the Atlantic Monthly, “Is Google Making Us Stoopid?”

The idea, as we’ve mentioned before, is that Carr believes the end result of the attention getting behavior of the Internet is that it will “scatter our attention and diffuse our concentration.”

“When the Net absorbs a medium, that medium is recreated in the Net's image. It injects the medium's content with hyperlinks, blinking ads, and other digital gewgaws, and it surrounds the content with the content of other media it has absorbed. A new e-mail message, for instance, may announce its arrival as we're glancing over the latest headlines at a newspaper's site. The result is to scatter our attention and diffuse our concentration.”

During the interview, Colbert made a play of ignoring Carr to check his iPhone. Now, that that does happen in real life, but I’d say that’s more an indication of individual rudeness then of culture spinning on a dime over the concept of hypertext.

The same criticisms that Carr makes of the Internet could be made of the newspaper – you’re trying to read one thing but it’s broken up, put next to all these other interesting articles, and ads designed to catch your attention… with all these… analog gewgaws, how is one supposed to be informed?

We’ve mentioned before that the limits on network performance limit the ability to communicate complex thought back when the Atlantic Monthly article first came out. But, we missed an opportunity to get less academic, more practical, and closer to the issues in a corporate network environment.

While we disagree with Carr’s diagnosis that the Internet causes short attention spans, (I’m a pro-blogger at a tech company, raised on Nintendo and MTV – I’m the poster-child for the 21^st century digital boy, and still I managed to summon the concentration to read the book Nick Carr wrote…) we do agree that human attention spans are short.

When I worked at a supermarket retailer, back in the early 2000s, as I’ve mentioned (and complained about) we were using a java-based networking app that took one to two seconds to input each number and move to the next field, and processing the entire report took minutes. The network performance was absolutely horrible, and as I pointed out before, we would have mentioned it in the hopes of having the performance improved somehow, except that we all realized that our jobs were essentially superfluous anyway and that we could all be replaced by a very small shell script that could parse the orders as they came in instead of printing them out and having us enter in all of them by hand.

Of course the lot of us at the data entry farm had CNN.com, Slashdot, and All Your Base Are Belong To Us and Hamsterdance open while we waited for the pages to load. (It was a simpler time back then.)

Of course, if we didn’t have outside Internet access, we could very well have distracted ourselves offline with desktop toys or conversation. We did that often anyway – as I said, it just took forever for those fields to come up.

I’ve also heard, second and third-hand, stories of other companies who are shocked to find that employees are going on to do other tasks while they wait for reports to generate, fields to come up, and pages to load – so if you’re honestly worried about dwindling attention spans, it might be better to not curse Google or the Internet, but to go in and actually improve things where you can.

When Google Chrome was released, our genuine reaction around the office was something like this:

Okay, so the last thing the world needs is yet another browser. Between IE, Firefox, Safari, Opera, Flock, Konqueror, Epiphany, Camino, Galeon, SeaMonkey, OmniWeb, and, of course, Wii Internet Channel, Web applications developers already have their hands full.

However, if you work in IT, you are either in the business of developing applications or delivering applications. And sometimes the bottleneck in application delivery is the browser. You can have the best network in the world, with only a couple hundred milliseconds of overall delay – but if it takes seconds to render the JavaScript on the front-end, it’s almost academic. At any rate, the end-user probably can’t tell the difference between delays on the network to delays on the client-side browser.

There are two things that make Chrome stand out – the first is running each tab, and each plug-in, as a separate process, with protected memory address space. Problems in one tab will not crash the entire browser.

The other is advances in JavaScript execution. By running java scripts in separate process, buggy JavaScript can’t hang the browser, like it would if JavaScript ran in a single-thread in a browser process. The above scenario should come as no surprise to anyone that has used Firefox and watched as a single buggy JavaScript site made you restart all the tabs on your browser.

But Chrome also comes with a JavaScript virtual machine, which speeds up JavaScript-based Web applications by turning the interpreted JavaScript code directly into machine-code for your processor and OS. Again, faster delivery of the application, when the browser is the bottleneck.

There are a few nay-sayers out there that are looking at this from a bottom line point of view – that Google is trying to enter into the browser wars and try to own the space – basically, if you use Google’s browser, even if it’s open-source, you’ll view Google’s advertisements, and make Google money. That’s true enough. But what we really should be taking from this is that even if Google’s code wasn’t open-sourced – and it is – these innovative ideas would eventually make their way into other Web browsers in order to stay competitive. Firefox will likely incorporate changes at least by the next full release, and Microsoft, Apple, and Opera Software will do so if they want to remain competitive.

I’m skeptical that Google Chrome will make it onto enough desktops that Google becomes a key competitor in the Browser Wars. Then again, Mosaic was the first Web browser, and no one uses it today – but we certainly use a lot of the technological ideas behind Mosaic. It really was a quantum leap forward, and though I may be overly optimistic about it, this really is a quantum leap forward in Web application development.

The point is not Google Chrome. The point is the technology behind Google Chrome.

I’ve been getting a number of e-mails and comments asking why I haven’t yet written anything about the Russian/Georgian war and the supposed “cyber-warfare” taking place. ZDNet has written extensively about the DDoS attacks being waged against Georgian government sites.

At first, I thought that this was solely a security issue. As a general rule, I don’t like to talk a whole lot about computer security on Network Performance Daily because I lack the proper mindset to get around security – security experts are people who look at things and see how to break them down, network performance experts are generally people who look at things and see how to build them better. Besides, there are tons of blogs out there about computer security, and very few about network performance.

I’m not going to get into the geopolitical aspects of it, except to say that getting involved in a land war in Asia is one of the “classic blunders.”

However, I did start thinking about things… I mean… wasn’t the Internet partially designed to be a resistant form of communication in case the Russians ever attacked? The irony of the Russians effectively taking down a country’s Internet is… well, it’d be funny if it wasn’t for all the people dying.

What this does tell me, however, is that cloud computing (and I’ll continue to call it that despite Dell’s claim to the term,) has a long way to go. While the Internet can be cheaper and simpler than having a fully-fledged IT department monitoring in-house servers and applications on leased lines over a WAN, the one problem that in-house IT has licked is fault.

For the most part, we’ve managed to get it so that we no longer worry about fault on the enterprise network. It was a while ago that we passed the 99.999% uptime mark. So while we may worry about security and performance, we typically don’t have to worry about the network not working.

But cloud computing still has fault problems. And it doesn’t take the Russians attacking. I love Stumbleupon, but they went down for a few minutes yesterday – Twitter also, but they’ve got problems. Even Gmail, which I greatly rely upon for my personal e-mail, went down for a little while earlier this week.

By and large, cloud computing makes great solutions for smaller companies and start-ups because of the low cost, low maintenance, and portability. However, the tradeoff is reliability – Internet applications simply aren’t as reliable as the bulky solutions that get things done when a single hour of downtime can mean thousands in lost business.

There really is no such thing as a private cloud. The entire concept revolves around using IT services offered from outside companies, which connect on public lines through to shared servers.

This is not to say that there is no room for the cloud in enterprise computing but that incidents like the South Ossetian war show that Internet applications suffer from one fatal flaw: They’re on the Internet.

Now, me, personally, I don’t use Twitter. Oh, yes, I know, as “new media/blog guy” I’m supposed to be all “hep” to the latest “doo-dads” what with me being one of those crazy “internet geekerinos” but I just never really saw a value in Twitter that wasn’t available with LiveJournal years ago.

One hundred and forty characters is simply not enough room to convey anything particularly complex, informative, or artistic. I mean, even though I read “Burnt Orange Report,” published by Karl-Thomas Mussleman, I must admit that twitter posts like…

“karltm Sitting behind marc katz in traffic. His left rear tire pressure is low. 12:24 PM May 24, 2008 from txt”

…neither inform nor entertain.

Others, like this one from my friend and sometimes improv comedy partner Chris Trew of Coldtowne…

“christrew just ate body paint 19 minutes ago from web”

…are just things you don’t want to know.

For all of its flaws, however, Twitter’s service is something that many professionals – for whatever reason – rely on. Unfortunately, Twitter is not particularly reliable – the constant outages have prompted at least one person to create a Web site called “IsTwitterDown.com” which pings Twitter’s server.

Now , pinging Twitter’s server may indeed help you determine fault – but it won’t tell you anything about the dropped packets, network round trip time, or any of the other performance issues which prevent Twitter from being usable. For example, users experienced degraded service this morning because Twitter’s main database crashed due to too many connections. A quick ping wouldn’t detect “too many connections” – it would just be one of the successful connections of which there were apparently too many.

To Twitter’s credit, they’re well aware of the performance issues and just today have started a blog which details “performance and reliability.” Pagination – whatever that is – is partially restored. (I’m assuming it might have something to do with Ellen Page, the lead actress in “Juno.”)

Mark Gibbs at Network World suggested that IsTwitterDown.com should switch from merely pinging the Twitter server to using cURL and Wget to see if you can send and receive Twitter updates, which would be more accurately measuring the performance of Twitter. Then again, considering that istwitterdown.com is in the same vein as abevigoda.com, which constantly updates "is he dead?" status of Abe Vigoda, that might be taking the joke too far.

It’s been hinted at and talked about for a year and a half, when Garett Rogers Rogers at ZDNet pored through Google Docs source code and found references to “localhost” in the code.  Now Google Docs, through Google Gears, is available as an offline application. 

Word processing “in the cloud” isn’t that new an idea – Adobe has been working on a similar solution in Adobe Buzzword, and Adobe Air’s offline capabilities will probably find their way to the desktop.  Microsoft has, through SharePoint, been trying to take word processing from the desktop to the cloud, while Google has what may be the easier job of taking word processing from the cloud to the desktop.

In any case, these online apps are significant.  Even with volume licensing, word processing programs are not cheap; Google Docs is untested, but free, which makes it likely to be the office platform of choice for today’s startups – and today’s startups become tomorrow’s entrenched large businesses. 

There is a real trend for what were once completely offline apps – such as word processing – to become hybrid online/offline applications.  That means there’s more traffic – but of course, most of you already know that.

But what makes this traffic notable is that this is added traffic on the network that actually has every claim to being considered “business-critical” – compared to most sources of new traffic, which has been recreational. 

Worse, chances are you’re going to have to deal with the “cloud traffic” at the same time you have to deal with traditional client/server traffic.  Old technology solutions stick around while the new solutions get implemented, and sometimes even afterwards.  What we end up with is a hybrid model, where old and new technologies based on completely different standards are equally important – and that can be difficult for network engineers. 

Nick Carr’s “The Big Switch” makes a case – which we’ve argued against – that eventually all apps will become online apps.  Oh, if only that were the case!

A year ago, ITWire wrote a story about Adobe moving into the SaaS market with a free, entry-level version of photoshop… within six months.

That version of Photoshop launched yesterday. Dubbed Adobe Photoshop Express to distinguish it from the desktop-based Adobe Photoshop Elements, the service is much like Picasa or Picnik, and in fact, despite Photoshop's "pro" reputation, may actually contain fewer features than Picasa or Picnik.

Still, an "online Photoshop" has been heavily hyped for quite a while, especially among Slashdot's Linux-heavy crowd, who come in two camps: Those who bemoan the lack of a native Photoshop for Linux, and those who think the first group should just use the GIMP and be done with it.

But there are a few things that stood out: The first was that Adobe's EULA is written so that, if you should upload your photos to the "publicly accessible areas" of the Photoshop Express service, while you retain copyright, Adobe gets a "worldwide, royalty-free, nonexclusive, perpetual, irrevocable, and fully sublicensable license" to use the photos in any way they see fit.

This may cause any company with concerns in intellectual property or data security - which is all of them - to start going over EULAs for their SaaS solutions with a fine toothed comb.

It is also a bit of a milestone for SaaS, as Photoshop is the Adobe Systems flagship brand and flagship product, a household name of desktop software. Adobe's moves in that direction are not to be ignored; and we've talked about the importance of maintaining network performance even when using SAAS solutions.

The release of Photoshop may bolster those, like Nick Carr, who believe that, fundamentally, IT is obsolete, and the trend is that all software will move from the desktop to "the cloud."

I happen to think that there's nothing to fear.

June 16, 2007, Network World:

"We're telling IT executives to not support it because Apple has no intentions of supporting (iPhone use in) the enterprise," Gartner analyst Ken Dulaney says. "This is basically a cellular iPod with some other capabilities and it's important that it be recognized as such."

March 6, 2008, Network World:

During a media conference at its San Francisco headquarters today, Apple unwrapped a host of new features that are designed to make the iPhone more attractive to corporate users.

Six months is a long time in the tech world…

We've warned that eventually the iPhone would be appearing on corporate networks and that the new (at that time) devices would introduce vulnerabilities into the corporate network and take additional resources. What we weren't counting on was Apple making overtures to enterprise networking - we had assumed that, much like the original iPhone was hacked to run on multiple carriers, that those who wanted to use the iPhone for enterprise applications would have to provide their own, messy, stop-gap solutions.

Back in January of 2007, when the iPhone was first announced, we wrote:

"That's another question - will this device have VPN support so that traveling employees can get the information they need while on the road? And if they do - how do you secure the data? The iPhone, like all small devices, is easy to lose, and easy to steal. That makes it vulnerable to illicit access. Does the iPhone have cryptographic abilities to make sure data stays safe?"

Well, apparently, Apple didn't take that as a rhetorical question because the fruit-based tech company is going to support Cisco IPsec VPN in the next iPhone update - the same one that will bring secure Exchange support as well as the possibility of an "iTunes Store for iPhone apps" - current Apple plans are to allow third party development but that Apple would have the final say on whether or not the applications could run on the iPhone. (Of course, clever hackers have already found a way around that.)

At any rate, the iPhone now seems to be competing directly with the Blackberry, which is good in the sense that competition in technical markets lead to innovation, and companies will have to expect new types of devices using different types of traffic, which - well, isn't bad, but which can be frustrating, absent a network device monitor.

Personally, I'm a bit confused by Apple's insistence to cripple the iPhone into only running "acceptable" applications on the iPhone, as A) it's clear that people are going to use it the way they like anyway, and B) if Apple took the same attitudes with their Macintosh/OSX general purpose computers, some of the best Mac apps (Quicksilver, Colloquy, Transmission, Burn,) simply wouldn't exist. Perhaps this increases the security of the device but at the obvious cost of utility.

It's just rhetorical, and I'd love to get some comments on this, but is the tradeoff between security and utility a false one? I'm not sure - havening not worked much in the security side of technology - but it seems to me that if the iPhone can be hacked to make it more useful, it can also be hacked to make it malicious, and so the choice is not between security and utility, but rather between a lack of security with utility, or a lack of security without utility. Hmm… maybe I should ponder this more.

by Brian Boyko
Editor, Network Performance Daily

The release of Adobe AIR today might just bring about major changes - both good and bad - for network performance. AIR is a way to produce Web apps that can be run as desktop apps. It is cross-platform and relies, like Java, on a just-in-time compiler and an interpreter of application bytecode. There are interpreters for Windows and OSX, and a Linux interpreter in development.

"It allows Web application developers - or just application developers - to use the Internet technologies they know, whether it's Flex and ActionScript to target the Flash part of AIR, or Javascript/HTML/CSS to target the AJAX part of AIR," said Phil Costa, director of product management at Adobe. "It allows them to take those applications and run them on the desktop."

Costa explained that through AIR, (depending on what the application does and how it is coded,) companies may theoretically experience a lowered amount of data throughput and an improved network performance.

"Today a huge number of corporate networks are moving towards browser based applications, and one of the extra bandwidth requirements that it puts upon the network is that every time you access a [Web based] application, you need to download it. Whether that's HTML or Javascript, or all kinds of Flex and Flash content, that needs to be pulled over the network. Having the application installed locally avoids that. All that will be going forth is the actual data that you're trying to access."

"We've done tests with some of our customers where they've seen our bandwidth [usage] go down for Internet applications in general, because unlike a Web site, which creates both the content and the formatting of the content, most AIR apps are just passing the information back and forth instead of refreshing the page each time."

"Now, depending on what the application does, it may actually add [to] bandwidth requirements for the network as well. One of the things that applications do, is run in the background and connect permanently to a data source's real time streams, or frequently check for data. That could increase the bandwidth requirements. But that's more about what the application specifically does than anything specific about AIR."

AIR's capabilities allow for offline usage as well, which will likely prompt more demand for online apps as the major drawback of SAAS - inaccessibility - is mitigated.

"In addition to giving the developers and then end-user of the application the convenience of launching the [Web] application like any other desktop application," said Costa, "it gives them additional capabilities that they didn't have when they were targeting the browser, such as local storage, either in flat-files or structured storage like a SQL database, which is embedded in there, or drag-and-drop integration with the file system, and cut-and-paste as well as the ability to take data or content offline, and run it when they're on an airplane or just not connected to the network."

"The runtime provides a whole set of APIs for notifying the application when it is on and offline, and so the developer can implement behavior that accounts for that; in many cases what we see is that the developers are caching some of the information offline, so that if the user takes it offline, it will still be available."

"To give you an example… one of our customers, Anthropologie, built an online catalog that lets people browse through things they have, and they built an AIR version which lets customers make little notes to themselves about the product, and rather than store them on the Anthropologie Web site, it stores them locally. The customer can put notes on things the same way they put stickie notes on an actual physical catalog, and they don't have to share that information with the Web site, so it's private to them. It also means, from Anthropologie's standpoint, that they don't have to create massive databases to store that information."

Costa said that Adobe hopes that there will be AIR apps on mobile phones, something that there's no specific date on, but which is on the Adobe roadmap.

EDITOR'S NOTE: I e-mailed Nicholas Carr about this post and he suggested that I pick up "The Big Switch" instead of relying on the Network World article, which he suggested might be a bit "sensationalistic." I'll swing by my local bookstore later tonight and see if they have it and will shortly go through it.

By Brian Boyko
Editor, Network Performance Daily

Nicholas Carr (who has kindly mentioned this blog in a post about Ad-block) has written a book called, The Big Switch: Rewiring the World from Edison to Google. And according to Network World, Carr, who wrote an article called "Does IT Matter?" for Harvard Business Review, said in this book that:

"In the long run, the IT department is unlikely to survive, at least not in its familiar form," Carr writes. "It will have little left to do once the bulk of business computing shifts out of private data centers and into the cloud. Business units and even individual employees will be able to control the processing of information directly, without the need for legions of technical people."

Now, we haven't yet read Carr's book and so we can't comment on whether or not he makes a compelling case for the obsolescence of the IT department, and for all I know that quote was taken out of context. But I do believe that it will be a long time before the IT department goes away.

SAAS is a wonderful development, and apps like SalesForce are, to the people that use them, godsends. However, unique company problems require unique solutions - SAAS services are looking to appeal to the largest common denominator. For that reason alone, IT will always have a place in the enterprise.

Additionally, if you want to connect to the network, which you most certainly will have to do to access your SAAS applications, you need network engineers to build and maintain the network - even if it's just for Internet connectivity. And what about application performance?

Google or other SAAS providers will not design your WAN to deliver large backups during off-peak hours, won't get your VoIP service to work with your data applications without clogging the lines, and won't help maintain your company's computer security. (Heck, if nothing else, when a key Ethernet cable gets unplugged, you need at least a sysadmin to find out which cable was unplugged and to physically run down there and plug it back in.)

Relying solely on SAAS is problematic at best. You're at the mercy of another company's quality control - and if the site goes down, so does your business. Your company's data - important and confidential data - resides on another company's servers. Finally, what about capacity planning?

That last one is crucial. You are usually not privy to the capacity of third parties. Larger SAAS services like SalesForce probably scale well and overprovision. But if Carr's thesis - that eventually most enterprise software will be SAAS - holds true, there will be some applications that are further down the long tail and service a much more limited number of customers.

With a typical client/server app, you have all the information there if you need it - the ability of the server, the number of clients, the average traffic per client, and if you have any network management software, you have a very good idea of how much total traffic you can handle. But put that application out in the "cloud" and you no longer can see that information, so you have no idea whether or not you're doing fine or teetering on the edge of a major slowdown in the service. It completely negates any possibility of meaningful capacity planning.

Sure, it shifts the blame from the IT department to the SAAS provider, but ultimately, it's the same thing: less productivity, less on the bottom line.

If Carr's thesis is that SAAS is going to play more of a role in enterprise computing in the future, we can't help but agree. But to say that there's no role for IT in a future with more SAAS applications is assuming far too much.