Without warning and without contacting us first, Digital Ocean blocked public IP access to one of our critical production servers on a Friday evening on the basis of a third-party security firm reporting to them that we were hosting a phishing page. We were, in fact, not hosting a phishing page. If DO had done minimal due diligence before blocking us they could have confirmed this. However, it took until the next Monday before DO support responded to our explanations that the phishing report was a false positive and unblocked our IP.
Yes, I second this. It was a nightmare for me. They brought down the droplet and the recourse was that I had to create a support ticket. It was weekend and they took more than 24 hours to answer.
Until then, my site was down with customers complaining to me.
We ended up launching another droplet, setting up a reverse proxy from the new droplet to the blocked droplet (which was still accessible via internal IP), and updating DNS to point to the new droplet's public IP. At least that way we were not down all weekend. Nevertheless, we decided that DO support's kill-first-ask-questions-later policy was completely unacceptable.
You didn't have a disaster recovery plan in place to spin up new critical production environments in the event of an outage impacting external network accessibility? This is on you as an Ops team, not really something to blame DigitalOcean for.
AWS will expect you to do the same thing but it'll be much harder just because it's AWS.
We did have a disaster recovery plan in place, and we implemented it.
It is my opinion that killing public access to a paying customer's server without talking to them first, and not providing any remedy for 60+ hours, is definitely something that DO support deserves blame for.
from the other reply it sounds like you made up your disaster recovery scenario on the fly.
DigitalOcean (and a lot of IaaS providers like them) expect you to create new servers on demand because the underlying hosts aren't 100% reliable. It could have been a RAID failure or a bad PDU feeding a rack or a number of other scenarios that would have taken your droplet offline, not just an abuse ticket.
Can I just say that the "relationship" theme of this article comes off as a tad ... creepy? Completely detracts from the substantive content.
>many years ago when we both were young. It was love at first sight – The elegant UI, the ease of use, the dirt-cheap price was everything I was looking for in a partner.
>There was no downtime, highly reliable as a partner and supported me with every problem I faced in life.
>I understood how to work with her and things to expect from her. Never before had she let me down. It was smooth sailing until recently when problems in our relationship started to surface. She expected more from me and wanted to change me.
I completely agree, this comes off as a highly sexist narrative where the expectation of a female partner is to be nothing but supportive and existing purely for the male counterpart.
I expected billing problems, or maybe reliability problems, or maybe horrible support... but the reasons turned out to be: "would not let me assign a floating IP to her load balancer." and "does not have integrated DDoS protection"
Someone really had pampered life -- this does not look like core functionality at all. I'd expect any service to have limitations like those.
That's a pretty... bizarre set of things to whine about.
If you want to grumble about DO for stuff, their absolutely scattered performance on lower end instances is a better one, though for how cheap the bandwidth is, it can be made to work. And when things like CloudFlare exist, I can't fault DO for not duplicating that sort of behavior.
I am the author here. Let me give you more context on this.
1. My Saas platform supports custom domains including naked domains and not just subdomains so it is important for me that the IP address remains the same when I add more capacity. I am running a single large droplet as of now and when I tried to add more instance + LB, DO wouldn't let me do that. Several people have asked this feature if you look in their forums. Unless I run and manage my own Haproxy/Nginx boxes, I cannot scale up.
2. This is currently a side project and I do not have additional time to maintain more resources which is why I am willing to spend more on a platform that provides me these features. This is not due to laziness as some people have commented.
Sometimes when you look back, you'll appreciate that someone a bit more. You'll realize despite the flaws she wasn't so bad.
If the author is look for more affection, I don't think AWS is the route to go. I'd go the other way toward Heroku-like platform. (Oh and shout out to Python Anywhere - great relationship there)
We moved to AWS.