« October 2004 | Main | December 2004 »

November 30, 2004

Discriminatory holiday shipping

I was shopping for my clients at the Harry and David website and noticed that they were willing to deliver an order on Christmas Day (a Saturday at that) for no extra charge, yet there was a $9.95 premium for delivery during Hanukkah. Talk about politically incorrect!

10:15 PM | Permalink | Comments (0)

November 03, 2004

Amazon delves into application infrastructure

I had to do a double-take this afternoon when I got an email from Amazon regarding their new Simple Queue Service. So, everyone's favorite [book/everything else under the sun] seller is now trying to pass itself off as an application infrastructure provider? Something just doesn't sound right about that.

My first concern is that they have the word "simple" in the service name. Although an obvious reference to the ease in which the service can purportedly be consumed, one has to wonder why Amazon would want to get themselves into the same word semantic boat that Microsoft is in (Visual "Basic" anyone?). Second, Amazon appears to violate (in my mind, anyway) the whole concept of a queue. With a queue (as I have always understood), you add items to a list, then extract them in the exact same order that you added them; Yet Amazon states that "data is returned in roughly the same order it was added to the queue." Further down in the spec document, it states that a "message may be returned by Read even though it has already been dequeued; and concurrent Read calls may return the same message to multiple readers." Hmm. Despite Amazon's advice that I make my application idempotent (a new word for me), my confidence continues to wane, but let's move on.

Third, data entries are limited to 4kb in size. While I can appreciate this limitation (these are supposed to be just messages, after all), I can imagine the .NET crowd trying to pass serialized DataSet objects via this service. Given the verbosity of DataSets, you won't get much accomplished with a 4kb per message limitation. Fourth, under the terms of the beta, all you need is an Amazon Web Services (AWS) Subscription ID and a queue identifier to manipulate a queue. There is no word on what security model will be implemented (if any) in the final product, which stymies any non-hobbyist implementation.

Speaking of security, I don't see how any company is going to be willing to trust Amazon with their private or secure information. In the case of medical applications (my company's specialty of late), HIPAA restrictions would downright prevent it. I don't see how applications dealing with financial or other secure transactions would jump on this bandwagon either. Even if the trust factor could be surmounted, doesn't it make more sense to just implement Microsoft Message Queue (or whatever queueing application fits your style, technology and budget)?

All of this begs the question: "Who in the hell is actually going to use this service?" I imagine the hobbyist crowd might dive right in, but even they might be scared off by the fact that Amazon has clearly stated that it doesn't plan on offering SQS for free indefinitely; And, of course, their definition of "a very reasonable price" may differ substantially from yours and mine.

All told, I commend Amazon for at least making an attempt at getting into the "software as a service" space in the public sector. Lord knows, hardly anybody else has. While Service Oriented Architecture (SOA) is on the brink of going mainstream in closed systems (with the help of upcoming technologies such as Indigo), it is pretty much DOA with regard to services that are offered to the public (either for free or for a fee). The free services are mostly limited and/or dumb, and the cool services (such as Microsoft's MapPoint Web Service) are just too expensive for any project that isn't extremely well funded.

But that's just the way I see it.

09:47 PM | Permalink | Comments (2)