Over the first six months of 2008, our sales in Europe, the Middle East, and Africa were 160 percent greater than the first six months of 2007. We’ve have 29 consecutive quarters of double-digit year-over-year growth. We were invited to speak at the Kaufman Bros. Investment conference being held today and tomorrow in New York City, where Gordon Daughtry, our Sr. VP of corporate development and strategy will be presenting an overview tomorrow at 11 a.m.

If we keep up this pace of growth, we should effectively own a majority share in the planet Mars by Q3 2127, which has, of course, been our primary goal all along. (If you’re an employee of NetQoS, and this comes as a surprise to you, you should read our mission statement sometime.)

Of course, a growing company needs to make its presence known – while our big in-house event of most years is the Symposium in Austin, Texas, we’ve also got other events happening in more places. For example, our East Coast customers are invited to Fort Lee, New Jersey for a regional workshop there around the same time as Interop New York.

But one of the biggest events comes up next October 9^th and 10^th, in Köln (Cologne), Germany, where we’ll be putting on NetQoS Symposium 08 Europe – with most* of the stuff that makes NetQoS Symposium in Austin a great place to hone your skills and build your expertise.

( *Unfortunately, we were not able to fly Mingo Fishtrap into Köln. )

We’ll also be attending the Cisco Networkers event in Brisbane, Australia, later this month.

All these worldwide events remind us that the whole point of having a wide area network is connecting distant locations and keeping in communication. I mean, from a philosophical point of view. And our job is to give you the tools to keep those communications running smoothly. So, if you think about it, we’re contributing to a world coming together as one.

Wow. That’s… kinda deep.

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.

Network performance is just as difficult – and just as important – as network security, but security is “sexier.” It brings to mind ideas of James Bond’s villain Boris yelling, “I am inwincible!” But, if you've got an IT staff that knows a lot about security but nothing about latency, you can guess how well the apps will perform.

But even separating network performance from network security isn’t enough – because the network fills so many different roles in the company, network engineers are becoming specialized by necessity.

According to IT Career Planet, Cisco just announced three new Cisco Certified Network Asscociate concentrations – CCNA Security, CCNA Voice (for VoIP issues), and CCNA Wireless – with an eye towards closing the “skills gap” and providing specialized knowledge. (Let’s side-step the whole “vendors offering training and certification” issue – that’s the way the system’s set up, and so far no one’s come along with a better solution to replace it.) Anyway, more specialized training is good news.

The bad news is that while Robert Whitely at Forrester Research says that in five years, organizations that have a dedicated position for wireless, voice, and security will grow as high as 70%, we can’t help but notice that he didn’t ask the question of whether there will be dedicated positions for network performance. Yes, it’s great that there’s going to be a VoIP specialization – but VoIP is only one of the applications that IT is delivering.

It’s one of the reasons that we’ve been offering (vendor-neutral) network training and certification in network performance technologies, metrics, and analysis, in our NetAnalyst program.

Scalability is one of the more overused terms in networking – which makes it hard to explain why it’s important. Well, I mean, beyond the main concept of: “More scalability means you can hook up more computers to it!”

True, how big the deployment is probably the best way to objectively prove scalability – for example, NetQoS has one ReporterAnalyzer deployment monitoring over 20,000 WAN links. No small feat. But scalability isn’t just the quantity of computers hooked up to the box, but also how much of the quality of the data you maintain when you’ve got tons of computers hooked up to the box. Or to put it another way, scalability means that in even large deployments, you get all the data at high granularity.

Talking about scalability in pure device count is sort of like talking about network performance purely in terms of fault. It is possible to have poor scalability without having no scalability, when you sacrifice detail for device count.

Another key of scalability that many people don’t think about is performance of the device itself. It would be ironic to purchase a device to monitor network performance that had a very slow UI because it strained under the load of monitoring thousands of links.

One of NetQoS’s many accomplishments over the past six months has been getting a patent on a memory management method and system which allows us to manage hundreds of thousands of combinations in a very small memory footprint.

Memory management is a major part of scalability, because allocating memory during a programming operation is relatively expensive, in terms of operating processor resources, to allocate memory during runtime. Put another way: the more efficiently you use memory, the harder you can push the processor on other tasks. For this reason, scalability requires efficient memory usage.

In addition to our own products, we also use it in our integrations into Cisco Wide Area Application Services (WAAS) – we’re able to integrate code there with little impact to the host systems.

Saying that your business should never, never, never use cloud-based applications instead of desktop or network/server based ones is about as ridiculous as saying that cloud-based applications will eventually replace IT completely.  

With an article that begins with “Cloud computing apps are for suckers. If there is an alternative that runs locally on your own machine, it will always be better,” John C Dvorak, seems to be going from “baiting Mac users” to “baiting Google users.”

But let’s just take the argument at face value.  Some of the points he makes are good ones – specifically, the ones with performance issues. 

I don't care if you have 30-megabit-per-second service—you'll get flaky performance from most online apps, especially if they're popular. Always remember that your online speed is only as good as the speed at which data is coming at you: The application server may be swamped, and the various nodes along the route could become clogged, too. Nothing is ever as fast as the machine sitting on top of (or beneath) your own desk.

Your desktop is faster than the cloud – that’s true - but is your car?  Information stored in the cloud can be accessed from any place with a Net connection.  Information stored locally can only be accessed locally – well, unless you connect through a VPN or set up a VNC server.  But even for those of us that know how to do it, a VNC server is a hassle, and a security risk unless you do it exactly right.  90 minutes is horrendous downtime for an enterprise application, and Dvorak is right so far as any application where 90 minutes downtime is unacceptable shouldn’t be put on the cloud. 

But there are plenty of applications – and for small-to-medium companies, e-mail is one of them – where the losses incurred from 90 minutes of downtime is less than the cost of having a dedicated in-house application installed and maintained on the network.  (If the opposite is true, don’t use cloud computing, use the in-house application, and keep an eye on how it performs.)

Dvorak also points out that your data is at the mercy of the service provider and that if the service is cut off, for whatever reason, so is your data.  That’s true, but if you don’t back-up your data, your data can be lost by a hard drive crash.  Both are about as likely to happen, in my experience. 

To Dvorak, “People tend to forget that software is NOT a service; the whole cloud scheme is a scam to lock users into a single product and somehow extract more money from them.”  There is some aspect of vendor lock-in, but mostly cloud computing is a way to provide an application at low startup costs in exchange for revenue over time – whether through advertising, in the case of Google’s apps, or through a subscription model.  Yes, it is very much “renting” rather than “owning,” but that can very well make financial sense in many cases. 

After that, the arguments get a bit silly. 

What happens if the net is attacked and your entire cloud world is gone for days and days? It just happened in the Republic of Georgia, and it can probably happen anywhere.

If the Russians start bombing us, John, I’m sure that the boss will give us a few days off. 

Ask yourself why the heck will we need six-core, high-performance chips if the cloud takes over everything?

Why do we need six-core, high-performance chips now?  In a virtualized server, certainly we’ll need power to spare, but unless you’re doing video editing or animation rendering, a six-core chip is probably overkill.  And if we stop putting the big iron in the datacenters of big companies (very unlikely,) they’ll pop up in the data centers of the SAAS providers. 

When it comes to performance and scalability, absolutely, standard client-server IT applications and local programs are going to have SAAS beat.  Final Cut Pro is not going to the cloud.  Photoshop isn’t going to the cloud (though Photoshop Elements is…).  But the key advantage of cloud computing isn’t performance or scalability – it is portability.  This is why people will pay twice as much for a laptop with the same specs as a desktop computer.  Mobility is important.   

I wanted to name this post “Things to view in Denver: Talking heads” but no one around the office got the reference.

Well, if you were worried that Obama’s VP announcement would overwhelm your network, you were spared. The announcement came in the middle of the night – 3 a.m., in fact – on a weekend. But convention season is starting, and that’s a whole additional set of worries.

At 5 p.m. EST today, the Democratic National Convention will begin, and with it, streaming video from multiple news networks and the DNC itself, which, like NBC’s Olympics coverage, uses Silverlight to project a “high-definition” (480p?) image.

Unlike the Olympics however, there’s bound to be some event – a protest that goes wrong, a verbal gaffe, a moving speech – that becomes a viral video. The reason I’m pretty sure about this is that it’s in the interest of both political parties that something goes viral – something good for the Democrats, something embarrassing for the Republicans. Politicians will find a compelling video of an unplanned, sincere, candid, spontaneous moment, even if they have to manufacture one.

There’s bound to be online coverage from the major TV networks as well.

And then after that, the Republican National Convention – with streaming through Ustream.tv - is next week. And McCain is yet to announce his vice presidential nominee.

Those interested in Obama and McCain’s technology policies will find this article at Ars Technica interesting, while C|Net has technology policy information for Biden.

Cisco has put up a new video in their “Seminar and Webcast Series” talking about “Energy Efficiency in the Data Center.” It may be produced by Cisco but the key points are pretty much vendor-neutral – starting with the idea that “Green” computing is a political/PR buzzword, and the way enterprises should look at the problem is one of efficiency and of sustainability.

Data center power consumption has more than doubled since 2001; the worry is that the trend will continue on an exponential pattern. This power consumption mainly comes from cooling the servers, rather than powering the servers; and with each 1U server (running 24/7/365) requiring the same amount of energy per year as it would take a Toyota Camry to drive 15,000 miles, energy efficiency is crucial.

Part of the solution is to buy more efficient components that cost more up front but pay money back. Another part of the solution is virtualizing servers, consolidating servers, and decommissioning servers.

They also mentioned using provided utilities to step-down the voltage if the server was underutilized – a trick laptop owners have been doing to get more life out of their batteries on the road. Same concept – if you don’t need all the power, consume less of it.

As far as the network goes, data center consolidation brought on by advances in WAN optimization is a big step towards reducing utility costs. Another step is taking advantage of the movement towards putting tools in the network infrastructure itself rather than as separate appliances – for example, putting SuperAgent network monitoring software (shameless plug) into Cisco’s WAAS.

These are all some common sense solutions and probably not the first time you’ve heard them. But the key point of the video-seminar was that just as we keep harping on the fact that you need to baseline your network performance to ensure that the changes you make to your network are having the desired effect, you also need to baseline your power costs as you make improvements.

I can’t believe I missed this the first time around.

I was so focused on how the online Olympic video was getting through the last mile, that I completely forgot to ask: How the heck are they getting it from Beijing to the U.S.?

Douglas Gourlay at Cisco has been blogging about how NBC’s been using Cisco’s Wide Area Application Services (WAAS) for WAN optimization, so that NBC’s video editors can use three 155Mbps OC-3 pipes, combined and load-balanced (with, of course, Cisco gear) to get the files directly from Beijing. While I’m not 100% sure on “as if they were stored locally,” holds true, it’s clear that WAAS is capable of some amazing stuff – we know because NetQoS has SuperAgent integration on WAAS devices and ACE load balancers. We track stuff like that all the time.

“This reduces operating costs of housing, air travel, transportation, and food. Avoiding 800 airplane trips also supports NBC’s green initiatives for the Olympic Games.”

It also probably makes the video editors a bit grumpy that they didn’t get to go to Beijing.

What I’m curious about is what will happen after the Olympics. Just as Olympic stadiums still stand – and are used – in every host city, I’m wondering if the infrastructure that NBC has to Beijing to deliver high definition video will remain after the Olympics. As China starts to become a new superpower, more news and information is bound to come from Beijing, after all.

And if this can be done for one series of events in one major city, is it that far off from having video-heavy WANs in every city to cover every major event?

While we’ve talked quite a bit about what impact the Olympics may have on an enterprise network’s performance, we haven’t talked much about the performance of the NBC site hosting the live streaming of the Olympics. 

According to Jason Perlow at ZDNet, Limelight networks (which hosts the streaming videos) deployed the videos by going to the public internet by hosting the content more locally – at the ISP.  That means you’re viewing the Olympics through your ISP’s internal network, and the broader internet doesn’t even enter into the connection. 

This is smart thinking, it appears to be working, and by all measures this should be applauded.  Perhaps even duplicated – if you know that multiple employees will download the same content, local hosting on the LAN is preferable to duplicate download streams tying up the more expensive, slower WAN lines.

From the enterprise end of the equation, the fact that Limelight is delivering Olympics video more effectively just means that IT managers cannot count on their servers going down from being unable to handle the demand – IT managers still need to monitor their own networks for performance problems when a big event like the Olympics come up. 

However, it would be wrong to assume that Limelight’s strategy is the only reason why Olympic live-streaming hasn’t slowed to a trickle.

First of all, the site blocks 95.44% of visitors from accessing the content – because it limits the content only to those in the United States.  That’s a lot of people.

Secondly, the site requires Microsoft Silverlight. Most people don’t have Silverlight installed.  Some can’t even install it on their systems.  And there are certainly going to be a quite a few people who just didn’t think installing Silverlight was worth the bother to watch five minutes of Olympic footage they may be mildly interested in. 

And finally – none of the really popular sports are being streamed.  Gymnastics, Women’s Beach Volleyball, Swimming (with the exception of synchronized) and most of the track and field events aren’t available live. So you’re left with judo, fencing, and the decathlon.

So while it is a true technological wonder that the lights have stayed on and the site performs admirably – it is important to recognize that Limelight has not found a magic bullet to deal with extremely high internet video demand. 

Jim Metzler and Steve Taylor have another insightful article up at Network World – this one on the effects of the FCC ruling against Comcast over their BitTorrent blocking using deep packet inspection technologies.

Perhaps some of the best news for corporate network managers is that this is proof that equipment designed for DPI actually works – and evidently works well. So if you decide that you need more control for P2P traffic on your corporate network, this seems to be quite an endorsement. And, again pointing out that we’re not lawyers, there seems to us to be a fundamental difference in the ability to filter traffic on your own corporate network and on public networks.

This is true. But there is something here that is amiss.  Yes, deep packet inspection works.  Except for communication that is encrypted and decrypted.  Of course, if an employee is determined to jump through the hoops required to get a decent encryption on BitTorrent content, so that he can download the large, copyrighted, non-work related files at the work computer… well, at that point it ceases to be an IT problem and becomes an HR problem.

Chances are, anyone smart enough to set up encryption would be able to figure out to use their home broadband connections.  Can’t wait to get home? Set up a remote login. 

What is of more significance is the idea that it looks like at least some degree of network neutrality will be enforced by the FCC; the Comcast case may set a precedent and other ISPs may be wary of implementing DPI.  That may make a huge impact on deciding whether you want to try putting apps out on the cloud or whether you want to develop a solution on the WAN.