Setup Can Be Complicated
In any thin-client environment—ASP or inhouse—application setup can be complicated. Very few companies design applications for multiuser environments in which many instances of one application run on the same computer. For example, applications might reference machine name or IP address instead of username—a problematic scenario because the applications are actually running on the terminal server, not the client computer that is displaying their output. Also, applications must be able to maintain per-user settings even when multiple instances of the same application are running simultaneously. And although an application might be capable of running properly in a multiuser environment, you need to make sure—
particularly in an ASP setting—that customers can run only the applications to which they have approved access. You must disable any command-line or .exe browsing support in their applications.
To ensure that applications run securely on Push's application servers, the company subjects new applications to a three-step deployment process. First, Push tests the applications inhouse. During this process, engineers attempt to break in to the command line from the application and study the application's code for features that could present problems in a multiuser environment. (For some potential problems that engineers look for, see "Tweaking Applications for a Multiuser Environment," September 1999.) If an application's features expose too much of the OS or file system, the engineers strip them out. Humans do all the work—Push hasn't found any automated tools that work as well as an engineer. The length of this testing period varies from 1 day to 2 weeks, depending on the application's complexity. If necessary, Push talks to the application's developers to resolve problems. Sometimes, the company finds that it can't resolve problems in an existing software version. For example, if an application can run only as many as 2 simultaneous instances on the same server, it won't run on a computer that needs it to support as many as 30 concurrent instances. In that case, Push informs the developer about the problem and asks for a terminal-server-compatible version of the software, which the company might not receive immediately but can hope for later. As more companies use terminal services as a method of deploying Windows applications, more developers will likely make their applications multiuser-aware.
After the engineers are satisfied that the application will run without problems (and have made any necessary modifications), Push deploys the application on a test server. There, the customer works with the application to make sure it's functioning properly. When the customer is satisfied, Push deploys the application on its production servers. This deployment isn't necessarily an all-or-nothing procedure: Push rolled out one application for a client with 250 seats very carefully—one department at a time—so that both Push and the client could evaluate the deployment's progress and fine-tune as necessary.
Because of the way Win16 and DOS applications run under NT, they don't perform as well as Win32 applications in a multiuser environment. In short (and all else being equal), supporting multiple instances of a 16-bit application requires more memory than supporting multiple instances of a 32-bit application. Therefore, Push doesn't encourage its customers to choose 16-bit applications. The company is currently trying to discover how to support a 16-bit application that one of its customers wants to use. At the same time, Push has convinced the developer to create a 32-bit version of the application that offers the same functionality.
Supporting ASP Customers
One of Push's customers is GiftTracker, a small company that issues gift certificates for stores that don't have an inhouse certificate program. GiftTracker chose an ASP solution for two reasons. First, like many business-to-business (B2B) providers, GiftTracker doesn't have an IT staff. Second, some of the applications the company wants access to (e.g., the Great Plains customer database) are too expensive for a small company to set up and house. From GiftTracker's perspective, almost no setup is necessary: Push engineers installed the ICA client on GiftTracker's computers and it worked—end of story. From Push's perspective, the task was a bit more complicated (not surprising to anyone who has set up an application to work in a multiuser environment).
What's the complication? In many ways, supporting ASP customers is like supporting inhouse terminal server clients: You need a reliable network, you need enough server resources to keep client applications running at a reasonable pace, and you need to provide a secure environment by locking down customer applications. However, if you need to support customers who aren't part of your company and aren't in the same building as most of the servers, you face additional hurdles. For example, Push can feasibly maintain all customer accounts on one domain controller—as long as the domain controller can authenticate all those people. (Push uses dedicated domain controllers to authenticate users.) However, if customers have specific security requirements because of agreements with their customers, Push must match or exceed those requirements. Therefore, some customers have their own domain controllers and even their own network segments inside the data center.
Similarly, Push maintains multiple server farms, which are logical groupings of terminal servers that contain the same applications. Clients connect to the server farms, which automatically forward the client to the least-busy server that supports the desired application. Push maintains server farms not only to organize applications but also to provide dedicated server farms for larger customers.
Push must also account for network reliability. The company uses HP OpenView to monitor network traffic and uses Packeteer's Quality of Service (QoS) product, AppVantage, to ensure that client performance is consistent with service level agreements (SLAs)—a measure of uptime and application performance. However, Push can't control the network end-to-end, even though the company keeps an eye on its portion. Because Push's pipeline to its customers is a public network, the company can't physically protect every part of the network from outages. For maximum reliability, Push maintains outside connections with three public networks: two national networks and one local cable company. Rich says that Push's customers have the option of maintaining dual network accounts to avoid outages that individual ISP problems cause.
Push has a large, growing, and varied user base—the company can't simply set up applications and move on to the next customer. Also, finding talent to support server-based computing isn't always easy. As Rich observes, "[Multiuser Windows] technology is young, so there's not a lot of expertise out there." Because Push evolved from Make It Work, which was a systems integrator, the company is having an easier time than an ASP new to terminal services or to MetaFrame might have. However, as anyone who has supported terminal services knows, supporting clients in a multiuser environment is a constantly evolving process, particularly when you're dealing with a changing group of users and applications and trying to ensure that your customers always have access to the latest software enhancements.
Future Plans
Because ASPs assume many of the duties of their customers' IT departments, ASPs generally engage in the kinds of technology evaluations that large companies with many seats to support engage in. In many ways, ASPs are large companies with many seats to support.
Having recently implemented some server-side modifications—introducing HP's OpenView for network monitoring, utilizing load balancing and failover clustering for file servers and mail servers, and changing the base network from a distributed model to a more centralized data center—Push is starting to make some changes to the service's client side. Today, Push supports any device (i.e., Windows terminals or PCs) that works with the ICA display protocol. However, in a thin-client environment, supporting PCs presents potential difficulties, because PCs are more vulnerable to misconfiguration than terminals are. Therefore, Push is considering Netier Technologies' NT Embedded Windows terminals for customers who need to run both locally installed applications and applications residing on the remote server. These terminals, which vary in hardware profile depending on customer needs, can work with Rapport—Netier's remote-management utility—thereby letting Push configure and update customer terminals from its main data center.
Today, Push uses NFuse to support some clients and ICA to support others. Eventually, most of its customers will access applications using this Web-based program neighborhood.
Chasing Nessie
Small businesses that lack dedicated IT departments can have trouble gaining access to applications and data security that larger companies might take for granted. Using technology such as WTS, companies such as Push can give smaller companies access to applications and infrastructure they couldn't otherwise obtain. Although the ASP model isn't yet widely deployed, industry analysts expect it to increase in popularity over the next 5 years because of this need. I wouldn't expect Nessie to soon rear her head in every office, but as people become more comfortable with the idea of outsourcing traditionally desktop applications, we'll have a few more photo opportunities.
Register
