Capacity planning methods need to evolve into real-time management to take on resource allocation in dynamic virtual environments, enabling IT departments to successfully grow their virtual deployments.

By Denise Dubie

IT managers are no strangers to capacity planning, but many have yet to update their practices to account for a fundamental change in how resources are being consumed: virtualization.

Capacity management challenges persist in virtual environments

Virtualization changes a somewhat static environment into a dynamic one in which resources are moving about with relative ease, but not always at the control of the IT managers. Industry watchers have been warning of the need for better capacity planning and ultimately capacity management processes since x86 server virtualization started to take off in enterprise IT shops.

"Capacity planning today is all about trying to ensure that you have enough capacity and memory cycles to meet workload demand. But virtualization causes new variables to be taken into consideration, and power consumption is just one among many," said Cameron Haight, research vice president at Gartner, in a February 2009 interview. "For IT resource planning (ITRP) there are several more elements to consider and the process must become much more strategic within an enterprise."

Continue reading "Are your capacity planning practices obsolete for virtualization?" »

A study by L.E.K. consulting, a business strategy and marketing consulting firm, recently conducted a survey on media consumption habits; and what they found turned out to be a bit of a shock. 

According to the survey, 32% of users listen to an average of 5.8 hours of Internet radio a week.  That’s huge.

The reason it is huge is because unlike a lot of high-throughput downloads; streaming radio tends to be a constant drain on bandwidth.  Sure, a 5GB file is a lot to transfer, but it saturates the available bandwidth in the pipe for a limited amount of time.  On the other hand, 160mbps streaming audio improperly configured into a high QoS priority knocks out 160mbps of your total bandwidth.  Multiply that stream by the number of users streaming; and you can see why a new interest in streaming Internet radio is something to take note of. 

The other major thing from the report worth mentioning is that “e-readers,” like the Kindle, have been encouraging people to consume more written words – digitally downloading them.  While only 10% of consumers own e-readers, 48% of those who do report reading more books, and only 7% decreased their book reading.  This also extended to magazines and newspapers as well. 

Why?  According to the survey, 40% said that e-books are more affordable, and that drives their consumption, while 47% indicated that “more interesting books were being released.”  Considering that the publishing industry hasn’t hit a halcyon boom, it’s more likely that e-books enable readers to more easily find books they would be interested in, through searching, recommendations, etc.    

What’s interesting about this shift is that we’re increasingly in a world where if the medium can be digital, the medium will be digital.  And this requires thinking about the network in ways that a lot of enterprises haven’t thought about the network before. 

It used to be that the network was what enabled computers to talk to each other – it still is, of course – but the language of computers was dull and uninspired; in the beginning, only business apps transmitted through the network, because the business apps were what the network was used for. 

But to most end users today, the network isn’t just for one limited purpose.  It’s not even for a variety of purposes.  The Internet is the tube which gives us information, entertainment, conversation, and sustenance, in the form of productivity.  It is, quite frankly, the most important thing in many people’s lives. 

So the stewards of the network have to consider that they hold an awesome responsibility, and that it might be time to stop thinking of the network as just a business tool, and instead, think about it as the circulatory system of human culture. 

Hold on – I think I just had a hippie moment brought on by high stress levels and lack of sleep.  It’s okay though.  I’m sure you get the idea. 

At the UBS 37^th annual Global Media and Communications Conference, Ralph de la Vega at AT&T mentioned that AT&T’s been having cellular data network problems because of heavy users – touting out the usual “80/20 rule” bandwidth hog rule (in this case, that 3% of users use 40% of the data) the company’s representative, Ralph de la Vega, suggested  to its investors that AT&T would likely introduce a pricing scheme that would penalize heavy data users, according to the LA Times.

We’ve written before about how the “X% of users use Y% of data” is kind of a boondoggle, but that doesn’t mean that congestion problems aren’t real for AT&T.

Which makes me wonder: If your data network couldn’t handle data streaming services for downloading web browsing, video, and applications, why, in fact, did AT&T team with Apple to sell a phone whose selling points were web browsing, video, and applications?

This is compounded with the idea that a lot of the problems have occurred in New York City, where AT&T rolled out the 850 MHz spectrum. The 850MHz spectrum travels further into office buildings and apartment complexes than the previous spectrum – and as a result data usage in the area went up 30%. 

Again – to me this seems like a case of infrastructure not being able to support the sales claims.  So the end result is that AT&T is trying to do the most difficult thing of all – trying to solve the problem by changing end-user behavior.  To their credit, AT&T is, at this moment at least, intending to use incentives to get people to use less bandwidth rather than punishments for heavy users. 

Still I feel a little frustrated.  Business Internet has been around for nearly, what, 15 years now?  How long will it take before people learn you don’t roll out new applications or services without baselining your performance and making sure that you have the infrastructure capable of supporting it. 

In May of this year, Nemertes Research president Johna Till Johnson wrote in Network World that “The Internet Sky Really Is Falling.”

The next day, we came out with a story about that column, in our much more irreverent style, entitled “That’s great, it starts with an earthquake: Is the Internet dying?”

In that article, we questioned the conclusions that they drew from evidence. To sum up, those conclusions were:

• 
  

  Nemertes believed that YouTube restricting high definition video to developing countries was a sign of the Internet outstripping backbone demand. We pointed out that such restrictions were due to local traffic problems and the lack of profitable business models in many developing markets.

  
  
• 
  

  Nemertes also pointed out that many cable carriers were instituting bandwidth caps and pay-per-byte pricing. We pointed out that we did an entire series on why usage caps don’t help with traffic congestion, and that ISPs that roll them out typically do so in generally non-competitive markets where they have other business interests (like cable TV and phone service) that compete with Internet access, and that there were plenty of counter-examples of companies (like Verizon and Cablevision) offering more bandwidth without caps.

  
  
• 
  

  And Nemertes pointed out the IPv4 shortage, for which there was already a solution, IPv6. (Though adoption rates have been slow, it does not mean the Internet will halt – simply that IPv6 changeovers will be more expensive the longer the delay.)

But the one thing we didn’t question was claim by Nemertes claims that Internet traffic will grow “exponentially” while Internet backbone will grow “linearly,” leading Nemertes to the conclusion that there will come a day when there will be Internet “brownouts.”

Recently, Johna Till Johnson published another column – this time in ComputerWorld, outright claiming that net neutrality legislation would mean the end of the Internet. That’s not hyperbole on my part – the headline is literally: “Hello net neutrality, goodbye Internet.”

And Ars Technica, a Conde Nast publication, decided to take another look at Nemertes’ evidence.

Essentially, Nemertes now claims (in the October article) that Internet growth creates a strain on last-mile access lines (Cable/DSL/FiOS) that makes it “excruciatingly expensive to upgrade,” that network neutrality would mean that you can’t charge different rates for different traffic, so backbone providers and carriers would start charging by the bit – or at least capping and charging for overages. Since bandwidth providers would now charge each other for the traffic on their networks, they would either raise subscriber rates dramatically or disconnect from the Internet entirely, literally killing the Internet as the entire thing breaks down into walled tiers like early 1990s Compuserve, AOL, & Prodigy.

Ars Technica, on the other hand, points out that the “excruciatingly expensive to upgrade” last-mile bandwidth isn’t exactly excruciatingly expensive compared to the profits that Internet service providers already generate with net neutrality and in most cases, without caps. Verizon, for example, is paying $18 billion for FiOS upgrades, but that’s the most expensive upgrade in the market, and Verizon finds it financially feasible to do so in a net-neutral market. For most ISPs, DOCSIS 3.0 (for Cable) and FTTN (for DSL) are very cheap solutions to increasing last-mile bandwidth.

As for the idea of the Internet fracturing, Ars Technica pointed out that ISP networks all exchange roughly the same amount of bandwidth; and an even trade is an even trade no matter how much it costs. There are many ways to recoup costs – but raising the rates on a competitor who can then turn around and raise rates on you doesn’t make any sense at all.

Or as Sevcik and Wetzel put it in Network World:

“Backbone ISPs and access ISPs must play nicely with each other to satisfy their customers' needs. Why for heaven's sake would they hurt their customers and themselves by balkanizing?”

What’s most worrying however, is that Ars Technica wrote that Nemertes idea of Internet growth outstripping capacity may be flawed.

According to the University of Minnesota MINTS project, the year-over-year growth of Internet traffic is not “50-100%” as Nemertes claimed in the ComputerWorld article, but “50-60%.” (Technically, “50-60%” is within the range of “50-100%” but it’s like estimating that a man that could be 5to 6 feet tall is “between 5 to 10 ft. tall.”) In Canada, where ISPs have to reveal traffic numbers due to network neutrality research by the Canadian government, they find that growth is slowing, year over year. 53% growth in 2006, but 32% growth in 2008.

We’ve found that when it comes to enterprise networks and IT in general, Nemertes Research is a valuable research organization. But in 2007, Nemertes made a prediction – a reasonable one, given the evidence at the time - about the Internet that did not come to pass. Instead of re-examining that prediction, they continue to insist – on openly contested arguments – that they were indeed right all along, even as, less than 3 months away from the ominous “2010” date, the Internet has managed to keep up with the demand of high-bandwidth YouTube HD files, NetFlix streaming, Skype Video-calling, video game downloads, and other high-throughput applications.

I think that what is actually happening, rather than demand for bandwidth outstripping supply, is that the supply of bandwidth creates its own demand, and that the new demand comes primarily from new applications. That is, HD video on the net is only in demand now that the networks have been shown to be able to handle that kind of capacity. YouTube didn’t start until there was enough capacity on the Internet to make SD video distribution feasible. Only later, when capacity grew, did YouTube roll out high quality video, and still later (after Vimeo proved it was feasible) did YouTube roll out 720p video content. When the network capacity can handle streaming 1080p video, then that will be the new standard. But no one is going to roll out 1080p video until the network can handle it.

This is not to be confused with the issues faced by enterprises when trying to allocate resources to business critical traffic over recreational traffic – where supply of recreational network traffic can be artificially restricted through QoS policies and traffic shaping in order to, presumably, lower the strain that recreational traffic puts on the network. Even so, most smart companies engage in capacity planning, making sure they have the bandwidth available to use new applications before those applications are rolled out. Teleconferencing, for example, is a business application that requires a great deal of bandwidth – but it’s of no use to an organization – and therefore not demanded – if the company network can’t support it. Or in other words, if the money saved from teleconferencing isn’t equal to or greater than the increase in network costs, smart companies are not likely to invest in teleconferencing.

In short, the sky is not falling. But keep an eye on your patch of it, anyway.

Wearing an eyepatch (I’m having a little eye trouble) has given me new appreciation for the importance of visibility.  There’s some good news coming out on that front; as company Ipoque has released an open-source deep packet inspection client.  It’s slower than commercial offerings – more of a tech demo than anything else, but the idea isn’t so much to provide DPI for the masses as it is to show the masses exactly what DPI is, instead of relying on rumor.  Ipoque doesn’t store or examine information being transmitted, for example, a common fear regarding DPI. 

Now, there are products that do packet capture and analysis – we even sell one for the enterprise IT environment.  But it would be chilling, at the very least, to use a product that inspects the content, rather than protocol, of information being transmitted for University or public ISP internet connections.  Still, knowing what protocols are running at any particular time is very useful for even public and university Internet connections.  If World of Warcraft connections and VoIP took a larger share of the network bandwidth than large Web/FTP downloads and YouTube, it’s an easy choice to focus network improvements on solutions that decrease latency rather than those that would increase latency but improve throughput. 

Of course, all the DPI and network monitoring in the world can’t help some networks. 

For example, Telkom, in South Africa, provides ADSL service.  Apparently, it’s not exactly the speediest service in the world, as Unlimited IT decided to transfer 4GB worth of data over 60 miles in one of two ways – via ADSL, or via carrier USB-stick connected to a carrier pigeon. 

The pigeon took two hours – including the time it took to load the data onto the computer from the USB flash memory stick. During that time, the ADSL transmission was about 4% complete.  It wasn’t even close.

Just doing some math here – 4% of 4GB is 163.84MB… that’s 81.92MB/hr, or 1.365MB/min, or 23.3kBps.  Yep, sounds about right.  That’s one of the major problems with ADSL… the “A” part.  That 23.3kBps is around 186kbps – which is actually not that bad compared to the 256kbps upload speed on most ADSL providers.  But the policy of providing download speeds vastly greater than upload speeds was created in an era where people overwhelmingly downloaded information from the Internet, and large uploads were rare, and usually done by large corporations.  Now, we have YouTube, Flickr, anyone in the world can contribute to open source projects, etc.  Might be time to consider changing those policies.

Or someone could make a ton of money providing an upload-only service to compliment the download-focused services of ADSL and cable providers.  Food for thought. 

There’s an article on ZDNet talking about a video where Sun Microsystems CTO Lew Tucker talks about how future cloud computing applications will be able to know exactly how much demand there is for the application, and requisition the appropriate amount of computing power. During high demand, the application could grab more resources, preventing application-based slowdowns, and during low demand, the application could release resources back into the cloud, saving the company money.

Of course, ZDNet’s title for the article is “Future Cloud Apps won’t need humans” which conjures up frightening images.

If it’s any indication, dynamic allocation of the needs of information will cause anxious consternation about the continued necessitation of the IT occupation, and frantic desperation. (Of course, that’s just idle speculation.)

But it might be more accurate to suggest that “Future Cloud Apps won’t need humans to babysit them.” That is – all that Tucker talks about is the idea of taking what used to be a manual process – deciding how much processing power any particular application needs – and having the computer make that determination on the fly based on the actual processing power needs. Certainly, humans will be involved in determining how much power is “too much,” how much slowdown is “acceptable,” and – most importantly – how much performance that the end-users can actually use.

This has two main impacts on the networking side of IT – that is, if an application can dynamically allocate more resources during times of excess need, application performance may be limited on the server or on the network, but it eliminates one of the main causes of application performance problems – not assigning enough resources to the application.

Additionally, application performance becomes important independent of the network, as a poorly coded application might need more resources and therefore require more money to operate.

Secondly, when you essentially remove the limits on application performance by simply allowing it enough resources to do the job at any time of the day, you have to continue to look for other bottlenecks. If you have the capacity to do more with what you’ve got, it makes sense to do everything you can to take advantage of that capacity.

Now, before this possibility becomes a reality, cloud computing standards need to be developed, agreed upon, and used in order to have multiple applications cooperate in any dynamically scaling environment. That may be very soon, or a long way off, but it will probably happen, because there’s just too much money to be missed out on if there isn’t a cloud computing interoperability standard.

I’d like to be skinny. And have a million dollars. G’night folks!

------------

I have just been informed that, even though it is Friday, I still need to put at least some effort into writing an intelligent blog post.  So, here goes.

Here’s my first thought about health and the economy: Obviously, there have been massive layoffs across the board, and IT has not been spared.  Over the past two years, not only have there been layoffs due to the general contractions (or as I refer to them, death-spasms) of the economy, but since 2006, there has been an increase in the number of internationally outsourced jobs by IT service vendors, according to Network World. 

Data prepared by Everest Group Inc., a research and outsourcing consulting firm, shows in broad brush fashion the shift of jobs overseas by some major IT services vendors. In 2006, U.S. and European firms typically had less than 20% of their workforces offshore; Now, for most companies that figure may well be generally over 30%.

At the same time, many laid off workers are starting their own businesses.  Certainly not all of them, but when you need a job, and no one is hiring – entrepreneurship and despair seem the only logical choices. 

A quarterly survey of 3,000 job seekers conducted by Chicago-based outplacement firm of Challenger, Gray & Christmas, Inc., released Thursday, shows a near doubling in the year-to-year growth of job seekers turning to self-employment.

The problem with this is that because more people are becoming unemployed or self-employed, it creates additional political pressure on the health care debate.  The unemployed and self-employed have to rely on the private insurance market for healthcare, which is where the majority of healthcare horror stories exist, according to NYT opinion columnist and Nobel Laureate Paul Krugman. Krugman argues that government regulations require that employer contributions to health care “can’t discriminate based on pre-existing medical conditions or restrict benefits to highly paid employees,” and thus people don’t see the worst parts of private insurance until they’re either unemployed or self-employed.

Which brings me to my second thought on health and the economy: The “American Recovery and Reinvestment Act” (a.k.a. “the Stimulus”) which give $19B for healthcare related information technology, but also requires that each American has an electronic health record in 5 years.  TechTarget argues that meeting that deadline simply isn’t that easy. 

"The concern is that when you have these programs that are time limited … that the quality of those implementations could go down," said Chad Eckes, the chief information officer for Schaumburg, Ill.-based Cancer Treatment Centers of America (CTCA). "There can be spectacular failures of electronic health records, because folks didn't anticipate what might happen if it was unstable, and that can have disastrous consequences for patient care."

We’ve seen some of the difficulties with medical data networks before – with the importance of maintaining network performance when lives are literally on the line. 

There’s no question that electronic data records are faster than paper records, and (usually) more accurate… or at least, more accessible in a crisis, which is why there is a mandate.  The problem arises when there is poor network performance, in which case records are less accessible.  Moving the patient records from paper to data places the onus of providing that information from the administrative staff of a hospital or medical center to the IT department.

By Brian Boyko
Editor, Network Performance Daily

I’ve been getting better and better with video as I’ve worked here – and I noticed that many people don’t really understand the nature of digital video files – what makes one file big, what makes one small, what makes one 20 MB file look good, while another 20 MB file looks lousy. 

Considering that Cisco is claiming that video will take up 90% of all traffic by 2013, it might be important go over some of the ideas about what makes up digital video files at the low level so that you can understand how they impact your network. 

If you already know this, I apologize. 

Digital video files are, essentially, pictures.  Multiple pictures played in sequence, with an audio track.  And like digital pictures, they can be compressed.  Uncompressed video is like a photo in BMP format – perfectly accurate, but huge.  Compressed video is like a JPG file – it creates artifacts, but is much smaller. 

There are many compression schemes, with advantages and disadvantages, based on different ways to compress the file.  Some are more effective at reproducing more accurate information with smaller filesizes, but ultimately, from a networking perspective, it’s really not important which you’re using.  What is important is the resolution, framerate, and bitrate. 

The resolution is the size of the video in terms of how many pixels you can see on screen.  It’s usually in varying rectangle sizes, but it’s usually expressed as the size of the rectangle (i.e., 640x480) rather than the absolute number of pixels.   High definition television comes in two types: 1920x1080 (a.k.a. “1080”) and 1280x720 (a.k.a. “720”), and “720” is the format used for YouTube high definition video.  Standard definition television comes as either 720x480 (NTSC) or 720x576 (PAL).  

The framerate is the number of frames – or pictures – that are shown each second.  In a filmed Hollywood movie, it’s typically 24 frames per second (or 24p).  On television, and with most recording equipment, they usually show 30 frames per second in the U.S. and 25 frames per second elsewhere in the world – though, in order to get faster motion, they often stagger every other line of resolution and place them between every other frame – so when you watch 30 frames per second of TV, you’re really watching 60 “half-frames” per second - also known as 60 interlaced frames  (or “60i”).

Finally, the bitrate is the number of bits of information that are in the file for each second of video.  A file with a bitrate of 512kbps has exactly 512 kilobits per second in order to convey all the information it can about the video.  With more bits, you can contain more information. 

Ultimately, the only thing impacting the network is the bitrate.  Bitrate determines filesize for downloadable video, and bitrate determines bandwidth requirements for streaming video.   A 3Mbps SD video will be the same filesize as a 3Mbps HD video, for example, provided that they are the same length. 

The quality of the video, however, is impacted by resolution and framerate as well as bitrate.  

In one second of 640x480 video at 30 frames a second, and 24 bits per pixel, you have 210 megabits worth of information.  Representing that, with, say 3 megabits is a daunting task.  On the other hand, if you increase the framerate to high definition – 1280x720 – you get 632 megabits of data per second – and representing that with only 3 megabits is an even more daunting task. 

The higher the bitrate, the higher the quality of the video; but the higher the resolution and framerate, the more you have to increase the bitrate in order to get the same level of quality.  High definition files tend to be larger than standard definition files because they’re usually – but not always – rendered at a higher bitrate. 

This was one of the reasons that when NBC was covering the Olympics, they often sent the raw footage from Beijing in low-resolution, low-bitrate formats, and only sent high-resolution files to their editors in the U.S. when they knew exactly which shots they wanted to include in their broadcasts.

By way of metaphor, think of bitrate as a fixed amount of butter that you have to butter bread.  You could spread out a single pat of butter on a whole loaf of bread, but it wouldn’t taste very buttery.  Or you could just butter one slice with that pat, but the bread wouldn’t be very filling.

Where different compression schemes come in is that they’re ways to use the limited amount of bits in each second of video to represent all the information – some compression schemes simply look better than others.  Right now, the leader seems to be H.264, which is about twice as efficient as the file system used to store information on a DVD (MPEG-2.)  A 3Mbps H.264 file and 3Mbps MPEG-2 file will have the same filesize, but the H.264 file will simply look better. 

Bitrate is also important because for streaming video, the bitrate of the video is equal to the amount of bandwidth required in order to show a video without pre-buffering or jitter – especially important for live applications like teleconferencing.  Lowering the bitrate decreases the quality, but image fidelity is often less important than immediate response time in teleconferencing applications.  (There are other issues that can cause jitter even with sufficient bandwidth, so it pays to monitor your communications network.)

At any rate, I hope you find this information useful when dealing with bandwidth.  At least now, when someone complains about how long it takes to download a video file, instead of spending tons of time and energy on network upgrades, you might want to ask if you can get a lower bitrate file instead. 

One of the things holding back the rollout of new applications (like VoIP, Video, and Unified Communications) is the fear that the new applications will cause network performance problems; according to Network World’s Denise Dubie, citing a survey from Apparent Networks.

Nearly 61% said that they had delayed a VoIP implementation due to network performance concerns. Some 35% postponed a video rollout for the same reasons and 26% put a unified communications project on hold. The survey also showed that network managers can’t always validate their service-level agreements (SLA) with external service providers. More than one-quarter of respondents don’t have the capability to validate SLAs.

It would be instructive to know if decision makers are “concerned” that new apps will reduce their performance because they have baselined performance and know that the network cannot handle new application rollouts… or if they’re concerned because they have no idea whether the network can handle it or not.

It’s the difference between being stopped by practicality and being paralyzed by fear.

And if you’re being paralyzed by fear, it’s costing you money.

For example, Cisco decided to “eat it’s own dogfood” and estimated that they saved $277M from bringing in their own virtual office telecommuting technology – a new application (based on their “Cisco Virtual Office”) for the network that leads to cost savings. If Cisco didn’t know that their network was capable of supporting the CVO application, they would have been out $277M.

Of course, the reason you don’t roll out an application that might save you millions when you don’t know whether those applications will negatively affect network performance is that poor network performance can cost more than whatever you’d save by the rollout.

You can know, or you can be paralyzed by fear of the unknown. I know which I’d rather be.

Well, coming from the land of the ice and snow, from the midnight sun where the hot springs blow, the Norwegian based Opera Software is following in the footsteps of the Vikings.  Opera Unite is a technical achievement and if it – or a worthy imitator - is widely adopted, will be a game changer.  The Vikings were the game changers of their day, engineering the best seafaring technology of the time.  They also pillaged and burned a whole mess of Europe, which many people may find reprehensible, but, hey, the Vikings were the best at what they did. 

At its core, Opera Unite is nothing more than a webserver – we’ve had these things for years, of course.  What makes it different is the ease at which it can be set up – download the browser, create an Opera.com account, and you’re done.  By routing through Opera’s servers, you don’t need to mess with VPN, Remote Desktop, IP addresses, or configuring those fiddly little port forwarding settings on your home router – you don’t even need to have access to it – or even to know what a router is – to use Opera Unite.

Right now, the immediate use is to run it on the home computer to access files from work, and vice-versa.  And that’s where the snag comes in.  Opera Unite cannot be considered in any way “secure” – the fact that it connects to a third-party server makes it ripe for a man-in-the-middle attack, people might mistakenly share sensitive information on their work or home computers, and of course, there’s the problems that you’d expect to have with any filesharing app on the PC.

But more importantly, this will have a major impact on performance.  Employees running data servers can choke the network links your company pays for; we have already seen this when highly technical users run FTP or Web servers from their office desktop machines.  Opera Unite doesn’t change the nature of FTP servers – it just places creation and access of FTP servers and hosting services in the hands of the many, rather than the few. 

Even so, I can’t help but think that overall, Opera Unite is a good thing overall.  It reduces dependence on third-party hosting sites and cloud apps – like YouTube.  If there’s a video that YouTube doesn’t like – or has to take down because of a mistaken or fraudulent copyright claim, the video can still be made available.  (Often times, copyright law is abused to get hosting services to remove unflattering footage of a company or organization.)  And if a particular hosting service should die, the data can still be accessed.  In this manner, it removes some of the risk from cloud computing by allowing anyone to run their own hosting services. 

It doesn’t hurt Opera that they’ve found a hail-mary pass for desktop software to remain relevant in the age of the “software as utility” philosophy of cloud computing… by essentially providing a desktop app that turns your desktop into a cloud computing platform. 

Additionally, although I don’t hold out much hope for it, it may increase demand for more uploading capacity for home users.  AT&T DSL, for example, maxes out at 768kbps upload speed – over three hours to upload a single gigabyte of information. There’s been little complaint about this because most people care more about download speeds than upload speeds – with their own hosting services however, people might be more likely to notice, and care, about what speed they can access their home computer from work, or their friends or colleagues can access their files.  That may lead to increased upload capacity provisioning. 

Ultimately, I’m psyched about Opera Unite as a desktop user, but in the trenches of IT, I’d want to make sure I had a way to track this traffic and see if it affects network performance in a meaningful way.  It may be nothing but a flash in the pan, but if it does catch on, I’d rather err on the side of caution.