Showing posts with label amazon turks. Show all posts
Showing posts with label amazon turks. Show all posts

Tuesday, April 17, 2007

Thank you!


Thank you to everyone who attended my session today at the Web 2.0 expo. I hope you enjoyed it as much as I did - I am always amazed at how amazing the things you do are.

A few people asked me for the slides, and I have uploaded them on SlideShare here. Jack Ivers was also so nice as to record the podcast, and I'll put a link to that on the site as well when I get it.

Again, thank you!

Wednesday, March 07, 2007

Amazon Web Services in Telephony

With all this talk about Amazon Turks, I wanted to push another idea out there which I think is just as important : EC2 and S3.

EC2 stands for the "Elastic Computing Cloud", which is Amazon's rent-a-server service. Need a server for an hour? Rent it for an hour. You package your standard web-like program in their image, upload it, and off you go. Need a thousand servers right now? Go get them. Not now? Get rid of them. I remember a few years ago I worked on this application for a "get out the vote" effort in Utah, where we had crazy traffic, but only for a few days.

S3 is the same sort of deal for storage. Need storage, go get it. It's fairly inexpensive too. This is a pretty interesting thing for a different reason: cash flow. As a service provider, you don't need to scale your resources until you scale your business. From a technical standpoint, nothing changes. All good.

Does the name Erlang ring a bell? If you happen to be a telephone engineer, it should. Mr. Erlang figured out how many telephone lines you needed to handle the traffic from a set of subscribers. For instance, everyone doesn't pick up the phone at the same time in a town and talk at once. On average, maybe one in a hundred people are using the phone at any one time. To be safe, telephone switches are typically setup to handle ten times that amount, just in case everyone decides to let their fingers to the walking. In Israel, they call it a "Scud Event". When a Scud missile flies across the country, all the grandmothers call to make sure everyone's OK. So, you actually have about ten times more hardware than what you would typically use, just in case somebody decides to start a war, or the equivalent.

How does this apply? Well, consider EC2. If you could deploy servers "on demand", then you could ramp up capacity when you needed it. You might think that it takes longer than a few seconds to deploy a server, and it does need a little more time than that, but peak usage actually grows rather slowly on the phone system, as the growth comes not only from new calls, but longer ones. The impact? One tenth the amount of hardware? Not bad.

Doesn't stop there. A big thing in telephony is resilience, which typically means redundant hardware. (Note to self : this is the wrong time to get on a soap box about how idiotic it is that telephony guys are always fighting a fragile network through making each element stronger instead of making the system stronger. They never watched that Borg episode in Star Trek, apparently.) If you could ramp up other servers, you could radically increase reliability at a lower cost. In this, don't let your head stop at failure of hardware, keep it moving to think about distributed denial of service attacks, or military applications. For this, EC2 and S3 shines.

Web 2.0 Expo, here I come!


In a surprising lack of judgement, the nice folks at O'Reilly have asked me to join them in San Francisco from April 15th to April 19th to handle a session called "Writing Voice Mashups with Mechanical Turks and Maps". Brady Forrest asked me if I would extend the nurse's interface so to include geo-location and maps, and since I've been really fascinated with Wheel of Food, I couldn't resist.

Here's the abstract :
A few short years ago, communications applications required millions of dollars, teams of highly skilled engineers, access to networks and many months of time. Telephony Mashups rewrite that equation, and make it possible to blend communications services into applications quickly and easily.

In this workshop, led by 2007 O'Reilly Mashup Winner Thomas Howe, we look at how these mashups are created, and at the implementation details in depth. Using After Hours Doctor's Office as an example, every part of the mashup will be reviewed in code-level detail, including a Voice XML front end, the software interfaces to the Amazon Mechanical Turk nurses, and mapping displays to help direct the patient to a local health care facility. The attendees will leave with a good understanding of the technology and effort required to write their own compelling application.

Thursday, January 25, 2007

A sick thought...

I just had a sick thought.

I'm presenting tomorrow in the "VoIP Spam : Challenges and Solutions" panel, which means (of course) I'm writing it now. The other distinguished members of the panel appear are vendors, so my supposition is that they are selling solutions. Since I'm not a vendor, I'm writing about challenges. So, here I am thinking about VoIP Spam challenges, and I had a sick thought.

I remember hearing once that, after years of building SPAM filters for e-mail, a very effective method of determining SPAM was simply looking at people reporting SPAM from their inbox. If a bunch of people reported an e-mail as SPAM.... it was probably SPAM. Of course, this makes some sense.

Forget that approach for a second, and you are only using SPAM filters. Imagine that, to increase the chances of getting through the filter, you just changed spelling and smaller parts of the text. That would help get the SPAM through, but in general, there are only so many permutations because you are dealing with a fairly small field of possibilities, and in the end, you still had to have some sort of HTML link in there, and how much could you vary that?

My sick thought was that, with voice, I can vary it nearly infinitely such that it would be impossible from simple correlations to determine if two voice messages were the same. As a human being, I would hear them as the same message. As a computer, forget it. And even if the computers got better at correlations, I would simply need to add more noise to the message, knowing that human ears are really good at picking out the voice from the noise. Any Aerosmith fan will tell you that. This is really hard stuff. That takes away a very powerful tool that we have with e-mail SPAM.

On the good side, I have a brand new application for Amazon Turks! You could pipe all your voice mails through a real person who would throw away that voice SPAM. Don't laugh - it might be what this all comes to.