Articles / Six Reasons Not to Use an A…

Six Reasons Not to Use an ASP

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 my.service.com 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 dot.com 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:

  1. 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.
  2. 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.
  3. 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.

  4. 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?).

  5. 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.
  6. 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... :-)

  1. 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.
  2. 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.
  3. Data lock-in. Save everything into a local file or database, then copy and paste it into the ASP's interfaces. Fun, huh?
  4. Performance. Log in at 4:00AM. Seriously, try logging in at times when others probably aren't.
  5. Security. Make friends with a cyber-terrorist. The best way to not be targeted is to be friends with the guy with the gun.
  6. 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.

I'm interested in learning of any other problems inherent in the concept of ASP-based computing that you are aware of; please contact me at pbr@opencountry.org with the details. But please don't ask me to help you get your email archives off Yahoo!; doing that once was more than enough for me!


Before co-founding OpenCountry, Paul Reiber worked as a software product architect. He has been immersed in UNIX/Linux and Internet technologies for almost 20 years. As an early adopter, he has extensive experience building and repairing Open Source software including collaboration and infrastructure software. Paul has programmed in more languages than he can remember. His list of happy customers includes Ford, GM, EDS, NYNEX, FedEx, and Sun.


T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

Recent comments

11 Sep 2000 08:32 Avatar dscho

Application Service Providers
Some people do not seem to understand that security is a *BIG* issue.

There is no DNA involved using electronic highways. So it can be impossible to even know about a crime if you don't force physical evidence to be left (by storing data only on your own computer, which you switch off after using, locking your room and house, switching on the alarm system etc.).

Even if it is known to an ASP that your data was stolen, is the provider really interested in informing you of that? Making you loose trust in him and his services?

P.S. Webmail services are a very good example of ASPs because they have already reached numbers of users so as to judge their capabilities.

30 Aug 2000 18:22 Avatar serxx

Appropriate use / abuse
This is another of those use/abuse topics. Jeff is right, from one perspective, and I think he's more or less clear about where he's coming from. ASPs are much more acceptable in a business environment, when the company itself is running the ASP. Is it technically an "ASP" in this case? In some cases, ASPs are useful for home users. Although I wouldn't advocate using webmail as a primary interface to email, it is handy when I'm away from a computer I own. Having an account with an ASP word processor is handy for the same reasons, although I wouldn't use it for anything more than authoring trivial documents. Jeff is correct, however, about several points.


First, a (home) computer with a temporary internet connection is more secure than a server that's on-line all the time even if the user is a security novice, simply because of availability. Second, if a user accidentally erases his/her data, this is *acceptible* (note, I did not say "desireable" or "non-damaging") by the user. If the *ASP* loses or corrupts the data, this is entirely unacceptable. Third, availability is very important for certain activities. Most people know ASPs through email services or some such, and I'd argue that if the network goes down, being able to access your email locally is of limited use. However, if I couldn't use my word processor because a construction developer cuts a telephone backbone cable (believe it or not, this happens about once a year in central Oregon), it culd be crippling. Fourth, privacy is probably the strongest argument about storing data at an ASP. The fact is that you can *not* trust any ASP with your data in unencrypted form. The ASP may be completely trustworthy, but ultimately, if they can access your data, you might as well assume anyone can. Which ASP won't roll over when presented with a court-order and hand over your data? Which ASP can vouch, unreservedly, for the honesty of every employee that has access to your data?


Would you believe them if they did?


When ASPs begin delivering applications which run on the client, that encrypt and decrypt data before transmitting that data over the network, and have been evaluated and proven by a third party to contain no back doors, *then* I'll start re-evaluating ASPs.

30 Aug 2000 00:11 Avatar pbropencountryorg

Public Discussion
Mr. Chi Huang; my relationship past/present/future w/ ASPs is a private matter.


Anyone on this list who has used ASPs and wishes to comment about whether these points are worth assessing when making the decision to use or not use a given ASP surely may.


Many people are happy that this list exists to help them make smarter decisions about how they'll implement their computing solutions. I'm happy to help them with that.


This isn't a courtroom in which ASPs are being judged. This is simply a LIST of questions worth having an answer for... ...when someone chooses to judge, for themselves, whether to use an ASP to manage data that's important to them.


Any free person on Earth may choose to apply any metric they prefer in making important decisions. Lists of things to think about - such as this one - simply help people to think through the issues before making up their minds.


Lists of reasons TO do something, lists of reasons NOT to do something. Both are valid lists.


Regards,
-Paul

Thanks, Fernando Martins, for your insights. They're not FUD, they're RUD. Reasonable Uncertainty and Doubt.


> From: mjr

> To: pbr@opencountry.org

>

>

> Some ASP companies may be unscrupulous enough to mine

> users/companies files for more clients. That address

> book for your e-mail would make a tempting target.

Of course it would. If they had it, and a lack of scruples, they'd quickly use it for business reasons having little to do with the happiness & success of their customer base.

> What about valued corporate information about a project.

> Such information could conceivably be sold

> to a competitor.

>

> Trust is a very real issue with ASPs!


I agree wholeheartedly.

-PR

30 Aug 2000 00:07 Avatar simon3001

RE: Reasons not use an ASP
It's kind of funny to look at these comments. I must say a lot of you seem to have the notion that some of the failures of an ASP do not exist or are minimal. The fact remains that these failures do exist and are very real. I do understand that midsize and small companies are more likely to profit by going to an ASP. I myself work in a large company. Despite all the propaganda though, our CEO told all of us that we will not use an ASP( solely for security reasons ). Now let me first clarify what is an ASP. An ASP to me is any one who sells as service his application to such a point where he shares that one application with as many people as he so chooses. That means any web application such as email , calendars, anti virus software, distributed client apps, applications applied through any kind of refresh mechanism one can think of, databases, SAP, Peoplesoft... . ASP means to the end developer that he/she does not have think about shrink wrapping, flyers, or advertisment brochures. Now here are the facts as I see them for distributed apps because that is what this is really about, where end users will have pay for the service the app brings.

Cons:


1. Security - It is well known that an ASP is on the internet 24 hours a day and if he is not I would ask question why. Because if an application is down and I can't get access to it then you would be costing me money. Therefore you are susceptiple 16 hours longer than my pc is at work since mine is shut down when I go home. A keen person may say that they use they use encryption on the wire. But it is also well known fact that any encryption scheme can be broken except for one time ciphers, in which case the keys are always thrown away. Plus anyone who leaves any machine on connected to the internet is at risk to a lot more than stealing of data, such as the ping of death, flooding attacks, man in the middle, etc.. The fact is that an ASP is going to more susceptible for a longer period of time. Another wise crack would be that end users are not as savy to restrict thier machines or let alone shut them off, touche( see pro ASP below ).


2. Latency - This is a problem for any distributed application. On good web application, within a company on a T1, 4 second download times are acceptable. That would include the pretty graphics and supporting files. Now some of you would say that even that latency time is attrocious, mind you that's the first time you hit the site. From then on most of the static material should cached on the desktop and on the web server if not already. But it is a well know fact, that shared memory applications out perform any over the socket application. Why, because they are not being translated to or from the tcpip stack. It is in memory period. Also, for the engineering in my mind, probability adds up when things are series not when they are in parallel. That is why anybody building distributed computing wants to have redundant systems. End users using an ISP or even corporate users who work at home are at risk. Why because things for him are in series on the frontend not the back. Now someone could make the remark that with an ASP, if your machine goes down then you could move to another workstation and continue, touche again( see pros below ).


3. Data lock in - This still plagues us in many ways. I think things though have come a long way from what it used to be like. Not to say that it couldn't happen again. If people opt for proprietary methods then this will continue exist. But some might say that there is XML, touche. But there is more than one way to skin a cat. And in fact anyone who has read the Halloween documents knows what I am talking about and whom I am talking about.


4. Performance - This is a problem and was even publicized in many articles. Companies such as Victoria Secret were knocked off line purely because of the number people who logged onto the site during the super bowl game. Similar stories such as these have occurred at Schwab, eTrade, and others( see pros below ). My own company has dealt with these issues before. In a lot of cases this goes with the territory of distributed applications.


5. Availability - for end users who use distributed apps from the home suffer from probability of not being able to access an application for several of reasons. a. There machine goes down for whatever reason ( This actually serves as a pro ). b. The telephone wire between the telco and the house is snapped for whatever reason. c. ISP provider is either knocked off line or has too many people accessing the ISP at one time. d. ASP provider suffers an outage for whatever reason. Note that these are items are in series and could not possibly be any other way. Now someone may say, we take care to make our apps redundant. But that still does not affect the other elements but rather the underlying total probability.


6. Privacy - It's kind of funny. There are companies, eToys, who have actually been less scrupulous. And were caught in the act of selling personal information of paying customers to third party companies. Again someone may say that already occurs today without the internet. True and in fact your medical care providers can tell you about this one.


7. Cost - Arguably this is a thorn. One could say that on the upside, you don't have to upgrade anymore. On the downside, you have to pay every month. If one just does the math, you will be able to see what it means for the end user at home. If every software costed $3 a month and the end user had one hundred different apps then this would literally be $300 a month. To me that's a damn nice car for the same amount. For companies this may not be a big deal. For the end user this literally would total to $4800 a year. Now again counter point, most people won't have a hundred apps in fact 10 will probably be the most. But think about this even now most people would not consider their mouse arrow an application, but yet things like comet cursor do exist and what is to say they won't charge you a buck or two a month. Games are another cash cow, my daughter alone has 10 or more that she uses. I myself have 30 distinct "vendor" apps on my desktop. In my company we have 400 hundred developer groups with 7-8 people each. That same figure above translates to $15,360,000 a year. But in this case these are normal costs. In fact my company probably spent way more than that. Probably 10 times that. But again the cost of an app in this case would probably be higher for the more sophisticated applications even from an ASP.


PROS:


1. Security - for the end user this is not so much of a big deal especially given the fact that it would take years for a hacker to crack 128bit SSL encryption. Yes I do know about a project that did occur on the internet to crack the 32 or 64 bit encryption scheme. But by increasing the number of bits makes it that much tougher. Only countries or large could afford the time or money.


2. Latency - it was said a long time that the fear was that internet traffic would soon clog when more and more people got on line. But in fact the opposite has happened, the speed of the internet has literally increased 12% a year. Because companies are always improving the network, applications, etc...


3. Data Lock in - With XML, we should see things open up even more for B2B. And if you do know XML learn it. It's the future.


4. Performance - see 2 above.


5. Availability - moot point when one is on a pc at work since multiple routers will exist to the ASP. See number 2. Also when was the last anyone has had a phone outage. In this case two things could go wrong, user error or congested ISP. To slow for you then move to dsl. You can get that for $20 in my area QWest.


6. Privacy - Government is cracking down this issue. In fact acts of stealing personas or credits cards happens as much or more outside the internet. There things more likely to happen to an individual today as there was yesterday.


7. Cost - this is most arguably the hardest to swallow. For companies this may make sense since desktop refreshes do have to occur and why not through the mechanism of the internet. For end users this does not make sense. In fact I have not replaced the 10 games that my daughter has in 2 years. I spend far less money doing it that way then any other way. Now that is not that I don't download the free stuff. In fact I do. Whatever software I do buy would have to on average be less than $1 a month for me to be able to justify it with myself or my family. I fact my wife would have a coniption spending $3 on one app. Mind you, I have more than one PC at home with different apps on each one. In fact I probably hit 100 distinct vendor apps on two PC's.


8. Much of the ASP solutions are already happening and have been happening for about 5 years. So what's with the new sticker. It's like any thing with e in it's name was popular. Now it seems to be anything with "my".


Nough said. Now you draw your own conclusions

29 Aug 2000 11:00 Avatar cyh

Agreed!
I agree with you perfectly, s4. Can you imagine someone who has only heard of ASPs recently and suddenly reads an article like this? You'd think that all ASPs are crooks and that ASP technology is doomed. It's just too Naderish. You can't judge all ASPs like that. Mr. Reiber, you still haven't answered my question: "What other ASP have you used before besides Yahoo!?". Mind you that I don't even consider Yahoo! as a real ASP.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.