[hydra-dev] Still confused, but at a higher level

[Kevin P. Fleming]

Olle E. Johansson wrote:

> 12 apr 2010 kl. 17.01 skrev Tim Panton:
>> No. (In my not so humble opinion)
>> Hydra is a Cloud telephony engine. Asterisk isn't. 
>> Hydra will work on private clouds and clusters, it may work on a single box as Asterisk does, but I
>> don't think that use-case will be interesting or valuable in 5 years time.
>>
>> Perversely Hydra components may actually run on _smaller_ devices than Asterisk does - like iphones or pogo plugs, but those 
>> devices will depend on the rest of their Hydra buddies out in the cloud.
> 
> Now you're defining something that's separate from Asterisk, which I haven't seen earlier. Good. We're getting somewhere.

This is what we talked about in the meeting; in my mind there are at
least two core, fundamental problems that Hydra is intended to solve
that Asterisk cannot, at least not without being changed so dramatically
that it is no longer Asterisk at all.

The first, as Tim mentioned above, is whatever term you want to use for
'scalability' and 'fault tolerance'. Our goal is nothing short of
infinite horizontal scalability, with the barest minimum of effort
required on the admin's part to add and remove capacity when necessary.
The work required to achieve this will naturally also dovetail nicely
into a very fault tolerant platform, which is why we think it's most
effective to concentrate on building components that can provide
failover for each other (as opposed to full N+1 redundancy and load
sharing), because the cost of additional computing resources to hold a
component are dropping so fast that there's not any particular reason
that you need to have excess resources just sitting around waiting for
the work to come to them. If we can achieve nearly seamless mid-call
failover, only the smallest percentage of possible installations would
really be able to demonstrate why that's not adequate... and there's
nothing to say that the platform we want to build can't move in that
direction if the effort can be justified.

The second major problem is that of APIs (programmer access,
extensibility, pick your name). When we look at platforms that are being
developed already to provide application-level control of
telecommunications systems, we can see that Asterisk's design is lacking
in having a comprehensive, organized and (most of all) stable API for
the operations that many app developers need. If you look deeper,
though, there is an even greater need to provide stable, documented
interfaces at many levels throughout the system, and to provide
mechanisms that allow entire components to be replaced (or proxied) when
the situation warrants it. This demands that the *entire* system, from
the ground up, be designed that way from the beginning; it can't be
added on later, because it will never be comprehensive enough nor stable
enough to achieve these goals. Even it can be 'bolted on', providing
APIs that can be used natively by developers in a half-dozen programming
languages, across platforms as diverse as Android, Silverlight, iPhone
OS, and Windows, (although Tim has pointed out that the Java mapping may
not be what an experienced Java developer would want to see... but that
can be addressed outside of Hydra itself) is an enormous task.

As I said in the meetings here in Huntsville, some of the other problem
areas that we want to address with Hydra *could* be addressed with
Asterisk, although they'd require a substantial effort on many fronts
and the likelihood of introducing instability into Asterisk is quite
high. Part of our discussions also revolved around whether it was
reasonable to attempt to attack only the problem areas that could be
addressed without fundamental redesign work, and in the end we decided
that it wasn't the best use of our resources, because the time and
effort required would not provide enough 'return': the resulting product
would not be far enough ahead of Asterisk and its current competitors to
warrant the cost of doing that work. If we use those resources instead
to build a platform that is based on 2010-era tools, the same man-hours
can achieve vastly superior results. This is what ended up being the
primary factor in the decision to start looking into whether Hydra was
feasible or not; it won't surprise anyone that it was a cost-benefit
analysis, but a large part of the 'benefit' side of the equation was the
desire to improve the tools available to our ecosystem so that they can
continue to build cutting-edge systems that provide what their customers
need, even five (or ten!) years from now.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org