Ditto. It happens with physical servers too. If you can't survive unscheduled degradation or termination of a node, you aren't running a high availability service. (Note: not every production service needs to be HA.)
I agree. When you don't run your servers yourself it should be a calculated risk that sometimes your server goes down. Of course, if this happens quite often, you should considering going to another hoster, but it can't be guaranteed that one server has 100% uptime with perfect recovery.
If the website of one of my clients goes down, it's not a disaster and it's fine when it's up and running again in a few hours, maybe a day.
I understand it's not nice when this happens, but it's the risk you take with essentially outsourcing your hosting.
AWS generally, although not always, shows an alert before this happens.
However, I totally agree - if you are running any sort of service where you have a financial penalty if that service goes down, then it's your responsibility to ensure your service's architecture supports catastrophic failure of nodes. 1 machine running all the things isn't high availability and shouldn't be sold as such.
I do agree, We do setup for HA, but due to some bugs on our end, the cut over from our DB Slave to Master didn't happen. Will be more careful next time.
That's interesting. So, from that, the thing that stops DO being a cloud service (and linode and so on) is that you can't say "I used 2 CPUs at 100% for 12 hours"? It only allows for the granularity of saying "the node was on for 12 hours"?