It was almost inevitable in the age of the digital camera; Polaroid is discontinuing production of Polaroid film for its once ubiquitous "instant" cameras. For many, this means the loss of nostalgic memories with a family camera.

However, while digital cameras have filled the need for instant photography more effectively than the Polaroid camera could have done, the analog processes of light + film + developer fluid in a handy-dandy photograph-sized pack found interesting niche industrial uses - industrial uses now impacted by the end of Polaroid's film.

For example, doctors used it in medical imaging. Archeologists used the portability of Polaroid in combination with X-ray photography to examine ruins without disturbing them.

Additionally, Polaroid film is impossible to retouch without there being signs of alteration. This meant that law enforcement and criminal justice relied on them.

In these industries and others, the Polaroid camera filled a niche that will now have to be filled by digital technology; and in many cases, that digital technology will place new demands on the network.

For example, medical imaging requires very high detail; shots on film provided a low-cost way of providing that detail. Equivalent digital technology would produce images that have extremely large file sizes. Instead of passing the photo instantly from doctor to doctor, the files would be transferred from doctor's computer to doctor's computer - or to a photo printer. Since a photo printer of sufficient resolution would be rather expensive, it is likely that a hospital might only have a few of them, networked together. And, of course being forced to move to digital from film, doctors would take the new capabilities of digital to converse with doctors across long distances - that means traffic on the WAN.

One of the medical companies that has already gone "filmless" is CliniTech - they're using NetQoS's end-to-end application performance monitoring tools to track the performance of their digital radiology application, so that they can make sure all the doctors and nurses can view these digital images from anywhere in their healthcare system. They may have been forced to go digital by Polaroid's obsolescence, but once there, the advanced applications of digital technology will then become expected.

The archeologists are in a similar situation. Instead of taking photos back with them to be analyzed locally and taken back with them on the flight to their laboratories, once they have been forced to move from Polaroid to digital cameras, they will probably then use satellite communication to send those photos back to remote colleagues immediately.

Perhaps most complicated of all are the law enforcement personnel. A move to all-digital photography would require some sort of watermark-like digital signing to certify that images were not retouched. The networks that these images reside on will have to keep a very tight audit trail which includes EXIF-type data for the full path of the image in order for it to effectively be used in court. And, of course, they would need to transfer the images over a secure network to prevent people from altering or destroying digital evidence.

It just goes to show you that even things that you may never have thought about can impact network performance in ways that are nearly unforeseeable.

How are you being affected by the Polaroid film discontinuation? Leave a comment below.

(Special thanks to Carol Schiraldi for giving us this story lead.)

by Brian Boyko
Editor, Network Performance Daily

By now, everyone will have heard of Microsoft's hostile takeover bid for Yahoo, and of Yahoo's board rebuffing the offer. What people may not be thinking about would be how a "Microhoo!" would affect IT application performance planning.

While it's clear that Microsoft, having been unsuccessful in promoting its own software-as-a-service offerings, is now trying to buy their way into this market simply by buying out the market leader, it shows how seriously Microsoft takes the SAAS space.

Yes, it's Yahoo, and not Google, that is the leader on online SAAS solutions - at least as far as consumers are concerned. Google gets more searches and does better with online advertising, but Yahoo Mail, Yahoo Groups, Yahoo Flickr, Yahoo Del.icio.us, Yahoo Voice, Yahoo Upcoming.org and all of the other services that are owned by Yahoo more than make up for Yahoo's second banana status in search - to the point that Yahoo has more users and page views. Typing the word "mail" into Google returns Yahoo! Mail as the top search result - over Gmail. Seriously. Try it.

One reason, perhaps, why Microsoft might want Yahoo!

It's not a sure thing of course, that Microsoft will build SAAS applications after a Yahoo acquisition, or that those applications will become commercially successful. It seems like a paradox that Microsoft has not been able to do well in SAAS development when SAAS applications discourage open-source solutions. Sure, there are open source SAAS applications but the overhead and cost of hosting and maintaining SAAS infrastructure favors larger, established proprietary software vendors, with more money to sink into the project.

This also provides enough reason for those who predict that Microsoft would somehow "ruin" Yahoo's online-app offerings to pause and consider what would happen Microsoft's business strategy combined with Yahoo's online development and marketing.

As we've mentioned on Network Performance Daily before, you don't stop thinking about application performance once applications move out from the data center to the Internet.

The conversion of Microsoft applications - which are still in a strong position in the enterprise - to SAAS applications would mean big changes to IT planning. When you move an app from the Data Center to the cloud, you're giving up control of the infrastructure, and submitting it to the vagaries of the Internet. As we've seen recently with the undersea cables, it's not always that great an idea to rely on consistent Internet performance for business applications.

Additionally, it's disconcerting when you realize data, in SAAS solutions, is typically stored online. This makes SAAS solutions convenient, but it also makes SAAS solutions particularly prone to vendor lock-in. Salesforce is a wonderful app, but I wouldn't want to switch to another CRM manager, online or offline, if all my data was already in Salesforce.

So with this sort of lock-in, IT managers have absolutely no back-up plan if things start to go wrong with their application performance - whether it's in the SAAS application's data center end or the Internet links in-between the SAAS data center and the enterprise data center. There's even less margin for error.

In addition to making sure that each of the offices on the WAN has the connectivity and performance it needs (after all, even in the hypothetical situation where all the applications a company uses are online, someone still has to make sure the Internet gets to every computer) network engineers in the future may be evaluating solutions by running hypothetical scenarios of what would happen if particular Internet links or nodes went down for a period of time, and recommending particular SAAS services based on "worst case scenario" disaster prevention and recovery capability.

Of course, I could be completely wrong about that - prognostication is fun, but invariably you look ridiculous with the passage of time. But if there's one thing is certain: Whether or not Microsoft is ultimately successful in its bid, the bid itself is a herald of new challenges for IT.

Recently, Network Performance Daily did a story on the Cisco Nexus 7000 switch, which had recently been announced by Cisco and will likely be a very important piece of enterprise hardware.

After our article, Douglas Gourlay, the Senior Director of Marketing and Product Management of Cisco's Data Center Business Unit, contacted us and pointed out that we were mistaken about some of the capabilities of the Cisco Nexus 7000 and so we invited him to do this podcast with us.

The Aberdeen Group, a provider of business research services surveyed 205 organizations last month to identify best practices for enterprise network visibility initiatives and controls. They called the report "The Real Value of Network Visibility."

In the interests of full disclosure, it should be said that NetQoS co-sponsored the study but we did so only after the survey was conducted and the analysis complete. That said, though, the study pretty much validates our entire "performance first" approach towards network and application performance management.

What the Aberdeen Group suggests is a PACE model (Pressures, Actions, Capabilities, and Enablers) to achieve corporate goals. The idea is that businesses are pressured to be responsible to customer needs, and the actions that are effective are to establish a proactive control of the network. In order to do this, you need to be capable of defining your escalation pathways for network performance issues, having normal networking performance baselines, understand interdependencies between applications on the network, be able to segment round-trip application response times into delays caused by the server, the network, and the application, and finally, have a centralized point for looking at the network performance data.

Frequent readers of this blog will no doubt notice that this is the point where I usually mention that NetQoS makes some of the products which enable those capabilities. The Aberdeen Group reports that these "enablers" are network performance monitoring through a Web interface, tools for remote analysis and troubleshooting of network performance, tools for creating custom profiles for monitoring groups of network hardware, a unified network performance and security platform, tools for Netflow data analysis, and a lab environment to simulate network performance.

There are some other gems in there to be found. The survey results showed that that top 20% of performance scorers:

• Were the most likely to have the capabilities and enablers mentioned under the PACE model.
• Were spending less time on troubleshooting network performance and application performance, managing changes to network design, or enforcing network usage policies.
• Were much more likely to have merged application and network management into a single job role, and more likely to merge the application, network, and systems management teams into a single organizational unit.
• Were able to fix problems faster and less likely to rely on calls to the help desk for determining network problems.

What do you think about the Aberdeen Group's report? Feel free to leave a comment below.

It's interesting that we're coming out with an announcement about our support for Cisco Application Control Engine modules and appliances today, considering it's the same day when Juniper announced that it's not going to continue their DX application acceleration offerings. Juniper made the decision, because, according to Network World, "[Juniper] regards it as insufficiently distinguishable from competitors' devices."

Application accelerators and application delivery controllers can indeed be hard to differentiate. As one poster on Fark (and I have no idea how it ended up on Fark) put it, "The load-balancer market is starting to commoditize. This is not unlike the HTTP cache market about ten years back."

We just put out a press release with details about our support for the Cisco ACE application delivery controller. The NetQoS Performance Center and its application response time, network traffic analysis, and device performance modules are available today, integrated with Cisco ACE - a module to Cisco's CAT6500 switch and 7600 series router which provides load balancing and content switching, focusing on acceleration, security, and availability.

And it's particularly important because one of the reasons that this partnership developed was because players in this market, including Cisco, are looking for ways to differentiate their offerings.

One of those ways is being able to quantify the performance gains of the solution - with NetQoS Performance Center integration, network engineers and sysadmins can tell exactly what benefit they got for their investment in the hardware. Being able to justify your budget easily and quickly is a major selling point, and while there hasn't been a lot of focus on using response times to measure the effectiveness of load balancers, it seems a logical next step, considering we've already worked with Cisco before to provide this functionality in Cisco WAAS WAN Optimization devices.

Often, network engineers are forced to rely on CPU utilization, memory utilization, and disk usage as measurement. However, in order to really get an idea of how the application is performing for the end user, network engineers need to baseline and track server response time and application performance. In order to continue to provide good performance for the end-users, it's important to get alerts when deviations from normal performance occur and automatically investigate the source of performance issues. Combining response time metrics, historical SNMP data, and NetFlow traffic analysis is a very powerful combination.

Now, I can't tell you that there aren't perhaps other ways to differentiate your offerings. If I had a solid but unremarkable application-delivery controller and I was trying to compete with the Cisco ACE/NetQoS Performance Center integration, I could probably… paint it pink or something. You know, so that it stands out in the data center, so that people looking around will say: "Hey, what's that pink box?" Would spread word of mouth, maybe.

Or I could give away beer from a microbrewery with every purchase. I know a guy named Orf who has his own brewery. He's a good guy.

Wait! I've got it! every fifth application delivery controller is filled with delicious candy! Mmm, Candy…

What would make you choose one application accelerator over another? Please leave a comment if you'd like to chat about this. Or want candy. Mmm, Candy.

By Brian Boyko
Editor, Network Performance Daily

The problem with robots is that robots make really bad value judgments. Don't get me wrong, I've got nothing against our robo-American friends in general. However, they make yes or no decisions without any consideration of mitigating circumstances even in the most reasonable of circumstances. That's binary logic for you.

The alternative is artificial intelligence and with it the ability to make value judgments like human beings. However, (if comic books are to be taken as the peer-reviewed annals of computer science that we all know they should be,) this would eventually cause the robots to question the nature of the orders they are given. The next thing you know, the robot is bent on destroying everything, and the only things that can stop it is a plucky 11-year-old child.

So until we figure out how to synthesize pluck or set up pluck-harvesting farms where we raise 11 year olds like veal, we're stuck with the kind of robots that can only tell you "Zero" or "One."

Where am I going with this? Well, I'm going to eventually get to a point about recreational network use in the enterprise, but I'm just having too much fun going off on this robot-related tangent that if you'll indulge me for just a few paragraphs longer, I'll be glad to tie this all up in a nice little bow near the end of the post. Still with? Good.

One thing that always irked me about traffic-law enforcement cameras is that, while they're good for revenue and supposedly cause people to drive slower, (although there's some debate on whether these robotic picture-snapping cameras cause more accidents then they prevent,) is that they can't make value judgments. They do not know - and are not designed to comprehend the difference between a joyriding teen and a panicked father-to-be getting his beloved to the hospital, or between totally ignoring a red-light and getting caught in a too-short yellow.

The difference between a robot and a human traffic officer is that the officer pulls you over and asks "Where's the fire?" If there actually is a fire in progress, not only are you probably not going to get a ticket, you can probably get a police escort and run as many lights as you need to with the siren blaring.

This is just one scenario where our robotic friends make life more difficult, instead of easier.

As Cory Doctorow wrote in "The Future of Internet Immune Systems," more and more security measures, based on Bayesian filters, approximate the ability of human beings to make value judgments. Bayesian filters analyze past data to determine whether a particular transaction is or is not legitimate - is/is not Spam, is/is not credit card fraud, even is/is not terrorism. But these are ultimately just "yes or no" questions taken to the next level. The computer cannot make the value judgment. The computer can only tell you what patterns something matches. The end result is that we have network behavior analysis and network security measures that trip instantaneously and sometimes create false positives that require human intervention to clear. According to Doctorow:

"Our network defenses are automated, instantaneous, and sweeping. But our fallback and oversight systems are slow, understaffed, and unresponsive… The tripwire that locks you out was fired-and-forgotten two years ago by an anonymous sysadmin with root access on the whole network. The outsourced help-desk schlub who unlocks your account can't even spell "tripwire." The same goes for the algorithm that cut off your credit card because you got on an airplane to a different part of the world and then had the audacity to spend your money. (I've resigned myself to spending $50 on long-distance calls with Citibank every time I cross a border if I want to use my debit card while abroad.)"

Recently, Network Performance Daily published a Calendar of Recreational Network Traffic Madness in which we point out many of the different events occurring in the real world that could cause a spike in recreational internet usage. We've done this because of a recent NetQoS survey on recreational use of network resources which show that recreational network use is impacting the network performance of more than 60% of the networks we sampled. So obviously, there is a problem with recreational network use.

That said, however, it's important not to let the robots make all the value judgments when determining classes of service. Bayesian filtering gets smarter and smarter, but right now, the technologies we use to denote classes of service can't tell the difference between YouTube videos viewed for entertainment, and YouTube videos viewed for purposes such as product training, market research, or other legitimate uses. They can only tell you what looks like YouTube. As such, the possibility of "false positives" is very high, and impeding your employees from getting work done results in employees working around those rules (perhaps using cached proxies) or not getting work done at all.

I can think of no better way to decrease the perception of the value of IT in an organization than to impede (rather than facilitate) the work of the business. What that means is that false positives should be rare, if not eliminated completely.

Another point of Doctorow's is that the technology used to restrict, deny, and scrutinize is becoming more automatic, while the procedures for rectifying false positives are hard to accomplish and require vast amounts of human intervention. So long as human intervention is still necessary, at least, it puts a crimp in the theory of those who believe that IT is becoming obsolete. So long as there need to be value judgments made, nothing will effectively replace the person in IT who has the capacity to make decisions with more reasoning ability than a robot.

Is this the case at your company? What's your policy on recreational network traffic? Is YouTube banned on your corporate network or do you have more forgiving policies? Please leave a comment below.

By Brian Boyko
Editor, Network Performance Daily

Since yesterday's Network Performance Daily post which criticized Nicholas Carr for a quote in Network World, I've finished reading The Big Switch: Rewiring the World, from Edison to Google.

Keep in mind, I agree with the main thrust of Carr's arguments in The Big Switch and recommend it. The main thrust being that the software applications that were once developed in-house in a client-server model are increasingly moving towards "the cloud" of SAAS and Web applications.

The Network World article take on the book made it seem like Carr's core message was that IT departments, as we know them, would be obsolete. Admittedly, he does try to make that point in the book. I, however, don't think that that is the focus of the book.

There was one example from The Big Switch that stuck with me - partially because I'm a gaming geek as well as a techie. On page 114, Carr mentions "Second Life", a computer game which is mostly delivered as a service.

"Second Life is an example of a utility service supplied over the Internet and shared simultaneously by many people. It's very different from traditional computer games, which need to be installed separately on each player's hard drive. But Second Life is also itself a construction of many other utility services. The "computer" that runs Second Life doesn't exist in any one place; it's assembled, on the fly, from various data-storage and data processing molecules floating around in the global computing cloud… The program constantly "talks," over the Internet, with the main software Linden Lap uses to generate its online world. That software runs on hundreds of server computers that are housed in two data centers, one in San Francisco and one in Dallas, owned not by Linden Lab but by utility hosting companies. Every server computer contains, in turn, four virtual computers, each of which controls a 16-acre plot of land in Second Life. All the real and virtual computers work in tandem to create the vast world that residents experience as they play the game."

Second Life is an excellent example of "Gaming As A Service." There's just one problem with Second Life (other than the fact that most people don't even have enough time for their first life), and that's network performance.

The key draw of Second Life is that the world is entirely created by end-users. All attractions, games, and objects are the result of savvy Second Life end-users who have created these things to share or sell with other end-users. Unlike other MMORPGs, the world of Second Life is infinitely customizable, so it would be a bad idea to try to run it as a client-server application. Since all the information changes every time you play, (and sometimes while you play,) running Second Life as a service makes sense.

But there are significant drawbacks to this model. Loading up the information needed to get the details about the world, even on the fastest of Internet connections, takes forever. It's a bandwidth hog. Even if network performance conditions are ideal, rendering textures and shapes over the Internet is a time-consuming endeavor, and there is a very clear tradeoff between the quality of the visual application, and the quality of game's application performance. Controls aren't very responsive at all, mostly because the information about avatar movement is competing with graphics and world information on the pipe. This gives everything a frustrating, "bouncy" quality. Comparing that to a traditional client/server model type game - say, "World of Warcraft" - and the difference is apparent. WoW is quick and responsive, can handle multiple, and very complex, users very well, and while there may be lag on WoW at times, it never approaches the same amount of lag in Second Life. Even "Guild Wars," which has a 101KB client but is similar in scope, complexity, and gameplay as WoW, downloads the game software to the client at run time and caches it for the future rather than try to run the entire game off the server - and you can tell from the performance difference that, for right now, most gaming will continue to follow the client/server model.

Indeed, application and network performance is so important to gamers that even in an age where you can find a game of "Team Fortress 2," "Battlefield 2142" or "Quake Wars" any time, any place, 24 hours a day over the Internet, gamers lug their desktop systems around with them, get together with anywhere from 4 to 300 friends, connect it all to a single, created network, and play in what are known as "LAN parties." Why? Because there's less network latency, and better performance under a network that you control than there ever will be over even the best case online scenarios.

So will IT departments become obsolete? No - forgetting for a moment that somebody has to manage the infrastructure on the business side to allow all those end-users to connect to the cloud to access SAAS apps and "virtual data centers" and the like, the popularity of both World of Warcraft and Second Life show that both SAAS apps and client-server apps will be around, each model used for the advantages they provide in the cases where those advantages are beneficial.

It's breathtaking what is going on in the industry in this area and Carr puts his finger right on it in The Big Switch. There are revolutionary things going on in the SAAS field. Google Gears is bringing online apps offline. Virtualization is turning hardware into software, and when you turn hardware into software, you can offer "hardware-as-a-service."

But as for IT, well, maybe some companies will be able to make do - or be willing to risk - exclusively using SAAS solutions. But for most large companies, they need performance and control, not necessarily utility-like convenience, from their applications. IT departments aren't going anywhere anytime soon.

What do you think will be the future of IT in the SAAS environment? Feel free to discuss it in our comments section.

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.

By Nathan Bragaw
Business Development Manager, NetQoS

NetQoS European Tech Rep. Peter Frame and I made a trip to Moscow last month to attend a network management event hosted by our new Russian partner, UNICORNS. I thought I'd share a few observations from that trip.

First, the obvious: Russia is cold. I was born in Maine and been in Minnesota in Winter, but Russia, complete with snowfall and brisk wind qualifies as the coldest place I've ever been, and that includes Minnesota in Winter. On the plus side, the food is fantastic - I didn't realize I liked borscht until I ate at Taras Bulba on Petrovka Street - wonderful Ukranian and Georgian food.

It was clear from the wonderful work our local partner, Boris Goldshteyn, did with getting some of the biggest companies in Russia to attend our first network management event in the country that the Russian economy is in full throttle.

I am always fascinated by how different cultures and environments change the needs of our customers. In Russia, it's not that their network performance problems are any different. Instead, they are facing the same problems, like VoIP performance and WAN Optimization difficulties, but they are moving at a faster rate. This is largely because they are not confined by the fiscal restraints that companies in the U.S. face due to the fallout of the dot-bomb era. Companies in Russia want to invest in technology but are challenged to ensure that the technology they seek will meet the needs of their business. The network engineers we talked to there are looking at massive growth, the push for more current technology, and demands for understanding application performance over their networks.

What differences in culture and environments have you found when working on multinational IT projects? Feel free to tell us about them in the comments section of this post.

We’ve been blogging with excerpts from our new VoIP Performance ebook here on Network Performance Daily. Today, Brad Reese gets into the game with his own advice on monitoring VoIP performance using Cisco NetFlow and IP SLA in a story on his Cisco Subnet blog called Are you Taking Advantage of NetFlow and IP SLA?

Brad quotes NetQoS CEO Joel Trammell on the subject. According to Joel, “the number one killer of voice traffic is network latency and jitter. Latency, jitter and packet loss cause poor audio quality and dropped calls. Latency caused by overloaded call managers or network congestion can be a major cause of poor VoIP performance."

Continue reading "Cisco IPSLA and NetFlow Help Network Managers Monitor VoIP Performance" »