A talk about the future of Citrix and the Server-Based Computing Industry

This was an excellent talk, which opened my eyes a bit on the whole AAC/CAG/PS connection.  I drank 3 beers during this talk, so it's not something you'll listen to in 5 minutes.
 
 

Great talk. Citrix's 'Access Suite' strategy is a pretty easy sell (except for Password Manager perhaps)
 
I hate to nitpick but there is a big difference between IPSec and SSL VPNs. Yes they achieve the same thing, but with an SSL VPN you can't route like you would with IPSec. With the Access Gateway, the Secure Access Client (SAC) is essentially a WinSock redirector. In this way there are no routes from the client to the internal network, and policies are applied to allow specific traffic from the client to the corp. network. However, the downside is that the SAC is Windows only.
 
On another note, now that the CCEA requires passing exams for the complete suite, perhaps a v4.0 CCEA may mean a bit more than previous versions.
 
And a last one, the ActiveX control is a wrapper around a local installation of Office (which does work very well), it's not a 'web' version of Word or Excel.

Why does Citrix continue to expand their product, because there is no future for SBC.  As most enterprises
look to consolidate servers, Citrix goes against the grain.  Pay attention to Citrix earnings two things jump out
Presentation server growth is relatively flat while SA grows.  As Brian mentioned, with the new functionality of Longhorn, what small to mid-size company can justify the $400 dollar a seat cost for PS.  The old adage will happen again, as always with MS, it isn't the best but it is good enough.  I appluad Citrix for expanding, but in the new areas of focus they aren't the 800 pound gorilla and compettion will be tough.  Most not all Citrix partners focus on the under 5000 seat customer, and as PS sales slow down will they push the new technologies, time will tell

Thanks Brian, this is a superb talk with some particularly interesting insights on how Citrix are positioning themselves with Longhorn on its way. 

I think CAG + AAC is great, but I'm not sure Citrix's pricing strategy for CAG is right, i.e. 150ish per seat, even after accounting for the added functionality of the CAG+AAC.  Its just not enough to justify the additional expense per connection to a farm.  When CSG was released, it generated huge revenues for their core product, much the same as any loss-leader does. It also further diffentiated themselves from MS Terminal Services and gave us another reason for choosing Citrix over MS Terminal Services.

I wonder if Citrix will ultimately offer ICA traffic via the CAG+AAC for "free" to stave off threats from Longhorn.

ORIGINAL: Guest

Why does Citrix continue to expand their product, because there is no future for SBC.  As most enterprises
look to consolidate servers, Citrix goes against the grain.  Pay attention to Citrix earnings two things jump out
Presentation server growth is relatively flat while SA grows.  As Brian mentioned, with the new functionality of Longhorn, what small to mid-size company can justify the $400 dollar a seat cost for PS.  The old adage will happen again, as always with MS, it isn't the best but it is good enough.  I appluad Citrix for expanding, but in the new areas of focus they aren't the 800 pound gorilla and compettion will be tough.  Most not all Citrix partners focus on the under 5000 seat customer, and as PS sales slow down will they push the new technologies, time will tell

How does Citrix go against the grain with server consolidation?  When 64-bit servers become the norm you'll see farms consolidate immensely.  I agree with your pricing that Citrix is pricing themselves out of their own market but not for the reasons you specify.

ORIGINAL: Jeff Pitsch

How does Citrix go against the grain with server consolidation?  When 64-bit servers become the norm you'll see farms consolidate immensely. 


Yes, but why would you *want* to consolidate WTS servers (and users) into a small number of big iron boxes? Consolidation is of course a major trend in the industry, but I would advise some caution here before putting all your eggs into a small number number of baskets - that is, unless CPU and RAM becomes so plentiful that virtualization on all layers become feasible (turning your 64bit monster into a truly big iron host style system which simply does not care when an application - or an OS instance - crashes on you).

This may be around the corner marketing-wise, but is not here yet. For what I have seen today, I would state the 64bit truly is the future - but in the future. For now, I would not join the consolidation bandwagon (yet) - especially since technologies like blade servers help us to control hosting costs (provided you have a data centre that can bear them).

My €.02 only, of course...

Big Iron?  Haven't you been paying attention to how many cores you can get on a system?  Right now you can get 1U/3U boxes with 4 cores and large amount of memory.  64-bit is much closer than what you give it credit for and for companies with hundreds/thousands of servers, moving to 64-bit will be a huge boon to them.

ORIGINAL: Jeff Pitsch

Big Iron?  Haven't you been paying attention to how many cores you can get on a system?  Right now you can get 1U/3U boxes with 4 cores and large amount of memory.  64-bit is much closer than what you give it credit for and for companies with hundreds/thousands of servers, moving to 64-bit will be a huge boon to them.

 
If you are not able to consolidate your hardware substantially, that is, into a very small number of boxes big-iron style (as, say, in the IBM commercial with the emptied datacentre), I see no real benefit in reducing the number of servers even by a factor of 10 or so - the eggs and basket argument here. Scale out, not up. Of course, with really, *really* big 64bit hardware and with plentiful CPU and RAM, you could benefit from the virtualization technology both OS- and application-wise, which seems to be in everybodies strategy books nowadays. But as I said, that's the future. Will happen, but not yet. YMMV, of course.

So your saying you'd rather have 1000 servers rather than 500?  100 rather than 50?  You'd rather have the cost of supporting more servers than less?  You'd rather not take advantage of the hardware you have?  I can't disagree with you more.  64-bit computing is here now and there are companies taking advantage of it, I'm guessing more than your obviouslythinking.  It's hardly putting all your eggs in one basket at all.  What difference does it make for redundancy if you have 50 serves or 100 or even 3 servers vs 2?  If the redundancy is there, who cares?  you are now able to scale out and up at the same time and still have the same levels of redundancy but you are now able to take full advantage fo the hardware you have today.
 
You are, again, mistaken in thinking that you need really, really big 64-bit hardware for any of this.  Take a look at the boxes you've bought over the last few years and they are already 64-bit and able to handle big amounts of memory.  I don't consider 1U/3U boxes big iron at all and the costs of those are pretty cheap.
 
Why move to virtual at all with terminal services if you can take full advantage of the hardware?  You can't take full advantage of the hardware with virtualization today. 

ORIGINAL: Jeff Pitsch
So your saying you'd rather have 1000 servers rather than 500?  100 rather than 50?


I would not argue this reasoning as dogmatically as you are now doing it, but in quite a lot of cases it is much more desirable to have 30 users on a server than 90.

From an operative/sysadmin perspective, it is no big deal for me if I have to deal with 1.000 instead of 500 servers. Financials are a different perspective - data centre costs are, of course, an issue, as is hardware maintenance etc. This (and other things not mentioned here at all) has to be weighened against possible other risks/factors, such as:


What difference does it make for redundancy if you have 50 serves or 100 or even 3 servers vs 2? 


If you happen to loose 100 sessions (or perhaps even hundreds of sessions) instead of 30, the impact may be quite dramatic to one's business...


If the redundancy is there, who cares? 


... as the lacedaemonians would answer this one: If. :-)



you are now able to scale out and up at the same time and still have the same levels of redundancy but you are now able to take full advantage fo the hardware you have today.


My understanding is, that in the WTS realm at least, we typically to do not have enough RAM today to really utilize the advantages that 64bit provides. 64bit applications are also not here yet, especially in environments with a massive portfolio of old 32bit "maintain"-state apps...


Why move to virtual at all with terminal services if you can take full advantage of the hardware?  You can't take full advantage of the hardware with virtualization today. 


My argument precisely. With more CPU and RAM you will *later* be able to virtualize both OS and the applications within the virtualized OS to make your environment more resilient against the typical outage scenarios on the software side of the show.

On such boxes, you can then consolidate your users massively. Therefore my dictum: 64bit is the future - in the future.

As with all dictums, this is indeed a simplification, and perhaps even polemic, and definitely does not fit all sizes. YMMV. OTOH, "consolidation" is a buzzword, too, and it is always useful to challenge such "trends" before following them overeagerly. This is what I am trying to do here.

Well I know from my clients that have 100's of serves they would rather see less servers (and associated costs) rather than more and they are actively looking at consolidating today with 64-bit rather than the future.  The cost savings by moving sooner rather than later is very appealing.  the one thing your not looking at is, again, the amount of money that can be saved by being able to put more users on a system.  I was dealt this by a person I was speaking with and it makes sense.  If they could put 5 more users on 1000 systems, that's a HUGE benefit to them.  That's 5000 more users on the same system without having to purchase more systems to accomodate them.

I don't understand your virtualization reasoning.  Your saying it's better to consolidate many servers down to one and have it virtualized?  Why?  Why is that better than not virtualizing and using the full hardware?  Wouldn't you be losing the same amount of users if the servers went down?  I'm talking crashes not vmotion or anything like that.

Oh and you can run 32-bit apps on a 64-bit server.  As for memory, you don't consider 32gb or 1TB enough memory?  this is what windows can support right now, not in the future.  Or are you arguing the cost of the memory?


by the way, before someone tries to call me out for anything, I LOVE these types of discussions and I wish we could have more of them without people blowing gaskets and start insulting people.  So Oliver THANK YOU for being able to have a discussion and differing opinions and keeping it civil.

0Good Morning!

ORIGINAL: Jeff Pitsch

... If they could put 5 more users on 1000 systems, that's a HUGE benefit to them.  That's 5000 more users on the same system without having to purchase more systems to accomodate them.

If they *already* *can* fit more users on a server, and they are happy to go along with the - in this case slightly - increased impact of a failure, then indeed why should they not? But this is not my understanding of consolidation. I understand consolidation to mean investing in a new technology like 64bit (that is, spending money on something with the prospect of generating some RoI). Not utilizing something you already have.

I don't understand your virtualization reasoning.  Your saying it's better to consolidate many servers down to one and have it virtualized?  Why?  Why is that better than not virtualizing and using the full hardware?  Wouldn't you be losing the same amount of users if the servers went down?  I'm talking crashes not vmotion or anything like that.

You want to minimize the impact of application crashes (software virtualization), and you want to minimize the impact of OS freezes (server virtualization). In practice, it means breaking down the big-iron thing (to use the phrase again - I do this explicitely because I'd like to stress the host analogy here) down to servers hosting a smaller number of users. How far you can take and want to take this approach depends of course on the hardware available, and your budget :-)  The most extremist approach would be the virtual desktop.

On the hardware-side, I would assume that such chunks of big iron hosting perhaps thousands of users will be built very *very* redundant, in any case much more redundant then you can afford to rig in a 1U or 3U server.

Oh and you can run 32-bit apps on a 64-bit server.

But thunking comes with a price tag attached to it. The price may be hefty. With todays RAM pricing, it may not even be worth the effort. This *will* change definitively, of course.

by the way, before someone tries to call me out for anything, I LOVE these types of discussions and I wish we could have more of them without people blowing gaskets and start insulting people.  So Oliver THANK YOU for being able to have a discussion and differing opinions and keeping it civil.

Let me return the compliment. On a lighter note, I'd like to share some wisdom of Dogbert here: "To appear as a visionary planner, centralize everything which is decentralized, and decentralize everything which is centralized!" 

You're kidding me right?

If this is your attitude, then you should not be looking at SBC as a solution for your company... Just give all you end users a desktop and be done with it.

For a company to have 500 servers vs 1000 is a HUGE.    There is no economy of scale for SBC.  A 1000 server system is going to cost twice as much (if not more) than a system of 500 servers.  If anything scaling out will reach a point of diminishing return.

Joe


ORIGINAL: Oliver Weber

ORIGINAL: Jeff Pitsch
So your saying you'd rather have 1000 servers rather than 500?  100 rather than 50?


I would not argue this reasoning as dogmatically as you are now doing it, but in quite a lot of cases it is much more desirable to have 30 users on a server than 90.

From an operative/sysadmin perspective, it is no big deal for me if I have to deal with 1.000 instead of 500 servers. Financials are a different perspective - data centre costs are, of course, an issue, as is hardware maintenance etc. This (and other things not mentioned here at all) has to be weighened against possible other risks/factors, such as:


What difference does it make for redundancy if you have 50 serves or 100 or even 3 servers vs 2? 


If you happen to loose 100 sessions (or perhaps even hundreds of sessions) instead of 30, the impact may be quite dramatic to one's business...


If the redundancy is there, who cares? 


... as the lacedaemonians would answer this one: If. :-)



you are now able to scale out and up at the same time and still have the same levels of redundancy but you are now able to take full advantage fo the hardware you have today.


My understanding is, that in the WTS realm at least, we typically to do not have enough RAM today to really utilize the advantages that 64bit provides. 64bit applications are also not here yet, especially in environments with a massive portfolio of old 32bit "maintain"-state apps...


Why move to virtual at all with terminal services if you can take full advantage of the hardware?  You can't take full advantage of the hardware with virtualization today. 


My argument precisely. With more CPU and RAM you will *later* be able to virtualize both OS and the applications within the virtualized OS to make your environment more resilient against the typical outage scenarios on the software side of the show.

On such boxes, you can then consolidate your users massively. Therefore my dictum: 64bit is the future - in the future.

As with all dictums, this is indeed a simplification, and perhaps even polemic, and definitely does not fit all sizes. YMMV. OTOH, "consolidation" is a buzzword, too, and it is always useful to challenge such "trends" before following them overeagerly. This is what I am trying to do here.

ORIGINAL: Guest
If this is your attitude, then you should not be looking at SBC as a solution for your company... Just give all you end users a desktop and be done with it.

Regarding your jibe regarding SBC vs. desktop PCs, you are totally beside the point here. The issue is not how many users you are putting on a system. The issue is centralization. I'm not totally sure about the virtual desktop concept myself, but I do understand that SBC is a mean, not an end.

SBC has been around since the beginning so I don't think it's going to go away anytime soon.

Even given Citrix "high" cost per set for PS, the ROI is there to justify SBC over a Client/Server architecture.   Longhorn, if anything, will help Critrix.  Microsoft is not stupid,  the know that Citrix brings in over 300 million dollars in revenue to Microsoft without having to lift a finger.  I've heard the same song and dance before.   TSE 4.0 was suppose to kill Citrix.  Windows 2000 TS was suppose to kill Citrix.  Windows 2003 was suppose to kill Citrix.  Somehow Longhorn is suppose to kill Citrix.

Joe



ORIGINAL: Oliver Weber

ORIGINAL: Guest
If this is your attitude, then you should not be looking at SBC as a solution for your company... Just give all you end users a desktop and be done with it.

Regarding your jibe regarding SBC vs. desktop PCs, you are totally beside the point here. The issue is not how many users you are putting on a system. The issue is centralization. I'm not totally sure about the virtual desktop concept myself, but I do understand that SBC is a mean, not an end.

ORIGINAL: Joe Shonk

SBC has been around since the beginning so I don't think it's going to go away anytime soon.

Even given Citrix "high" cost per set for PS, the ROI is there to justify SBC over a Client/Server architecture.   Longhorn, if anything, will help Critrix.  Microsoft is not stupid,  the know that Citrix brings in over 300 million dollars in revenue to Microsoft without having to lift a finger.  I've heard the same song and dance before.   TSE 4.0 was suppose to kill Citrix.  Windows 2000 TS was suppose to kill Citrix.  Windows 2003 was suppose to kill Citrix.  Somehow Longhorn is suppose to kill Citrix.


... this discussion is taking an unexpected twist here. Never said a thing about the future of Citrix.

Perhaps I should express myself clearer. I am all in for SBC. I simply do not believe that consolidation to 64bit is - at the present time - necessary or even useful in quite a lot of cases. I do believe that consolidation to 64bit will be a major thing in the near future, when boxes grow big enough to add additional layers of redundancy and fault tolerance both on the hard- and software layer.

At the present time, it is not yet economical to do so with the existing boxes - because the hardware is not yet up to the challenge of full virtualiztion, and you can't reduce server count sufficiently to justify the additional hardware costs of higher redundancy ("host"-style) beyond what we typically see in a Wintel box. But this will change. Pretty soon. 64bit is the future. In the future.