[THIN] Re: A definitive registry information source?
- From: "Steve Greenberg" <steveg@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 9 May 2008 10:06:19 -0700
Rick,
We have come to same exact conclusions in our practice. It can be summarized
by saying that traditional SBC has all the benefits of shared computing -
Efficiency and Centralization. VDI has the traditional benefits of the PC -
Compatibility and Personalization/Familiarity. Like you, we have
accomplished a very high level of application integration success with SBC
in our client base and all the benefits have been demonstrable. We have also
found though that the skill set and approach is different and this can lead
to situations where the maintenance and upgrade of the environment becomes
too complicated for the staff IT people.
So you have a spectrum from TS to VDI:
Efficiency of HW/SW with Skills Complexity <------->
Compatibility/Familiarity, ease with inefficient SW/HW
To me the main question right now is what is the scale of the inefficiency
on the VDI? Is it just a few extra servers for most environments or even a
doubling or tripling of hardware and server footprints? Licensing costs
overall? Maintaining a client machines as well as a VDI machine? Will the
users really accept their entire environment running over a remote protocol
versus processing on a local OS and video card? (this is something that most
end users pick up on right away)
Otherwise I do believe the time is right for VDI (which needs a better name
by the way) but how much of the workforce will it really apply to? I think,
like SBC, VDI will show great promise but end up being just another option
in the spectrum, although a valuable one, for some percentage of the user
base that can directly benefit from it.
The good news, as Rick alluded to, is that VDI instances still need to
print, they still need a Windows profile, they still apps to install and
run correctly, they still need to be accessed remotely and secured so I
don't think us SBC dinosaurs will go extinct just yet...
Steve Greenberg
Thin Client Computing
34522 N. Scottsdale Rd D8453
Scottsdale, AZ 85266
(602) 432-8649
www.thinclient.net
steveg@xxxxxxxxxxxxxx
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Rick Mack
Sent: Friday, May 09, 2008 12:11 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: A definitive registry information source?
Hi Jim,
I used to be a terminal server (TS) bigot too because I could get almost any
application going on TS. I'd spend days and nights finding out how
applications worked, and how to modify the application or environment to
make it happy. But not everyone has the skill, experience, time, tenacity or
stupidity to do that. I did it because it was fun and I've learned an
incredible amount of stuff. Other people are sensible and have a real life
:-)
Things are a lot easier than they used to be. Application verifiers, the
Microsoft Standard user analyser, the new TS application compatibility
analyzer and application isolation and streaming have made the whole process
of porting applications to TS a lot easier.
But it's still not as easy as installing an application on a Windows XP
desktop and unfortunately the major skill set in a lot of organizations
resides in the desktop management team.
You know them, they're the people who reboot a TS server with 50 users
logged on because the spooler has stopped. They often just can't or won't
come to grips with TS and actively hate it. They're the ones that have made
Citrix a dirty word in a lot of organizations.
Anyway, lets get down to the real stuff.
Server based computing (SBC) is about delivering a remote GUI to users while
running the users' "virtual" desktops or applications in the data center.
Remote doesn't necessarity mean far away, just that the desktop or
applications aren't running on the device in front of the end user.
SBC coupled with thin clients is widely acknowledged as a brilliant way to
keep desktop management costs in check, and to get away from the 2-3 yearly
desktop refresh cycle.
So if that's such a good idea, why do so many people hate TS?
Because it's different, and it's often just too hard.
It needs different skill sets, more experience and a much better
understanding of how everything hangs together. The people who do TS well
are the IT equivalent of rocket scientists.
SBC used to be solely about TS, but not any more. We've now got all sorts of
ways to give users remote access to their virtual desktops and applications.
We have user session isolation (TS), operating system partitioning
(Virtuozzo), virtual machines (VMware, Virtual Iron, Xen, Hyper-V etc) and
even blade PCs (DDI) that weakly qualify under the SBC blanket because
they're racked machines running in a data center. That's ignoring stuff like
VWware ACE and Moka5 where the difference between "real" and virtual user
sessions is just too vague.
So we've got a lot of different alternatives for delivering virtual
desktops, but which one is THE best way to do things?
Let's look at our SBC options.
At one extreme, if you've got a lot (200+) of interesting
(challenging/frustrating etc) applications, then the implemetation costs you
incur to get all those applications going on TS can be horrendous. And then
along comes something like Cisco Presence that won't run multi-user at all.
Oh, and the corporate application tha the CEO loves that is having problems
and isn't supported on TS.
So what do we do? Go back to fat clients for some of the users?
At the other extreme DDI is brilliant from the viewpoint that you can run
anything on a blade PC, even stuff like AutoCAD with 3D rendering etc. Any
super-heavy resource hungry application can be accomodated and we're still
using a thin client in front of the user. But the cost of having a thin
client AND a blade PC for every user is pretty horrendous.
Then there's VDI which is kind of a compromise. The number of user virtual
machines you can support on a given host is a lot less than TS but VDI on
virtual machines hosted on VMware etc will run almost any application that
will run on a desktop. No file sharing and locking issues, no problems with
privileges, no support issues. If you're crazy enough (which I hope no-one
is) you can even let your users be local administrators.
If I use Virtuozzo for VDI as an "intermediate" VDI solution, it's not quite
as "good" as a windows XP virtual machine. We're still running on Windows
Server 2003, but the user session isolation is heaps better than TS and the
number of users I can host on a server is nearly as good as TS. That's "VDI"
at almost the same hardware cost as TS.
So we've got a lot of alternatives that are right for different reasons.
Whever we quoted to do a fat client to terminal server migration project, we
used to go nuts trying to estimate how long it would take to port all a
customer's applications to TS, and worry like heck that we didn't cover
everything, and that some of them wouldn't port at all. With VDI/DDI as a
backstop, and particularly if you can publish seamless applications via VDI
(did I mention Provision :-)), I can run the bulk of my applications and
desktops on TS, and silo the applications that don't run or aren't supported
on TS on my VDI machines. Or if users have to run a huge java application
that uses several gigabytes of RAM, I can throw in a few blade PCs.
In an ideal world we would use each technology as is most appropriate to end
up with the best possible mix. Use TS for easy apps and lowest cost, VDI
for the apps that need a single-user desktop environment, and DDI for the
stuff that doesn't belong on a server. Imagine an SBC/thin client
environment where everything works, where it's easy to put everything
together and it's the most cost effective solution you can offer.
Then there's the real world.
Getting applications to run acceptably on TS can be a huge job with huge
risks whereas doing the same thing on virtual machines is dead easy with
minimal risk. Whether we like it or not there have been enough well
publicised failed TS implementations that the perceived risk is unacceptable
for many organisations.
What a decision for a CTO, a defined high hardware cost with very tight
implementation costs at a minimal risk, or a lower hardware cost with
undefined, possibly huge implementation costs and an equally huge risk. P2V
a standard SOE machine and you're nearly there with VDI, ingnoring all the
stuff you should do to get decent scalability.
And we can't forget the basic fact that for people who are used to managing
desktops, VDI doesn't require much of a change of mindset whereas TS does.
People can cope with the idea of virtual machines because you can manage
them the same way you always have, and aside from the VMware etc
infrastructure, nothing has to change very much.
It's this scenario that means people will often opt for VDI instead of TS
when they have a requirement for remote access, simplicity and the cost
saving associated with thin clients.
But it's not all bad news. VDI is still SBC, and where are the SBC experts,
the people that know about thin clients, profile management, lockdown,
tuning etc, all that stuff that makes VDI even more viable?
That's us.
We've only just begun to make a difference.
regards,
Rick
--
Ulrich Mack
Quest Software
Provision Networks Division
regards,
Rick
On 5/6/08, Jim Kenzig < <mailto:jkenzig@xxxxxxxxx> jkenzig@xxxxxxxxx> wrote:
Yes but if I did VDI I would need about 75 servers versus the 8 I currently
use with TS, not to mention the additional VECD licenses and Vista licenses
that must be purchased on the workstations.
At 15k a piece for the servers then that is another 850,000 addittional. It
doesn't add up. I'd just as soon as buy them all laptops, ; )
Jim
On Mon, May 5, 2008 at 4:55 PM, Joe Shonk < <mailto:joe.shonk@xxxxxxxxx>
joe.shonk@xxxxxxxxx> wrote:
Think of it this way Jim. 1000 users x 450 for a Presentation Server
Enterprise License will cost $450,000 dollars.
Joedee
Other related posts:
