Pushing Applications to the Masses

An NT-powered ASP blazes a trail

A hot topic of 1999 and now 2000 is application service provision. However, although the application service provider (ASP) market has much potential, it reminds me of the Loch Ness Monster: Everybody talks about ASPs, everybody knows someone who claims to have seen an ASP, but most people have actually seen only a blurry photograph.

Today, any company that offers any kind of online service or IT outsourcing seems to call itself an ASP. However, the basic notion of an ASP is that one company purchases software licenses from an independent software vendor (ISV) and resells them to its customers. (Some ISVs offer their own software and skip the middleman, but more often an ASP resells licenses.) The company pays the ISV either a flat fee for the right to resell the licenses or a per-user fee, which is a percentage of the cost that the company charges the user. Depending on the choices that an ASP offers, customers can access these applications through several types of connections: the Internet, private links such as T1 connections, and semiprivate links such as frame-relay connections.

One of the ASP concdept's strongest selling points is that ASP structure makes IT costs more predictable—not only licensing costs but also the costs of data storage and protection, links to the service, and Help desk support. The cost structure depends on the deal that the customer makes with the ASP. Some ASPs charge per user, some charge a flat fee for any user at a customer site, and some charge according to which parts of the application the user accesses—the latter particularly in the case of complex vertical applications. Some ASPs require their customers to make a minimum time commitment to the service. The required time commitment depends on the complexity of the application setup. Given the amount of work necessary to set up a company to use complicated software configurations, minimum contract terms aren't surprising. For example, one ASP estimates that the time required to set up a suite of vertical applications is 1 to 6 months.

ASPs can use three models to get applications to their customers. The first—and oldest—model is a system that includes a client component and a server component. The second model, which is more common today, is a Web-based system in which applications display in a browser (often a front end to a vertical application) and originate from a Web server. The third model, also increasingly common, is a multiuser system wherein the ASP installs applications on a terminal server and lets multiple users access the same server, sharing memory and compute time.

Push, an ASP based in Santa Barbara, California, uses the terminal server model of application publishing. The company uses Windows NT Server 4.0, Terminal Server Edition (WTS) and Citrix MetaFrame 1.8 to deliver applications to its clients through the Citrix ICA display protocol or the NFuse Web interface.

When Push Comes to Shove
Push began as a company called Make It Work, a Citrix solution provider that began performing application hosting. According to CEO Eric Greenspan, Make It Work stumbled into becoming an ASP about 18 months ago, when an East Coast customer needed access to the applications in Make It Work's West Coast office. Push changed its focus from systems integration to application service provision in September 1999. The company uses the terminal server model for application delivery for two reasons: First, this model lets users access a traditional desktop if necessary; second, terminal services let customers customize their application settings rather than endure the static user interface (UI) that Web-based applications typically provide.

ASPs can provide not only application servers but also entire IT infrastructures, including file servers, database servers, and email servers. When Push first introduced its ASP environment, the company used a model that differed from the centralized model most ASPs use today. Rather than maintain the servers from a central location, Push created "community centers" within the customers' geographic area. This way, the company's customers would be comfortable knowing that their data and applications would always be nearby and not feel nervous that their entire IT infrastructure was both far away and shared with other Push customers. This model would let customers access applications even if they had local access problems: Customers could simply drive to the nearest community center and use workstations there to access their data. However, a shortage of experienced technical-support personnel caused Push to abandon the community center model. (Push retained the community centers for sales executives and application specialists to offer local support.) The company has since established a centralized data center in Santa Barbara, where approximately 200 file, mail, database, and application servers (necessary to support Push's growing customer base) hum inside a fireproofed and secured facility. Figure 1 illustrates Push's centralized model. At press time, this Santa Barbara data center is the only site that Push uses. The company is currently scouting locations for an additional data center on the East Coast to provide local customer support to that region, as well as redundancy for the West Coast data center.

One advantage of a server-based environment is that it can offer more OS independence than a client-based model can easily offer, because the client in a terminal server or Web-based model doesn't actually run the remote application but rather displays it. However, OS independence applies only to the client side. On the server side, the applications must be compatible with the server OS. Because Push relies on terminal servers running WTS and MetaFrame to serve its clients, the company provides Windows-based applications (including Windows-based clients for non-Windows applications) that can run on that platform. Clients interact directly with the terminal servers running WTS Service Pack 5 (SP5) and MetaFrame 1.8. From there, customers run their Windows-compatible applications. The terminal servers might interact with other NT-based servers, depending on the applications that the customers use.

For example, if a customer gets its email from Push, then the email client running on the terminal server interacts with the data center's Microsoft Exchange Server 5.5 system. If the customer stores sales data in a Great Plains application, then the Microsoft Access 2000 client running on the terminal server interacts with a Microsoft SQL Server 7.0 machine that's supporting the database. Currently, about 200 servers (i.e., production and lab) support the entire operation, and 15 of those servers are terminal servers. Michael Rich, CTO of Push, likes to remain 30 percent ahead of required capacity, so he keeps in touch with the sales staff to monitor future customer requirements.

Push's customer base currently consists of about 10 companies, each with from 2 to approximately 200 seats per customer site. All the servers in this environment—storage, mail, database, and applications—run NT Server 4.0 (single or multiuser version, depending on whether they're application servers) and have similar hardware profiles: 600MHz 2-way Hewlett-Packard NetServers with 1GB of RAM. This configuration lets the ASP support about 30 users on each of the 15 application servers. For increased reliability, the storage servers have a RAID 5 external drive array. Generally, Push subscribes to the "many small servers" model of thin-client computing: Keeping many small servers gives the company spare servers, with which Push can easily add capacity or take over for a failed server.

Because hardware problems are exacerbated when many people depend on a server, you'll find all the hardware in Push's ASP environment on Microsoft's Hardware Compatibility List (HCL). Rich explained, "Terminal Server and MetaFrame have little flexibility when it comes to hardware compatibility." Even when Push used the community center model and was willing to maintain customer servers and applications, the company insisted that the customer equipment appear on the HCL, simply to reduce support problems.

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.