Most people reading this understand the concept of "application delivery." They get that it's more than server-based computing or application streaming. They know that IT is about providing applications to users, and that today there's a plethora of different technologies for delivering these apps.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Ten years ago it was easy. We only had two options: Citrix (the new way), and traditional installs (the old way). But in 2007 we have application streaming, virtualization, and isolation; VDI- and Terminal Server-based server-based computing; local installations, local streaming, remote desktops, remote isolation, OS streaming, OS isolation.... the list goes on.
I travel extensively. The one question I'm asked again and again is, "With all of these different methods of deploying apps, how do we figure out what we should use in our environment?" (The second most frequent question I get is, "what's real and what's not today?" But that's a topic for another day. ;)
The topic of trying to figure out which technologies should be used for which apps came up in the training class I taught last week in Paris. The attendees and I brainstormed about this for awhile, and we ultimately created a series of questions and a simple flowchart that we think can frame the conversation.
Before we look at that, I want to point out a few things:
First, this flowchart and these questions are not all-inclusive, and they're not dogma. Ultimately you need to do what's right for your environment, and you need to mold the solution so that it works for you. Our goal was a create an organized way to think about these issues.
Second, we built this for Windows applications. Web apps have their own complexities, but their complexities are different. (Ironically, as more and more web apps use specific versions of the .NET framework, Java, ActiveX controls, and other plug-ins, a lot of people today are treating web apps as Internet Explorer packages that are no different than any other Windows apps.)
Third, this framework assumes that you're focusing on application "use cases." For each application, the properties of a specific user (or group), a client device, and a client device make up the "use case." You might have to work through this excercise a few times for each application to catch all of the use cases. (Sales reps in the field with company-issused laptops is one use case. Client support reps in the office with a desktop PC is another use case. Business support staff connecting from their home computers over the Internet is a third use case.)
Finally, there are more technically-detailed (yet slightly different) views of this data out there. Ruben Spruijt created a very technical flowchart for BriForum 2007 Chicago that walks through all the various technical application delivery options. I've also seen (although I can't find at the moment) a giant table from Citrix that lists application delivery methods on one axis and the various properties (use offline, use with non-Windows clients, etc.) along the other axis.
That said, let's take a look at the flowchart we created last week. Detailed explanations of each decision point follow.
1. Application execution location
The first question to answer is where this application needs to execute: locally on the client device or remotely in the datacenter? (In other words, will you "remote" the application?) The following questions can help you make this decision for the particular use case that you're evaluating:
- Do users need to access the app from non-Windows clients?
- Will the application ever need to used from a client device with no network connection?
- Are there high back-end data requirements? (Does the application need access to back-end data to be used? How much data?)
- Do users need to start the application quickly from new devices?
- Does the application need to access data that's stored locally on the client device?
- Does the application need to integrate with other apps? Where are those other apps?
- Does the nature of the application lend itself to being "remotable?" (i.e. are there high graphics requirements, multimedia, etc.)
- Do you need to ensure that data stays off the client device?
2. Multi-user or single-user execution environment
If you decide that the application will be remoted, then you need to decide what backend architecture you'll use. Can the application run on a multi-user system like Terminal Server? Or will it need to be isolated onto a single user instance of Windows? (Windows XP or Vista. Blade or virtual machine. Will OS isolation like Virtuozzo work?)
- Is the application terminal server compatible?
- Does it require admin rights or anything like that?
- Does it require some kind of physical key or dongle to run?
- Does the user need access to "the system?" (Admin rights, full control of Windows, the ability to reboot or install drivers, etc.)
3. App installation
Once you decide where the application will run, you'll last need to decide whether you'll virualize and/or isolate the application. This applies regardless of whether the application will be remoted.
- Is it even technically possible to virtualize / isolate / stream the app? (This will depend on what app virtualization product you're using.)
- Do you need dynamic application installs?
- Do you have a stateless user environment or stateless desktop?
- Does everyone need the app, or just some users?
- How hard is the app to manage? Is it worth virtualizing?
- How many other apps will run locally in the context of this app?
- Do you need the raw application performance?
That sums up the basic questions you need to answer. Remember that you'll need to work through this for each use case for each application.
You'll have to be somewhat flexible with your results. For example, if you decide to build a large VDI environment, but a few of your app use cases ideally call for terminal server-based application remoting, you might decide to just use the VDI infrastructure for those few apps instead of building a dedicated terminal server environment just for a few apps.