Pushing Applications to the Masses

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.

   Previous  [1]  2  Next