|
Rising out of the expansion of the Internet and related technologies is a new outsourcing paradigm. Businesses rent or lease systems managed centrally by an application service provider (ASP); their users can access the applications from anywhere on the planet, using standard IP networks, including the Internet, extranets, and virtual private networks (VPNs). In addition to hosting, ASPs take responsibility for smooth deployment and operation, including ongoing maintenance, software upgrades, customer support, and (occasionally) training.
For grizzled IT veterans who have seen their fair share of silver bullets, this latest slug seems at first glance to be nothing more than “timesharing over IP.” It is true that like timesharing, hosting offers rented applications, predictable usage fees, rapid deployment, and the elimination of in-house upgrades and maintenance. But as many ASPs exclaim, hosting also offers global reach — undeniably true in most ASP scenarios — as well as overall cost savings that are … well, we’ll see.
Who are the key players in this emerging market? The leadership features a class of relatively new (albeit well-funded) ASP “pure plays,” generally fronted by seasoned management teams: Breakaway Solutions, Corio, Cysive, FutureLink, iXL, Pandesic, and USinternetworking are examples. Also joining the fray are hardware companies, application vendors, Internet service providers, Internet service and operations firms, and traditional service firms. Most ASP plays involve some partnering arrangement between two or more service providers.
The profusion of hosting providers and the complexity of their partnering arrangements makes the process of screening and selecting an ASP — or simply determining who the players are — difficult in the extreme. Unfortunately, most articles, analyst reports, and commentary have focused on the business model and market, with little thought given to the technical services required for the ASP solutions to work. In this column, let’s try putting the horse before the cart and examine some of the application, database, system, and network services that must be in place before an ASP solution can even be contemplated.
Most ASP systems fall into the four basic food groups: e-commerce (B2B, B2C, Web advertising, procurement, and billing); office automation (email, groupware, collaborative planning, and virtual office solutions); back office (payroll, human resources, supply-chain management, and electronic payment); and vertical market (such as legal, finance, or real estate). You can expect more to be added over time, covering all kinds of different applications. To make their services appeal to the broadest market, ASP purveyors often limit the degree to which you can customize the systems or integrate them with others. Of course, for some companies the accrued advantages of Web application hosting might outweigh the benefits of customized systems.
Frequently, the most critical piece of software provided by an ASP is not the hosted application itself but the support software that guarantees performance, scalability, and robustness. For example, does the ASP employ an IP load balancer to intelligently route Web server requests? Does it provide an application server to balance loads, mediate and broker user requests, and integrate data and application functions to meet those requests (or simply execute logic)? How does the ASP support database connection pooling and connection management? If your prospective ASP believes that cache is something you get from an ATM, perhaps you should look elsewhere.
System and Architecture
Currently, ASPs vary radically regarding the manner and degree to which they support basic infrastructure elements. For example, some ASPs provide a dedicated server for each of their customer’s applications and data, while others support only shared servers. Shared servers host applications from a variety of companies — typically small businesses accessing low-volume applications. While shared servers present a potential security risk, most ASPs have gone to extraordinary lengths to isolate and secure applications and data. As you would expect, a shared server solution is more economical.
There’s a third hosting option offered by many ASPs: collocation. Clients place their own server physically within the ASP’s server farm. The ASP provides connectivity, power, and equipment racks, with the server and application(s) managed either by the ASP or remotely by the customer. With some ASPs, clients are required to purchase their collocated hardware from the ASP.
ASPs also differ in their support — or lack thereof — for multiple hosting (data) centers. Smaller ASPs typically offer only a single hosting center; as they grow, they might add additional hosting centers. With multiple hosting centers, the ASP can make applications available on geographically dispersed servers. Generally, the closer the hosting center is to the client, the more rapidly users can access applications and content.
Multiple hosting centers form a necessary — but not always sufficient — platform for the replication and mirroring of customer applications, data, and content across servers at different locations. Replication improves response time by reducing the distance application calls must travel; it also eliminates the single point of failure, thereby increasing the reliability of the solution. If a hosting center goes down, the ASP can shift traffic to a replicated site automatically so that service is not interrupted.
Many ASPs, including some that offer multiple hosting centers, do not support replication. They note that most clients are unwilling to pay the additional costs (typically a 20- to 60-percent surcharge). ASPs also cite synchronization difficulties and the scarcity of technical talent required for supporting mirrored sites. Instead, many ASPs feel that by employing redundant servers, lines, and power sources in a single hosting center (in other words, single-site mirroring), they can overcome the single point of failure problem for all but the most catastrophic circumstances.
ASPs also differ in hardware and systems software. ASPs are determined to reduce the combinations and permutations of hardware, systems, and communications software that they must support; therefore, ASPs will often limit deployment options to a particular browser release, operating system variant, or Web server combination. Before choosing an ASP, you need to consider what impact the ASP’s limitations on back-end runtime architectures might have on performance, ongoing support, and overall costs.
Network Issues
How does the ASP enable clients to access the hosted applications, databases, and system services? This is obviously a key consideration. ASPs offer a variety of network options for accessing the hosted applications. Internet-based access is particularly sticky. Recall that the Internet consists of approximately 60,000 linked networks with servers, which are connected through a limited number of public peering points, including metropolitan area exchanges (MAEs) and network access points (NAPs). Public peering points are subject to high volumes of traffic that can severely reduce access times.
To optimize performance, ASPs should provide diverse and redundant connections that avoid public NAPs. ISPs that offer application-hosting services often employ their own backbone to provide a direct pathway to global Internet destinations. Other ASPs avoid congested NAPs by forming private peering points with other carriers. With private peering, providers agree to exchange traffic at a mutually agreed upon private access point. There is, however, a barrier to entry that limits private peering to all but the largest ASP/ISPs. Typically, private peering requires at least four direct T3 connections to each provider in the peer group.
Transit peering is an alternative to private peering. With transit peering, an ASP will provide a direct link to another ASP/ISP backbone. The ASP simply hands off all the traffic addressed for users not on its network to another carrier for delivery. Unfortunately, the ASP has little control on how the traffic is delivered downstream.
How does your prospective ASP connect its hosting centers to the Internet in the first place? As you evaluate ASPs, remember these watchwords: redundancy, bandwidth, and over-engineering. ASPs should provide redundant physical links that run from different sides of the building. Most ASPs will gladly cite how many lines and how much bandwidth they have available: T1 (1.544 Mbits/sec.), T3 (45 Mbits/sec.), OC3 (155 Mbits/sec.), OC12 (622 Mbits/sec.), and OC48 (2.4 Gbits/ sec.). However, the actual available bandwidth is a function of how many LANs are connected to the WAN at the hosting location, how many other servers are located at that site, and the overall amount of server traffic at the hosting site. Some ASPs cap the amount of capacity allotted to each customer — a practice known as “traffic shaping.”
Wishful Thinking
Web application hosting promises corporate sites large reductions in server and software capital expenditures. Hosting also offers an opportunity to reduce IT staffing and the associated overhead required to deploy and manage systems, not to mention a way out of the problem of hiring IT personnel in an extremely tight labor market. Businesses are thus free to focus on their core competence. However, while all of this sounds very appealing, do not base your decision about whether to go with a particular hosted solution solely on a strong business model, intuitive reasoning, and wishful thinking. The technical aspects to successful application hosting are not trivial. Ignore the theory and hyperbole: Focus first on how a hosted solution can really work, and then determine whether you should try it.
Dan Kara is CTO of the Intermedia Group, a research and analyst firm based in West borough, Mass. He can be reached at dkara@intmedgrp.com.
|
|
|
|
|