vicidial.org

Using Amazon RDS for the sql database of vicidial could allow for a click of a button scalability for call centers that have large demands such as thousands of calls at a time, as the database is the only segment of the vicidial deployment that can't be clustered to increase power deploying to something like Amazon RDS would enable a user to scale drastically as their system demands it. The struggle would be finding geographically advantaged data centers close to the RDS location, but once that's completed you could deploy multiple asterisk servers on dedicated servers as these don't work well in a virtualized environment due to CPU timing. once that task is completed theoretically your only limitation would be how many asterisk / web servers you can afford. you would be looking at 32 cores 244gigs of ram 2 x 320 SSD's as the back end to RDS. The only problems that i could contemplate with this setup would be the I/O limitations of the SSD's which theoretically we could resolve by using Ram Drives even though this wouldn't be ideal in a dedicated server environment in which the server could suffer from an unplug etc running SQL on a ram drive would be the highest performance option possible.

A self hosted option similar to this would be deploying your own openstack deployment in which you use block storage for data agility for the database.


if we normalized this for most business operations a database server that costs 7 / hour on demand would be 56 per day on a generalized 20 work days in a month that would put your database server costs at 1,120 dollars a month but since your database server could theoretically handle as much as you can throw at it would make sense for large call center deployments.


Thoughts?

Amazon systems would be viable ... BUT: (Notice that the But got Bigger due to the Caps).

DB communications with the Dialers must be instantaneous. Power alone won't do the deal, the delay between the DB and the Dialers must be minimized. In present installations, the DB must be in the same physical location as the dialers or DB communications are not fast enough to support high-volume systems while remaining stable.

It would be fairly simple to get a cluster up in an Amazon based system just like any other colocation configuration: Power up dedicated servers and apply the appropriate images IF they can share a low-latency internal communication network for DB operations. Usually this is just managed via single (dedicated) servers in Amazon just like any other colocation facility (Rackspace ... anywhere). If you break the DB up into "logical" servers in any fashion, you risk adding latency and breaking down the system. And you can not use a mysql cluster as individual nodes must await updates which requires time and Vicidial has NO patience for such delays.

Also: This sort of scalability is useful only for systems that exceed 150 agents. Presently, up to 150 agents can be managed in an Eight server cluster of physical servers located locally or in the cloud. So building a whole new scenario for that 150 agents would be ... pointless. If you could build a system capable of pushing past that limit, however, that could be interesting.

Managing more than 1500 calls and 150 agents is when things begin to get complex. And by 150 agents, I mean with predictive autodial and a fairly high call-ratio (ie: 1500 calls in progress). At that point, if you can reliably scale it to double the capacity (300 agents, 2500-3000 calls) and then scale it back down to 150 agents/1500 calls easily while ONLY paying for what you use, it could be useful.

Challenge: Anyone building a system of that scale usually also wants superior control and handling which is presently achieved by having physical control of the servers personally OR in a colocation facility with Vicidial Experience. So getting someone to let you "Play" who happens to have 150 agents (and occasionally 300?) is not exactly an easy task.

PS: When we've run our pricing scenarios for the necessary Amazon configuration to run a Vicidial Cluster ... we've actually found NO cost benefit without the ability to scale up to 300 and back down to 150 "at will". And even then, the benefit comes from scalability. The system is not less expensive at either size: Benefit comes from being able to drop back to tiny and jump up to huge thus not paying monthly for a system, but hourly. But it's rare to find a facility that needs to scale that much from day to day or week to week. Usually the scaling happens over several months and that tends to coincide nicely with colocated physical servers which are leased ... Monthly. *)

Ignoring the many issues with using the Amazon cloud, we've found very few client scenarios where that is beneficial. In fact, we had a small client who was on an Amazon-hosted system move to Vicihost and their server costs are less than half of what they were on their Amazon hosted vicidial system.

Primary problem: To get "good pricing" in the Amazon Cloud, you must reserve in advance and essentially commit to something akin to monthly service. But that good pricing is not as good as the same hardware for simple Colocation elsewhere. Amazon is geared for 'shared' services which Vicidial does not support by its nature, once you step outside that zone ... good pricing is not why you're there. But if you only use your system for a few hours a month ... that's a different story. You're paying for the ability to automate the "bring it up, shut it down" features. But you still have to build that automation for it to be of any true value. IE: It is possible to build a system that will spin up servers as you need them, and shut them down when you're done. And balance the load across the newly spun up servers at they come online, plus shutting down all but the "control" server when it's all over. Who needs this? *) Only someone who has a huge need for a system, but only for a very little amount of time. I don't know of any shops who run for a few hours every now and then with lots of agents.

In the end, we've not had a single client who actually ran with Amazon. We've had several who have gone to (and come to us from ...) other major Colocation facilities ... using dedicated servers just like we have. Usually the concern is the ability to run a multi-million (monthly) dollar business in a secure environment with hardware-based VPN and direct, dedicated data links to the carrier (a real carrier, not an aggragator). In these scenarios, we've found that the overreaching reasoning to go "cloud" has been a deep need for "24/7" "every minute" uptime. NO downtime, NO security risks as defined by whatever the CTO's college taught him was "Best Practices".

Funny thing that: There's still downtime ... and they still call *us* when it happens to find out what's wrong and who to call to fix it. Carrier down? Can't fix that, so let's call the carrier. VPN router died? Call the colo, and they'll bring out the crash cart and put a new one online and configure it. Then we stay on the phone with the NOC or the Carrier while they "work it out".

Of course, in our shop (as with Vicihost and any other colo), we have a server watch system online and no one has to call to get hardware repaired. A red light appears on our panel, an email (and/or a text message, depending on the situation) is generated to the duty technician. If they do call to find out what's broken, usually it results in our duty technician saying something like "Your network switch died, new one should be online any second now" or my personal favorite "you didn't pay your carrier, they shut you off ... you should probably log in and put some money on that account". LOL