As Halloween approaches, I’ve got a bit of a horror story to keep you up at night. 

There’s an interesting quote that’s somewhat appropriate now.  Well – song lyrics anyway.  “Did you feel you were tricked / by the future you picked?” Which, I’m told, are part of a Peter Gabriel tune for a Pixar movie, but which I only came across when reading speculative fiction about quantum AI computers running 419 scams.

The thing about the future is that by the time it gets here, it’s already the present. Wait, I’m sounding like Criswell there… what I mean to say is that only a couple years ago, the big story in technology was how IT departments were becoming centralized due to advances in virtualization technology that cut down on hardware requirements and power consumption.  Now the next level is cloud computing; an idea, fundamentally, that you can centralize data centers even further by centralizing them with the data centers for other companies via a third-party provider. 

Taken to an extreme, it’s easy to think of a day when even these cloud computing centers become even further consolidated – perhaps one on each inhabited continent.  “A world market for maybe five computers” indeed…

Except, it’s not quite that easy.  The transition from in-house architecture to cloud computing resources is just about as difficult as the transition from real servers to consolidated virtual ones, and the big problem is ensuring network performance – that data gets where it needs to go quickly.  

Much as the server consolidation/virtualization problem was helped with better virtualization technologies and advances in WAN optimization, the current rush in IT tool development is in the cloud computing area (not that we still don’t have a-ways to go with virtualization and consolidation).  And some of these cloud-computing tools are starting to appear – for example, self-managing environments…

One of the newest approaches is the concept of the "dynamic infrastructure." Rather than a simple collection of humming boxes or cards designed to push data this way or that, the dynamic infrastructure brings together virtual networking, automation and resource management with tools like application management, security and policy management to create a self-managing environment that can react to changes in workloads and other needs with minimal human interference.

Lori MacVittie, technical marketing management for application services at F5 Networks is one of the prime movers of the concept, which she says will be the inevitable result of the transition to the cloud. 

"When the entire data center is founded on a dynamic infrastructure, the infrastructure can react itself to changing network and application conditions and needs," she says. "When the entire ecosystem is sharing status and information about performance, every component can adjust itself dynamically to what’s needed now to improve performance or maintain availability. And it happens automatically, based on the specific needs of the business and IT."

Virtualization has underscored the need for performance management; back when everything was run on actual servers, you could almost always fix a problem by finding out where the bottleneck lied and increasing the amount of stuff.  Not always, but almost always.  But with virtualization, you’re essentially managing an interconnected ecosystem of stuff and… well, stuff that’s not stuff.  “Unstuff,” to borrow a bit of NewSpeak. 

And this management is so complex that it has increased the demand for network engineers, yes, but it’s also increased the demand for software to come along and replace the more tedious tasks of network engineers, automating the processes where possible.

But what if there is no upper limit?  What if self-managed cloud computing software is exactly that – with computers calculating exactly what needs to be done to preserve performance and then automatically fix it? 

And that network monitoring software…. WAS ME THE WHOLE TIME!!!!!

AAAAAAAAAHHHHH!!!! 

WAN Optimization solutions – assuming that they work for the applications you need them to work for – are like magic. Consolidating data centers, from a relativistic standpoint, actually moves users further away, so to consolidate data centers, and lowering costs, WAN performance needs to be good enough for the remote users to do their jobs.

But the irony is that as data centers are becoming more consolidated, users are becoming less consolidated. More people are telecommuting than ever before. (Even if the number of full-time telecommuters has gone down, part-time telecommuters rise). It makes a certain amount of sense – an employee too sick to come into work (and infect others) but not too sick to actually work might file some work from home, or sales teams might file reports from the road.

This creates a problem for most WAN Optimization solutions because most solutions require appliances at both ends of the WAN link. Telecommuters are usually accessing the applications from the public Internet. Software-based WAN optimization controllers (“Soft WOCs”) can do some of the work, but telecommuting requires high-performing broadband as well as optimization solutions.

The way that Soft WOCs work, is essentially to recreate a lightweight version of the client that normally sits at the remote end of the optimized WAN link in the software on the mobile computer. The Soft WOC then optimizes the stream between the telecommuter’s computer and the data center.

The problem is that WAN optimization is less efficient when you have a single user than when you have multiple users on the same stream. First, having multiple users accessing the same data means you can take advantage of caching. Caching is only useful on a Soft WOC link if the same user accesses the same data twice.

Secondly, in a normal optimized WAN link, there is only one TCP stream to worry about – the optimized one, with individual streams recreated only at the two ends of the transaction. Each SoftWOC essentially creates its own stream. For that reason, telecommuting solutions simply aren’t going to give you the same dramatic increase in performance you’d get from more traditional WAN Optimization.

On the other hand, any improvement is still improvement. Just be sure to baseline your performance and see if the value is there before deploying Soft WOC solutions.

We’ve produced a follow-up to our earlier “The Network Company” video, this time looking at LAN vs. WAN application coding, TCP Slow Start, and WAN Optimization. Instead of giving you a detailed run-down, I’m just going to go ahead and embed it right here.

I love any day when I get to smash citrus with a large blunt object at work...

Network World’s Jim Duffy’s latest article, “WAN critical to virtualization’s payoff” has me in knots. 

It’s well known that by virtualizing servers, you can consolidate them more easily in a single data center; but in order to maintain performance, you need high performing, low-latency WAN connections.  We’ve written about this before, and it’s only more relevant with VMWare announcing on Feb. 3^rd that they are providing an Open Source Virtual Desktop client.

But Duffy’s article seems to be focusing on the idea of virtualizing the desktop on backend servers, rather than virtualizing backend servers.  The rest of the article denotes all the challenges of doing so.

Now, there are benefits to virtualizing desktops – key among them the idea that software problems can simply be solved by replacing a user’s virtual desktop with a separate virtual desktop – instead of dispatching someone from IT down to the user’s physical location.  This is a laudable goal.

However, virtual desktops are prone to poor performance over the WAN, because, like video or VoIP, it’s an interactive, latency-sensitive service.  Specifically, let’s look at mouse input.

When you operate the mouse on your computer – feel free to do so right now, (unless you’re reading this on an iPhone, in which case, carry on being smug) -  it may seem like an instantaneous reaction.  You move and the mouse moves with you.  This is not true.  It is an illusion. The output, however, comes so quickly after the input that the human body can’t tell the difference.  This is because the input has to go from the mouse to the computer’s IO port (usually USB), get processed by the CPU, and painted on the screen by the GPU out to the monitor. 

However, in a virtualized desktop, the input goes through the user’s IO port, gets processed by the CPU, and then pumped out to the Ethernet connection to the WAN, is processed by the CPU on the server, is output back over the WAN, which is then processed by the CPU of the user and painted onto the screen via the GPU. 

Point is, you’re adding an entire round trip across the WAN to the process.  So even if there’s no congestion, if the round-trip latency due to distance between the user and the data center is 100ms, you’re adding a tenth-of-a-second delay.  That will probably be noticeable.  And there are other sources of delay on the WAN.

This does not even take into consideration the data involved in pushing video data out to the remote desktop.  Long story short, virtualized desktops are probably a good idea on the low-latency connections that you’d find on the LAN, but trying to operate them over the WAN probably won’t work that well.  Is the benefit of virtualizing the desktop (or of consolidating virtual desktops) so great that you’re willing to suffer through poor end-user experience?

Which means that the premise of the entire article frustrates me.  Yes, it’s obvious that you need to have low-latency performance with your WAN to provide for virtualization – and good performance is a good thing; but at some point you are going to hit the law of diminishing returns.  If you’ve been monitoring your network performance and have the capacity to try to serve remote users virtual desktops in under 150ms, feel free to give it a try, but ultimately, will virtualizing the desktop over the WAN provide the best benefits as a whole? 

What may bear more fruit is to have applications virtualized and sent over the WAN onto existing, local desktops, much like XWindows apps back-in-the-day. 

An interesting post over at Slashdot pointed me over to a Network World story by Mitchell Ashley about how Windows 7 wouldn’t be a compelling upgrade from Windows XP. The interesting aspect is that Ashley goes on to suggest that perhaps the idea of OSes might become irrelevant if you move to thin clients connected to virtualized computers over the LAN.

The future Simon paints is one where these personal and business computing environments are virtualized onto the same computer, rather than intermingled as they are today. Businesses will deliver virtualized full OS plus apps, and stand-alone virtualized apps, to computers that users own. This maintains the security of corporate data and applications, and allows the business to viably deliver a computing environment they manage on computers they don't. Obviously this vision is in line where Citrix is going with XenServer, XenApp and their newly announced Project Independence, and given my own views about desktop and application virtualization I can see merit in a lot of Citrix's vision.

While we haven't seen much of this yet, I believe it would be wise for Microsoft to continue to improve Windows 7 as an easily virtualized OS and a platform for delivering virtualized applications. Microsoft has partially move Live Essential apps into the cloud. As they move Office and other apps online, the OS becomes thinner and thinner, less bloated with applications that entangle themselves into the registry and Windows folder of Windows 7.

You know what, I might be wrong on this – but I don’t see it happening.

This is not to say that thin clients and virtual desktops don’t have their place, but the problem with virtualizing the desktop is that offloading processing to a datacenter means, necessarily, more traffic on the LAN. Individual applications may be run remotely, sure, but operating systems – or specifically the graphical user interfaces of those operating systems – carry a lot of overheard. (If we were all using command line interfaces, the overhead would, of course, not be nearly as great.)

Additionally, companies have been moving more towards having consolidated servers connected to the end-user via the WAN – by bringing the servers closer to the datacenter, you’re also, in effect, moving the users further away. You can have virtualized desktops saturating your LAN, or virtualized servers saturating a WAN, but it would be extremely unlikely that you could have both on the same WAN.

What seems more likely is the use of virtual servers to serve up specific applications – applications that can be optimized to reduce overhead on the network. I just don’t see that happening with XP, nor Windows 7 – perhaps only the next generation – the Microsoft Cloud OS, perhaps – might be light enough to handle virtualized desktops. Then again, a computer’s what, $300 from Dell nowadays? And are you saving that much if you have to get a thin-client appliance for each user instead of buying a general purpose PC?

There have been some worthwhile attempts to do the WAN equivalent of having a cake and eating it too - a number of WAN Optimization vendors are putting in Windows services on the WAN Optimization blades themselves.  That is, one of the ways they optimize the WAN is to keep traffic off of it – and one of the ways to keep traffic off the WAN is to take care of Windows services on the branch LAN, before it even reaches the WAN.  In a way, it’s sort of the opposite of server consolidation – but since you have to run the blade for WAN optimization purposes anyway, you’re not adding additional hardware or sucking up much more power. 

This is pretty much speculation at this point – but speculation is fun, isn’t it? I’d love to hear your comments on this.

By Steve Harriman

Last Tuesday, Riverbed, known primarily for Steelhead, its WAN optimization controller (WOC), acquired Mazu, known primarily for its network behavior analysis detection (NBAD) tool Mazu Profiler. Riverbed said that they’re planning to integrate Mazu’s technology into their own products.  Similarly, Blue Coat, another WAN Optimization vendor, announced earlier today that they are going to partner with Lancope, another NBAD vendor, for much the same reason.

Before the acquisition, both Mazu and Lancope had been retooling their messaging – moving from a security focus to a more of a network performance monitoring focus in an attempt to appeal to a much broader market. In the long term, it’s likely that NBAD is unsustainable as a standalone market – but could be part of the broader set of network performance management disciplines. It appears that the WAN optimization vendors agree and are becoming interested in expanding their performance management capabilities. Indeed, Blue Coat already demonstrated this with its 2008 acquisition of Packeteer. In hindsight, it’s a little strange to see network performance monitoring and network behavior analysis as two separate fields. 

However, these flow-based NBAD technologies should not be confused with the Cisco-NetQoS technology in Cisco’s WAN Optimization offering--WAAS. In July of 2007, Cisco and NetQoS jointly developed instrumentation for WAAS devices that feeds key performance data to our application response time monitoring product SuperAgent.  SuperAgent was designed from day one to track application-by-application, subnet by subnet, the end-to-end performance of applications running over WANs, and merely had to be adapted to the optimized WAN environment. The SuperAgent-WAAS integration restores visibility into optimized WAN links which create unique visibility problems by breaking the TCP stream up into three separate streams. Without instrumentation in the WAN Optimization Controllers (WOC), you need to have monitoring equipment on both ends of the optimized connection. That gets expensive, so it makes sense to have the monitoring software embedded (at no additional cost) in the WAN optimization equipment. 

Without this tight integration, you can still derive a lot of performance-related information from the WOCs as long as they export standard network flow datagrams, notably NetFlow or IPFIX. This data provides visibility into traffic composition across the optimized link so you can see what effects the WOCs are having in reducing traffic. However, it doesn’t tell you anything about the end-to-end response times so you can’t tell if they are better or not (which is severely disappointing if that’s why you bought the WOCs in the first place). NetQoS customers use our ReporterAnalyzer product to monitor NetFlow/IPFIX exports from these WOCs, including those from Cisco, Riverbed and Blue Coat.

It’s not just enough to optimize a WAN connection and hope for the best. If your WOCs–from whatever vendor you choose—are to be effective, they should be monitored. In fact, it’s really smart to monitor your links before you deploy WAN optimization gear so you know which remote sites are the best candidates and to give you baseline performance statistics. Performance monitoring not only helps you measure the performance improvements you’re getting, it helps you solve problems faster.

Given this, it may seem strange that Riverbed would be interested in NBAD technology which gives it NetFlow visibility but not latency visibility across the three segments of the optimized WAN link. We should assume that Riverbed will use its newly-acquired technology for more general purpose monitoring and expand its capabilities over time. Interestingly, Blue Coat’s roots are in the security space and it’s quite likely that Riverbed’s acquisition was, at least in part, intended to bolster its own security-related offerings.

NetQoS has offered NBAD capabilities in the NetQoS Performance Center since February of 2008.  

[In the interests of full disclosure: Network Performance Daily is the “house organ” company blog of NetQoS, and is competitive in the behavior analysis space to Mazu and Lancope. –ed.]

Steve Harriman is VP of Marketing at NetQoS.

Chandra Hosek, Ben Erwin, and Andrea Stout contributed to the research of this post.

President-Elect Barack Obama, recently put a new video on Change.gov, the official Web site of the office of the President-Elect. In the video, Obama is seated in the office of the President-Elect, sitting in the chair of the President-Elect in front of the desk of the President-Elect. And if I had to guess, he’s probably reading prepared notes from the teleprompter of the President-Elect into the YouTube camera of the President-Elect.

These YouTube videos aspire to function much like an online, 21^st century version of the FDR’s “Fireside Chats.” Coincidentally – or perhaps not - Roosevelt’s first Fireside chat, broadcast in 1933, was entitled, On the Bank Crisis. This was also the subject of Obama’s broadcast. And like FDR, Obama is proposing a federal employment program much like Roosevelt’s New Deal.

During the New Deal, the Civilian Conversation Corps, or CCC, was a work-relief program designed to keep people employed with a semi-steady paycheck. One of the main ways that the CCC employed young Americans was by putting them to work solving the environmental problems of that era – which mainly involved flood prevention, soil erosion prevention, wildland fire suppression, reforestation, et al. You can go to Wikipedia for the full details.

Similarly, Obama’s plan, (or the sketches of it outlined in the short YouTube video), calls for increased energy efficiency in national infrastructure. Obama didn’t mention it specifically, but it’s not a far guess to think that part of this process will be “greening” Federal IT – and that usually means server consolidation (perhaps aided with WAN Optimization) and virtualization – to do more with less of a power draw – as well as putting the network to new uses, such as teleconferencing instead of spending money on airfare. Both of these will require network monitoring and adept management.

What Obama did specifically mention:

“It is unacceptable that the United States ranks 15^th in the world in broadband adoption.”

Hmm. Sounds familiar. Sounds like something we’d say. (Mr. President-Elect, are you subscribed to our RSS feed?)

The CCC, and similar program WPA, also focused on building and improving the infrastructure of the country – broadband improvements, of course, are improving digital infrastructure. (Of note – American broadband improvements must be done on American soil, and can therefore be almost “outsource-proof.”)

Also of interest was Obama’s pledge that:

“In addition to connecting our libraries and schools to the internet, we must also ensure that our hospitals are connected to each other through the internet. That is why the economic recovery plan I’m proposing will help modernize our health care system – and that won’t just save jobs, it will save lives. We will make sure that every doctor’s office and hospital in this country is using cutting edge technology and electronic medical records so that we can cut red tape, prevent medical mistakes, and help save billions of dollars each year.”

We at NetQoS have a little bit of familiarity with how difficult medical networking needs can be. In Volume 3 of Performance Edge Journal, we published a case study of OSF Healthcare, which is a network of multiple acute care, long-term care, and college of nursing facilities and also a primary care physician network.

One of the applications that OSF wanted to implement included Picture Archival and Communications System (PACS) – in order to send and manage very large cardiac images. The application had very slow response times, and you know, when something’s wrong with your ticker, time’s of the essence.

Anyway, NetQoS considers this one of our big success stories. Through SuperAgent, they found that the delay was caused by excessive server response times, and using ReporterAnalyzer, they were able to figure out that some cardiac images were being sent to different sites across the WAN and not stored locally, slowing down retrieval times considerably, taking up large amounts of bandwidth unnecessarily.

Whether or not Obama’s plan will actually work, at least he seems to be aware of the real need for network performance in the healthcare industry.

At the risk of waxing political; Obama talking about technology policy means that the next four years (at least) will be interesting times for geeks. Under the Clinton and Bush administrations, discussions of what should be done about networking issues were mostly confined to – well, to blogs like this. (And even then, it was mostly confined to Slashdot). But, whether or not you agree with him, Obama seems to be using the power of his office – or of his future office – to call attention to the problems that up to now, only us techies were paying attention to.

Part 5 in a series adapted from Joel Trammell’s Keynote Speech at NetQoS Symposium 2008

One of the big downsides to WAN Optimization is that you’re breaking up the TCP session that used to be from one end of the network to the other into three independent TCP sessions.

To measure the response time after WAN optimization is deployed, NetQoS worked with Cisco to develop code that exists on every Cisco WAN optimization device that ships. That solved the problem – at least for Cisco WAAS users.

But if I can generalize, you talk to a WAN optimization vendor and they will tell you, "Well, who cares about breaking up the TCP session because we're going to make your network so good you're not going to have to deal with performance problems."

That’s not reality. They will solve a certain set of performance problems, to be sure, but in some cases they may exacerbate problems.

For example, earlier this year, I recall that a Riverbed box had serious issues around AutoCAD. When AutoCAD changed the file format version, the WAN optimization implementation was actually slowing down AutoCAD. That’s an important area that people don't necessarily think about when they deploy WAN optimization: Did it actually do any good and how can you quantify how much good it did?

You have to do some pretty sophisticated analysis to understand what applications are going to benefit from WAN optimization, or any other technology addition for that matter, and which aren't. It's not always obvious how much data reduction occurred. That's one of the big selling points, right? You're not going to have to transfer all this volume across the network; well can you quantify how much data reduction occurred on the network?

Finally you want to be careful what applications may break when they're optimized. So, with WAN optimization the network performance metrics you’ll want to see are response time and traffic flows. That ability to understand and “re-put together” the three response time segments that were broken by putting in WAN optimization in the first place.

[Ed. Note: 17 November - In our comments section, Bob Gilbert from Riverbed points out that the AutoCAD problem has been addressed with a patch from Autodesk, and that the problem with AutoCAD's .dwg files were not Riverbed exclusive.]

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?

Earlier today, Network World hosted a live chat with Jim Metzler, of Ashton, Metzler, and Associates on implementing WAN acceleration. They’ll have the full transcript up tomorrow on their site, but I attended and wanted to bring back a few highlights. 

-----

Question: What is the one question that should be asked when evaluating products that you don't see people asking?

Jim Metzler: One thing that I think that people should ask: What has gone wrong in previous deployments?  We have all been around long enough to know that things do tend to go wrong at least occasionally.  For example, some people have found that once they deploy a WAN optimization controller (WOC,) that they lose management visibility.

Question: We are constantly battling latency across our MPLS network.  We have retail stores that connect to HQ data center.  How do we improve WAN performance?  Do we need to implement QoS?  Or should we use a different WAN protocol for our Cisco routers?

Jim: MPLS comes along with service classes that promises a guaranteed latency.  For example, a given service class may promise that latency will not exceed 50ms.  If your problem is that you are not getting what you were promised, that is an issue to take up with your vendor, or, based on your contract, to possibly change vendors.  If the issue is that the latency that you are promised is not good enough, I need to know more about what the problem is.  For example, if the issue is that you are running chatty protocols over the WAN, then a WAN optimization appliance might be helpful.

Question:  How do WAN optimization technologies fit into a more VIDO oriented desktop/branch and/or more XML oriented apps?

Jim: The movement to implement virtual desktops is a bit behind the movement to deploy virtual servers.  As we deploy more virtual desktops, that will mean more traffic from the data center to the branch which will most likely need optimization.

Question: How does WAN accellerationfit into scenarios with heavy ICA traffic or Notes replication traffic?

Jim: WAN acceleration is a very broad topic.  Some applications (CIFS traffic that results from server consolidation) scream out for optimization.  Other traffic (VoIP) requires QoS so that other traffic (bulk file transfers do not interfere with it.

The bottom line is that there are differing traffic types and they often require different techniques.

Question: Is there any company that has the best all-around solution?

Jim: No.Okay, my answer was intentionally brief.  Your question goes to one of the key challenges facing IT organizations today.  A given supplier might have a great solution for data replication but not so great for CIFS.  Another vendor may have a great solution for CIFS, but not so much for data replication.

This presents IT organizations with a challenge - what problems are they trying to solve today?  Next year? You have to decide.  Do you choose the best solution to today's problem knowing it might be sub-optimal for tomorrow's?

The good news here is that over time the differences between the suppliers on common functionality (compression, caching, protocol acceleration) will diminish.

Question: What question do you hear the most about this product category?

Jim: “How do I get started with evaluating these products?”  “What new directions are the gear vendors taking these products?”

With regards to WOCs: Adding support for specific applications such as share point or SAP.  Creating templates to make it easier for IT organizations to configure the device to support key applications.  Embracing virtualization.

With regards to Application Delivery Controllers (ADCs): Offering virtualized solutions, adding security functionality, adding functionality such as XML processing, Integrating with Business Intelligence tools. 

Question: Do you see distinct advantages to implementing QoS in a WOC rather than the router level? 

Jim: This is a really fundamental question.  I believe that one of the reasons that we have not implemented WOCs more broadly is that we have not answered some basic questions such as what functionality should be done where.

The question is further blurred by the fact that WOCs are being integrated into routers making it tough to say where QoS was implemented.  Bottom line: I think you can make either approach work.  It comes down to factors such as how rich is the QoS functionality in the WOC and how easy is it to configure and manage the QoS functionality in the WOC or the router.

Question: Some users claim that acceleration claims made by the vendors are bogus, that claims of 400% improvements are marketing garbage (as you can’t improve speed faster than the original base speed) What are your thoughts on speed claims by vendors?

Jim: The acceleration claims made by the vendors represent a test done in a laboratory.  While these might give some insight into how the devices will perform in production networks, they are not definitive.  IT organizations must test the devices in their network to understand what types of improvements they will realize. 

Question: Any thought on masking poor application architectures with WOC or ADC products?

Jim: This is a hot button to me!

For example, most IT organizations do not spend much attention on how apps will perform over the WAN during development or acquisitions.

A lot of our current problems would go away if apps were designed to run better over the WAN.

For example, one company I worked with found out that the browser in the branch offices were downloading a 3MB file just to open it up and extract a 10 digit ID.  Talk about a badly designed application!

Question: Where is the next big thing: security, storage, or--?

Jim: I think that there will be a lot of next big things.  I recently wore a series of articles for Network World in which I described "The Perfect Storm." 

Let me explain.  Today over half of the outages occur based on ineffective change or configuration management.  once we move to an environment with a virtualized desktop, routers running VMs running all kinds of things, communicating with a virtualized application delivery controller (ADC) that front ends a Web server, app server and database server, all of which are virtualized and which use virtualized storage, then the situation gets very thorny. 

Can you imagine how much many more outages will occur in a fully virtualized environment?

Sticking with this: Today when an application is not performing well it is difficult to identify the root cause.  That will be much more difficult in a fully virtualized environment. 

SOA really worries me.  By SOA, I mean Services oriented architecture.  Some think SOA is the precursor to an SOB and they may be right.

With an SOA, an application is comprised of multiple web services - for the sake of example - say 8.  Now, these Web services are running in different data centers - say 5.

Now the WAN impacts that application performance many more times than it does in today's n-tier applications.  This will be a huge challenge, but it gets worse - these Web services are reusable.

That means that multiple apps are using the same web services at the same time - that drives the need for QoS for Web services

This is all extremely demanding. 

Then there is Web 2.0 and mashups. With a Mashup your app is using apps designed and managed by other entities.  You have no control or visibility into those other apps.  This will be extremely challenging.