A Different xSP Model

Greetings, all:
Because I'm semi-immobilized with a broken leg, I've been musing about dependency. As we've discussed in previous issues of this newsletter, one of the biggest concerns among potential or actual application service provider (ASP) subscribers is network reliability. Network speed also is a concern, but you can't think about speed without thinking about availability. If you get applications from an ASP and the network connection fails, you won't have access to your applications or data. That fact can be a sticking point for people who are considering the ASP route because even the most reliable network connections sometimes fail.

Redundant networks are one workaround for this problem, but one that increases the service's cost. Another workaround is one that ASP Push tried for a while—maintaining neighborhood centers where customers can plug into their ASPs even if the connections to their offices fail. But that workaround was unfeasible because Push couldn't find enough experienced IT people to staff the work centers. Push found maintaining customers from a central location more feasible. (I also wonder about wide acceptance of a solution that requires people to work in someone else's office.)

Consider another idea: The server provider could host applications on the customers' sites (plugged into their local networks) and remotely manage those servers from and back up to its own data centers. Using such a configuration (what my partner Steve Greenberg and I call the Distributed ASP model) shields customers from loss of data or applications in case of network failure. The only loss customers might experience during an external network failure would be disabled remote-management features—no patches, no remote backups, no upgrades. However, customers could continue to use applications while the provider worked to get the network back up.

Greenberg and I have been considering how this model could work for an ASP providing applications in a terminal server environment, and last week I spoke with SilverBack, a company that has already implemented this model as a Management Service Provider (MSP).
http://www.silverbacktech.com

Like many xSPs (i.e., ISPs, MSPs, or ASPs), SilverBack's clients are primarily Small and Medium Enterprises (SMEs) that develop an online presence for brick-and-mortar companies and need monitoring and security reporting. If companies don't want to invest money or setup time to configure management tools, they can purchase Silverback's Internet Control Message Protocol- (ICMP-) and SNMP-based InfoCare service, counting on the company to patch and upgrade tools and back up any relevant monitoring data. So far, so familiar in the ASP world.

The difference is in the model's network topology. Silverback's customers wanted more control of their data than they could get through leased lines to a central staging area, so SilverBack developed middleware that lets them put their management tools in a small pizza-box device (the InfoNest) that resides behind customer firewalls and plugs into their networks. Silverback manages InfoNest via a virtual private network (VPN) called the InfoPipeline, and customers see management data displayed in the now Secure Sockets layer (SSL)-supporting InfoPortal. Customers keep 7 days of monitoring data on their sites, while Silverback maintains historical data at its data center. If InfoNest devices fail, Silverback ships customers new devices within 24 hours.

The rest of the offering is good, but unsurprising, for an MSP that targets the SME market. Silverback is slowly expanding its management offering from the network monitoring support the company offered in June to recently expanded system (CPU, disk, memory, and power supply on Windows NT and Sun Solaris) and application (FTP, SMTP, DNS, POP3, Oracle) monitoring. Silverback plans to support Microsoft Exchange and Lotus Notes monitoring in future releases.

The key point is that ASPs might be able to offer the benefits of outsourced applications without the liabilities of WAN dependency. Greenberg and I are fine-tuning the details of how to apply this model to ASPs (as opposed to MSPs), but we're sure it's possible. If we're right, this model could remove a large hurdle to ASP acceptance.