Application Service Providers bring the mainframe + dumb terminals model to the Web, and users get all the benefits of a centrally-maintained system. Unfortunately, the distance from your house to is longer than that from your office to the admin down the hall, and it can be harder to hold your provider accountable. In today's editorial, Paul Reiber points out the downsides of ASPs.

ASP-based solutions are slowly making inroads into the territories enjoyed by traditional applications. Understanding the differences can help users to choose wisely.

The reasons for using an ASP are quite sufficiently described by the companies touting them as solutions. On the surface, ASPs look very attractive for many reasons. As with the current madness, there are some important but too often overlooked issues with using ASP-based applications. Here I provide six reasons why users might choose to remain with the more traditional, locally-running application:

Latency. Contrasted with bandwidth, round-trip latency describes the time it takes for what you enter to be sent to the application, processed, and returned to you. Examples of high-latency ASP applications are forms which make you wait, sometimes for minutes, as they process your request. Local applications are much more responsive than apps running on a server that is arbitrarily far away, both because of the network in between and because you're typically the only one in line to use them.
Availability. If your computer works, your local applications work. ASP applications depend upon your Internet connection, your ISP, their connection, (probably) some Internet backbone, and the remote server on which the ASP is running. That's a lot of hardware. The more there is, the more things can go wrong.

Data lock-in. ASPs introduce data lock-in problems which can be much worse than "file format problems" which are typically associated with lock-in. You know this problem well if you've ever attempted to move your resume from one word processor to another; the file format conversion routines almost NEVER get it perfect.

What happens with ASPs is that you will probably not be able to get at your data en masse at all. You probably won't be able to get a restorable backup in your own hands. You probably won't be able to export the data from that ASP into some format usable locally or by another ASP. I use the word "probably" above because, while it's possible that an ASP might provide for one or two of them, they're all not in the best interest of the ASP itself, so they're not going to want to do them. If they do, there will have been arm-twisting involved.

My experience divorcing myself from the Yahoo! email ASP is a good example of how data lock-in can affect users. I had a simple goal: offload a copy of all of my archived email so I could search it locally without involving Yahoo!, Netscape, PPP, and a phone line.

I had been trying for about two years to get Yahoo! to provide a means of exporting folders. I griped about this to a friend, who thought for a bit, focused on the messages instead of the folders (duh!) and this approach emerged:

It's pretty nasty, because while you're doing this, incoming mail can get mixed with the archived messages. Given that this isn't Yahoo!'s solution, but rather just a user's ONLY choice, that can be an acceptable risk.

First, clear the inbox. You'll be doing that a lot. Move all messages from folder A to the inbox, use POP to pull all email from the inbox to the local machine, save locally into a new folder named A. Repeat for all other folders...

If you ever try this, you'll quickly wish Yahoo! had a "select all" button in their folder interface. Users are forced to hand-select EVERY SINGLE EMAIL MESSAGE in each folder, one-by-one (fun when you have over 5,000 archived messages, as I did), to be able to transfer them to the inbox. Also, enabling POP involves agreeing that Yahoo! can send you advertisements via email. No Thanks...

The procedure is labor-intensive, error prone, and can easily take more than a day if you've got as much archived email as I had. At my normal billing rate, divorcing myself from my "free" Yahoo! account cost me over $1,000 in the end.

Performance. ASPs will suffer from a deluge of visitors at certain hours of the day, and performance will degrade. For business reasons derived from the rules and regs of provisioning, they simply cannot make it perform perfectly at those times; it's a spiral. They have to let the performance suffer, primarily to coerce some people into changing their habits and visiting at other times.

The phone companies have the "Mother's Day effect" -- statistical analysis done on usage patterns must often ignore data from Mother's Day or the numbers will be just plain wrong. ASPs will have similar problems with miriad users connecting from 6PM to 8PM in certain situations (what's on TV?) from 8AM to 10AM in others (how are my stocks doing?) and on certain days of the week as well (what's going on this weekend?).

Security. Even if an ASP has an absolutely great privacy policy, if they're on the Internet, they can't stop someone from stealing a copy of the data. Trust me, if someone wants that data badly enough, they'll get it. Even the Pentagon gets data stolen from it from time to time.
Privacy. "Ooh... they might be watching you." Most ASPs today have privacy policies which, when boiled down from 3 or 4 pages to 3 or 4 sentences, state:

"If you don't want us to sell your information, we'll try not to. But accidents happen. We might sell it anyway. You agree there's nothing you can do about it."

The ASP will know a LOT about you, your work habits, your family... Even if they have a bonded privacy policy today, they could change it tomorrow. As a business, they consider any information they have about you to be THEIR property, and the unscrupulous among them will use it to stay in business if times get tough.

After having just presented six compelling reasons to stay away from ASPs, it may be hard to believe that I'm actually a supporter of the idea. Well, I am, but with significant changes from the way ASPs work today. I learned a long time ago that problems are easier to swallow when chased by solutions, so I'll provide a short description of potential solutions to each problem. Now, whether you LIKE the approaches below is another thing entirely... :-)

- Latency. Go get a cup of decaf; there's nothing that can be done about latency. The speed of light is a constant; most stuff goes slower than that.
- Availability. Buy a second contract with a second ISP that uses a different connection to the backbone. You've maximized the odds of connecting to your ASP.
- Data lock-in. Save everything into a local file or database, then copy and paste it into the ASP's interfaces. Fun, huh?
- Performance. Log in at 4:00AM. Seriously, try logging in at times when others probably aren't.
- Security. Make friends with a cyber-terrorist. The best way to not be targeted is to be friends with the guy with the gun.
- Privacy. Anonymity. While the remainder of these "solutions" are pretty tongue-in-cheek, this one's real. The best way to maintain your privacy while still being able to use an ASP is to maintain your anonymity.

Pick a pen name -- a pseudonym -- and a non-existent mailing address, but with the city, state, and zip code correct. Most importantly, use a Web-based email account, such as Yahoo!'s email, as a pseudo-id. This is an account where all you do is throw away incoming email; ASPs will email you there to verify your ID, and send you advertisements there as well. It's your own personal digital garbage can; enjoy it.

Armed with the above, you can safely manage to use ASP services without compromising your privacy, for the most part. If you have a fixed IP address, however, you're sunk on the privacy issue. Fixed IP addresses are a bad idea if you like privacy and anonymity.

  • What is your reaction?
  • powered by Verysign
  • like
  • unmoved
  • amused
  • excited
  • angry
  • sad
TENDINTA  |  SystemRescue 9.00 provides better NTFS support and support for custom ISO i...
John Doe         
John Doe
Articole publicate de la contributori ce nu detin un cont pe Continutul este verificat sumar, iar raspunderea apartine contributorilor.
335 articole
In context

  • Comment
  • powered by Verysign

Nici un comentariu inca. Fii primul!