[asterisk-biz] The newest buzz word - cloud computing

[Troy Davis]

(Disclaimer: I run Cloudvox and I'm biased.  I'm also transparent, my
biases are logical, and I deal with this stuff every day.)

> I did lot of research on this subject.
>
> - Call recordings etc. will have latency and it will be not
> manageable. You call records should first be stored internally and
> then written out to S3 block. S3 block can be anywhere - west or east
> and you will notice call degradation.

Hi Praveen,

I think between Pascal's email and your reply, the term "cloud
computing" was transformed into "Amazon EC2."  Your reply raises
performance considerations specific to Amazon Web Services (some of
which I believe are not practical concerns, which I'll address below).

This is one of the biggest problems we encounter: one person will
mention "cloud computing," and someone else will interpret that as
"The cloud platform(s) that I've had experience with" (usually EC2)
and evaluate it accordingly.

Some cloud-scale services use EC2 or other parts of the AWS stack,
like S3 (file-based storage) or Cloudfront (content delivery).  Some
don't touch AWS anywhere and are based on rented or colo'ed servers,
or an internal datacenter.  Most are hybrids.

I cringe when someone mentions EC2, Google AppEngine, and Rackspace
Cloud or Engine Yard in the same sentence as if they're
interchangeable equivalents (not at all) or even competitors (barely).

If there's one thing to take away from this thread, it's that "cloud
services" are more different than alike.  There are very few
statements - about intended purpose, performance, reliability, or
complexity - that hold true for all cloud services, and that's even
more true of cloud telephony services.

> - Voicemail is ok on S3
>
> - EC2 does not have any ETA and they really do not concentrate much on
> jitter and latency.
>
> - The major bottleneck is Bandwidth in and out. If you are using G711
> - you will start burning yourself. If you have low volume - there is
> no point of using cloud.

While EC2 has performance and cost tradeoffs, I don't believe an
actual implementation would write raw call audio from EC2 to S3 in
realtime (without spooling locally).  EC2 instances have local disk
("ephemeral storage") and mounted quasi-SAN block storage (elastic
block storage or EBS) specifically to solve this problem.

I don't mean to say there aren't pros and cons to AWS, just that
compared to issues like fine-grained kernel timing under load, and
lack of control of the dom0 environment, these aren't huge issues (and
I say this as someone who does not base his business on AWS).

The second point you raise is:

> - Most of the APIs I have seen are jsut wrappers on Asteirsk AGI.
> Nothing else. Check out http://www.invox.com if you are seeking to
> build IVR components - just drag and drop. Click and click - your IVR
> is ready. 40-50 voice mashups out of box. Visual designer. Supports 40
> countries. Has inbuilt support for speech recognition, text to speech
> etc.

This is also a sweeping statement ("just wrappers on Asterisk AGI.
Nothing else"), rolled up into a self-serving paragraph.

If someone's looking for a drag-and-drop IVR authoring system, and
they're comfortable being dependent on the vendor who makes that GUI
environment, Invox might be a good fit (I've never used it).

But I don't think it's useful to knock a solution that meets the needs
of a huge number of people - AGI - to make your sales pitch.
Companies happily handle tens of thousands of calls per day with AGI,
probably hundreds of thousands: http://bit.ly/auPEMu

Trivializing AGI ignores LumenVox, Visual Dialplan, Cepstral,
Loquendo, Presence Technology, and others who have speech recognition,
TTS, visual dialplan, and ICD/queuing on top of Asterisk.

Maybe worse, it ignores the power of open-source libraries like
Adhearsion, Asterisk-Java, or asterisk-perl: they let the app
developer or entrepreneur hold the cards.  Create an Adhearsion or
PHPAGI app, and if your current app environment doesn't work, just
move.  If it doesn't have the features you want, ask, add it, pay
someone to add it, or move.

Controlling your own destiny is really powerful.  And in the right
hands, "just AGI" is ridiculously powerful.

I don't mean to knock using a GUI designer or a proprietary
environment, either.  That's the right solution for some people.  But
for companies with existing apps, or knowledge of PHP, Java, or
another language, they already have developers who understand how to
write and manage that app.  A GUI designer is not necessarily a
strength, especially when it means being locked into a single-vendor
solution.

It's not a case of your product versus "just AGI" - neither is right
for everyone.

> - G729 may have transcoding issues on cloud. Also, if you are using
> Speech recognition - G729 is no no.
>
> My 2 cents - cloud is not yet ready as they may have latency not
> covered in their SLA and they charge bandwidth in/out.

Sweeping statements like "cloud is not ready" simply lead to
confusion.  It's like saying "Some pizza has olives.  I don't eat
olives, so everyone needs to stop eating pizza, everywhere."

I'd encourage folks to do some homework, ask, and ultimately, test for
yourself.  The capital cost is low enough to do that now, both for
cloud platforms and cloud telephony.

Troy

-- 
Cloudvox  --  http://cloudvox.com/
call your code: API-driven phone calls, in minutes
Ruby/Adhearsion, HTTP/JSON, PHP, Asterisk-Java, SIP, and more