X
Home & Office

Remote access and virtualization: Not one and the same

Some of you may have seen me tweeting recently about a little experiment that I have going on where I'm using a small PC (perhaps we can call it a netbook, but that's a semantics issue) — the Nokia Booklet 3G — as my primary computing device outside of the office. I am using the device with remote access from LogMeIn to replicate the screen of my work laptop which sits running, locked to my desk at Forrester.
Written by Chris Silva, Contributor

Some of you may have seen me tweeting recently about a little experiment that I have going on where I'm using a small PC (perhaps we can call it a netbook, but that's a semantics issue) — the Nokia Booklet 3G — as my primary computing device outside of the office. I am using the device with remote access from LogMeIn to replicate the screen of my work laptop which sits running, locked to my desk at Forrester. My research in the area of remote access spawned the idea, my Everest-ascent-team-like desire to lower the total weight of my travel gear (and the Nokia, at just 44 ounces, works nicely to that end) pushed it forward.

Personally, I'm looking to explore what limitations the arrangement brings forth in my day-to-day usage. To date, a couple of issues have arisen - the slow refresh which made editing an MS PowerPoint document particularly painful being one — but it's fair to say that I have a relatively complete facsimile of my work computing environment from this, or any, device with a browser. But is what I am doing "virtualization"? Perhaps, in a broad definition, but it's not basic remote access.

It's been a long standing question among our clients and among vendors looking to serve the needs of remote workers, 'what is the best way to give secure access to the largest number of IT's consitutents?' and the answer takes many forms, one of which is virtualization, but it's not the only answer. 

What I'm currently experimenting with is an experience that can be duplicated by other third party tools or a mix of VPN and Microsoft native technology such as RDS, as well as by streaming application and desktop services. All of these options rely, however, on some other software or hardware implementation — my experiment included — either the presence of third party software, a distant, constantly running PC (not very green, I know) or the presence of resources dedicated to back-end systems in the streaming examples. To me, all of these are examples of one, potential definition of virtualization
"The replication in full or in part of a computing environment on a separate device." 

While these implementations serve my needs to get me access to my desktop, they are far more complex and require many more moving parts than a basic remote access implementation. To me, remote access itself is fundamentally a service, and it can be defined (and differentiated) as follows:

"The ability to connect to information and services remotely."

Make sense? Think Outlook web access via VPN. Remote access serves a much simpler role than virtualization, and is much faster to implement, not to mention cheaper for IT. Perhaps most importantly, when in a hurry (almost always the case when provisioning access in preparation for a pandemic event such as H1N1 outbreaks) remote access services are likely to be the cheaper, faster alternative to virtualization. 

It is possible, no, likely, that the two technologies will converge and remote access will be served by virtualization implementations in the future; yes, you've heard this from me before*. However, IT should be careful to look at the two technologies as separate projects and not paint with the broad brush seen in this exchange

I'd like to hear from you, IT readers, what's your company's approach to providing access to critical services: are you relying on SSL VPN, moving to virtualization, or still trying to figure it out? Comment here or respond via @802dotchris on Twitter.

Editorial standards