Is Digitalocean a good platform to start deploying a VOIP service?

April 2, 2018 184 views

I would like to make a conference focused VOIP service that can be utilised similar to IRC where the clients are native android and iOS apps. People, like with IRC, would be able to connect even with minimum registration. Perhaps as guests with simply one click.

I am thinking of using -all for the backend- Kazoo, kamailio, and freeswitch along with erlang, packer, docker, riak, apache cassandra, and postgresql. The idea is to have it easily scalable -even beyond cloud services such as digitalocean, if it can be used-, automated, and distributed.

Is digitalocean a good platform to start out to get this service out there?

3 Answers

If you're going to be providing a service that will be used by customers I would strongly suggest you look at how they handled the latest outage in FRA1. Servers and storage inaccessible for almost 48 hours and nothing but "sorry for the inconvenience" messages for most of that time.

Digital Ocean platform is great and works very well for VoIP but their ability to deal with a crisis leads a lot to be desired.

  • We're very sorry you feel that way. During an outage or incident such as the one you've mentioned our primary goal is to restore services and provide whatever support the engineering teams involved require to do so as quickly as possible.

    Internally we coordinate between our engineers, communications and support organizations in order to provide regular updates. When composing these updates one factor that comes into play is that every minute that an engineer who is actively involved in our response is working with support and communications to provide status updates to our users is a minute that that person is not actively working to solve the problem.

    Despite this we do maintain communication with the teams working on the issue in order to provide regular status updates. Status updates on an issue will not be an exhaustive detail oriented overview of the issue and steps currently being undertaken but are designed to let users know the status of an issue and that work is progressing.

    We understand the need to have a deeper understanding of what caused an outage or issue which is why it is our policy, after services have been restored, to work with the engineering or infrastructure teams who were involved in our response in order to provide a detailed post-mortem that outlines the issues encountered and our response. Because this is a detail oriented technical document it is not provided instantly but we aim to share full details within a few days of any major incident and have done so in the past.

    We are always looking for ways to improve our services and our response when issues occur and would love to hear any suggestions or ideas you may have on how we can improve in the future.

  • You are right, yet you as the developer of your application should be aware of these situations (even Amazon was down for a full day one time), and develop redundantly. meaning you should have replicas of your systems on other DO zones and/or even on other providers. I don't think that discouraging someone to use a service just because "s#!t happens" is a good idea, a better idea would be to encourage him to do so but to be fully aware that "s#!t happens" and you need to be ready when happens.

    --Just my two cents.
    best regards!


Have another answer? Share your knowledge.