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

Posted April 2, 2018 5.7k 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?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
2 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.

    • DO should work really hard on ticket response time. It is really pathetic. You guys should see how many people just complaining the time you take to respond to tickets. over 48 hours !!! Do you think this kind of outage is possible for anyone who is running production website on your droplets.

      You guys should increase the price of each droplet by a dollar and keep a live chat support system. I believe people here who are paying 10 dollar a month for a VM will not have any issue to pay 11 or 12 dollars if you provide quick and accurate support to those facing issues in their droplets.

      My droplet is down for over three hours now and there is no reply to ticket. Can you think your own droplet where you host your own DO website down for over three hours ????

  • 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!