• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Blogs for Florian Becker [ Blogs | Profile ]
Permalink | Twitter Post to Twitter | Comments (0) | Views (1039) |

posted by Florian Becker

I had the pleasure of attending Gartner's Symposium and IT Expo in Orlando in October. Other than talking to a lot of customers and partners, I took time off between booth hours to attend sessions and I was especially interested in anything labeled "Cloud".
Gartner defines Cloud computing as a style of computing, where elastically scalable IT services are delivered to customers using Internet technologies. This is one definition, and there are nuances between private cloud services (which corporate IT can build inside of companies to be more responsive to business needs) and public cloud services, which will enable companies to rid themselves of IT and consume services from providers - just like manufacturers stopped having their own on-premise power generators and are now consuming power from a utility. As a member of the Citrix Consulting organization, I was curious to see what the thoughts on a transition to the cloud would be. There is a lot of press and talk about the cloud itself at this time and it is not surprising that Gartner sees Cloud Computing on top of the Hype Curve with at least 2 yrs to wider spread adoption. Before that can happen though, we will have to move through the trough of disillusionment, but after we get over the mild hangover, we can talk shop.
Gartner looks primarily at three different types of cloud providers:

  • Infrastructure. Think providers of server on storage capacity a la Amazon EC2 and S3.
  • Middleware: Think providers of application developer platforms like Google Apps and force.com.
  • Applications: Think providers of applications that often run on the Middleware layer, such as salesforce.com, web-based email etc.

The piece that I was missing in the Gartner discussion was the Desktop in the Cloud, or Desktops as a Service (DaaS). Given that the public cloud mantra is still a bit in the future, this is not surprising, but the thought raises some interesting questions.
Unlike moving a few apps playfully to a cloud provider in non-production environment, moving a desktop into a public cloud requires a bit more thought. For one thing, the desktop must deliver the business applications and those apps often times need to talk to databases and file shares to be useful. Companies may actually keep this portion on-premise for the time being, so long as the communication from the cloud back to the datacenter performs reasonably well and can be secured properly. Consulting hint: Test the end to end response time to assess if this is feasible for your specific scenario. Given multiple regulatory questions such as "Who owns the data in the cloud? Who ensures compliance?" I would expect a lot of the backend data to remain in the corporate datacenter initially, even as desktops move to the cloud. Over time, networks will continue to provide ever increasing capacity and reliability, so the application latency introduced by backend resources is probably not necessarily going to be a showstopper.
So, let me go out on a limb and predict the future for Desktop in the Cloud (hosted virtual desktops running on shared infrastructure, accessed by end-user over public networks, used as the primary means to do work):

  • Desktop in the Cloud will first be adopted by small businesses or for desktops with a limited number of apps. Host a desktop with a web browser, office productivity software connected to a cloud-hosted web server (or entirely web-based email) and maybe include software such as Quickbooks and you have a repeatable, low cost desktop that can be used from the office or from home for a low monthly charge. Employees use their own personal PC or laptop to access this environment and gone are the days where everyone directs their PC troubles to the guy or gal in the office who happens play video games in the evenings.
  • Gartner stated in one session that ISVs will have to become good service providers to prepare for cloud computing. I actually disagree with that statement - it reminds me of the days when software vendors aspired to be ASP's. ISV's will have to provide software and licensing that is conducive to a cloud model. The software licensing will have to change to allow for hosting in the cloud and a subscription-based pricing model. Software and data ownership will need to be figured out and the cloud provider with the most straight forward legal terms will have a leg up.
  • Desktops delivering a few critical apps will be next. Think call centers or the healthcare vertical. Those are fairly simple desktop implementations without a lot of application complexity or a requirement to let traveling users connect or work offline.
  • Enterprise Desktops (those delivering pretty much any app and connect to a myriad of complex application back-ends) will be the most challenging and probably take the longest to achieve widespread adoption in a cloud model. One can imagine the offline use case being solved by streaming an offline operating system to an endpoint, and some of the emerging file synchronization solutions in the cloud ensuring that all corporate data is properly synchronized between online and offline usage.

One of the items that the industry hasn't figured out yet is a service level agreement (SLA) standard for virtual desktops. We have SLA's for servers and applications, but not for desktops, whose users are a lot less forgiving for latency for basic desktop interactions or the inability to access them. To establish and enforce SLAs for the desktop, end-to-end monitoring solutions are key that allow both the provider and the customer to pull reports on response times and overall system performance.

I remember one additional line from the Gartner Symposium keynote. According to their surveys, some 60% of CEOs believe that IT is constraining their business. What that tells me is that business leaders will need to have more trust in their cloud provider than they have in their own IT. Therefore, I predict that the Desktop as a Service providers of tomorrow will be the large system integrators. They are already trusted by many corporations to run IT end to end and have the expertise and backend capability to deliver hosted services with strong SLAs and security.

Florian Becker
Director, Worldwide Consulting Solutions
Follow me on twitter: @florianbecker

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (2) | Views (1216) |

posted by Florian Becker

When was the last time that a representative from your company's IT department spent an hour sitting down next to you and observed you while you were doing your work... for no other purpose than to learn about your needs and work habits so that IT can  provide you with better service, a better environment, and better application support?

Before you answer, I'd like to point you to a discussion on these pages that triggered me to think about this question: 

Daniel Feller authored a piece  which talked about the desire of users to install and manage their own applications in a virtual desktop environment. Dan gives several reasons that detail why letting users install their own apps in a virtual desktop is a bad idea in his opinion.

Brian Madden responded to some of Dan's points and stated that the flexibility and feel of control associated with user installed apps is critical to user adaptation of virtualized desktop environments. Therefore, Brian suggests providing each user with two desktops - one tightly managed by IT with approved applications; the other one more free-reeling to allow for any tool, utility, or app installed by a user. There are arguments for both sides and the common trade-off between user flexibility, IT's management capabilities, and cost must be considered during virtual desktop implementation projects.

So far, the virtual desktop discussion focused on increasing security through centralization and reducing desktop support and operating costs. Those are benefits primarily to IT. What about the users though? What's in it for them?

I spent several years in healthcare information systems, where the most valuable users (doctors and nurses, but especially doctors) are often the most reluctant to change their workflows towards the use of a computer and away from the voice recorder and paper notes that someone else has to decipher. How do you get these users to accept and embrace an electronic medical record (EMR) system? You have to state the benefit to them and let them experience them first hand! In this example  it means fewer patient deaths and complications due to missing or incorrect patient data and overall better patient outcomes. This appeals directly to some of the main reasons why these users are in their chosen field in the first place. Post implementation surveys among doctors and clinicians was overwhelmingly positive  once a doctor realized that she had the patients medical history at her fingertips and was more efficient in documenting her care.

Successful EMR implementation were all characterized by a fundamental shift in thinking in IT. Away with the old "this is not supported" argument of IT and away with the strict segregation of IT responsibilities between network, OS, servers, virtualized servers, databases, applications,  cross-system interfaces, storage, and "Citrix".  Our customer IT teams and we (the EMR software vendor) spent countless hours on the hospital floors, in emergency admission departments and in the operating room - simply to observe our users and provide the best possible products and the highest quality implementations to them. Our customer IT teams almost became experts in clinical documentation. On a side note, I am glad I wasn't on the OR team - I might have tossed my cookies...

Just like EMR implementations, virtual desktops have the potential of being disruptive and enabling at the same time. There is a fine line between providing a desktop from anywhere and excessively restricting capabilities. Successful implementations rely on strong leadership from the CIO down. Many EMR implementations include the Chief Medical Officer, CIO, Nursing representatives and traditional IT roles. By the same token, the virtual desktop initiatives must be guided by principles of including key user representatives and an IT organization that truly understands user needs. This should be understood at this point among many readers of industry commentary on desktop virtualization. However,  I still see many large organizations who make implementation decisions driven by their own organizational structure and  technical drivers (sometimes even politics). Of course, IT must enforce license compliance and protect environments from the hazards of poorly written software, but that imperative doesn't have to make it more complicated for users.

Back to the discussion between Dan and Brian:  I tend to agree with Dan - one virtual desktop image - centrally managed by a capable, agile, and results driven IT organization.  I simply don't want to switch between desktops for different tasks and I don't think I should have to. Instead, users who want their own apps demonstrate the business case (a personal preference of one browser over the other probably won't cut it) and an IT organization who understands their users' core requirements verifies the business need and provides the required app. Done. Simple.  

Going back to the opening question: When was the last time IT came to you? If you're in IT management or if you're a CIO - when was the last time you spent some proactive time with your users and learned about their work?

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (1) | Views (9157) |

posted by Florian Becker

You are planning for a WANScaler implementation in your datacenter. For redundancy, you have multiple physical WAN Links and are planning to use the WANScalers in the simple "in-line" deployment in each one of the links.
While the WANScaler supports this configuration natively with the "group mode" feature set, network architects may wish to use an external link load balancing method instead. Depending on your network architecture, group mode can lead to additional traffic on the LAN side as network architects may not have the luxury of a separate network to handle the group mode related traffic .

This is where Citrix NetScaler can come to the rescue in a powerful way. NetScaler supports link load balancing capabilities that are well described in the product documentation. However, when designing for link load balancing with WANScaler in the picture, it is critical to ensure that the WANScaler appliances see all TCP segments associated with a connection in both directions. Therefore, special considerations need to be taken when designing link load balancing for WANScaler implementations:

(a) For connections initiated in the datacenter, it is critical that all TCP segments of the connections keep flowing over the same WAN link in both directions. This can be achieved by ensuring certain settings are applied (such as destination IP based persistency and the RNAT switch).

(b) For connections initiated from a branch office or a mobile user, the link load balancing decision must be made prior to the connection being actually established. This can be done by leveraging the DNS-based selection of NetScaler's Global Server Load Balancing capability (although we're not load balancing data centers in this example). Furthermore, once a selection is made by GSLB, the return packets must not be link load balanced, but must stick to the path selected in the GSLB step.

Sounds complicated? It's not too bad and to make it easier for you, you can read all about it in the Consulting Solutions design considerations article published here.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (7067) |

posted by Florian Becker

Dan Feller on my team contributed at least two posts on the topic of virtualizing XenApp servers on XenServer. Dan makes some excellent points and gives you plenty of business reasons why XA on XS is a good idea.

I am not going to re-iterate Dan's points here, but rather focus on another burning question in this context: How much of a scalability overhead can I really expect with my specific application? The typical consulting answer would be "it depends" and "we'll have to do a scalability / performance assessment to determine the specifics and best practices". So, we have done just that and used two popular enterprise class Applications: Siebel 8.0 and PeopleSoft 9.0. The Solution Center is one of the teams under the umbrella of Worldwide Consulting Solutions (Dan Feller's Integrated Solutions team is another) and focuses on these types of projects, which often involve third party applications and/or hardware platforms from our technology partners.
Recently, we looked at running the front-end of Oracle's PeopleSoft and Siebel applications on XenApp (both 32-bit and 64-bit platforms) and focused on comparing the user densities we could achieve on "bare metal" servers compared to running them on XenServer.
The results are published in two separate whitepapers (PeopleSoft, Siebel), which describe the test bed, test methodology, detailed results and interpretation. As Dan stated in his May 15th posting, the virtualization overhead can be as low as 6% for XenApp virtualization on XenServer, and our tests confirm this number. Of course, the numbers vary between the applications and platforms, and we describe all the details in the whitepapers.
Generally speaking, kernel memory limitations constitute the first bottleneck on 32-bit platforms, and our tests verified that behavior. Even with the popular /PAE switch, the kernel memory limitation remains at 2 GB. Therefore, you can expect a higher user density per physical server if you're running multiple 32-bit XenApp servers on a XenServer. You'd have to be cautious not to consume too many CPU cycles, which often become the next bottleneck once memory is no longer a major concern. Prices of multi-core, multi socket servers with plenty of RAM have come down significantly, so chances are that your latest servers have plenty of resources to run reliably in that configuration at a reasonable price:

According to this 1988 article, prices of 1 MB memory chips were as high as $60 (or $105 in today's money), while you can buy a barebones server with 64 GB of RAM for roughly $5,000 today. While I am on the topic of computer nostalgia: a 150 MB hard drive set you back over $8k in today's dollars way back when... 1988 was also the year Dan Feller was looking forward to seeing his favorite TV show getting its own slot in the line up and he is still enjoying it to this day, as you can see from the quotes in his postings on this site. But I am digressing...

The Solution Center also conducted detailed validation tests with Oracle to obtain validation status for running virtual images of the Web-, Application-, and Database servers of Siebel 8.0 , PeopleSoft 9.0, and Oracle E-Business Suite 12 on XenServer 4.1, so you can now be confident that the entire environment can be successfully virtualized on XenServer, allowing you to take advantage of XenMotion in case of hardware failure and other benefits.

Expand Blog Post