4 ms·

And this is why I don't rely on cloud services for mission critical applications.

hdjjhhvvhga 4y ago
It doesn't matter if it happens or not. What matters if they manage to recover and how long it takes. Based on that information you can make meaningful decisions regarding the risk. I can't imagine I'd put all eggs into one basket these days.
leros 4y ago
I think about it exactly the opposite. I'd rather have a team of engineers at Elastic waking up at 3am and fixing things than me having to wake up and fix things by myself. My most critical infrastructure for my one-man SAAS is all third party infrastructure run by large companies. My non-critical infrastructure is self managed for cost savings.
abujazar 4y ago
So I guess my comment is getting downvoted by people who don't understand «mission critical». >how can you run mission critical if most cloud services have SLAs two or three nines weaker than needed That's exactly it. Cloud providers usually provide SLAs in the range of 95-99%. Amazon doesn't provide a full refund until monthly uptime goes below 95 %. Elastic apparently doesn't provide an uptime guarantee at all, they only provide an SLA for support ticket response times. And only on gold and platinum subscriptions. This incident lasted for more than 24 hours («most» instances restored after 22 hours). It doesn't matter if it's someone else that has to wake up at 3 am to fix the issue, when they're unable to fix it within reasonable time. Mission critical apps simply can't be down for 24 hours. And it's fully possible to design HA elasticsearch deployments. Elastic Cloud just isn't one of them.
aenis 4y ago
Sadly, doing things in house is not inherently safer. Same type of people designing same type of processes. But yeah, how can you run mission critical if most cloud services have SLAs two or three nines weaker than needed?
LastTrain 4y ago
I don’t know, if they are able to recover the deleted clusters I would consider this a qualified success.

It doesn't matter if it happens or not. What matters if they manage to recover and how long it takes. Based on that information you can make meaningful decisions regarding the risk. I can't imagine I'd put all eggs into one basket these days.

leros 4y ago

I think about it exactly the opposite. I'd rather have a team of engineers at Elastic waking up at 3am and fixing things than me having to wake up and fix things by myself. My most critical infrastructure for my one-man SAAS is all third party infrastructure run by large companies. My non-critical infrastructure is self managed for cost savings.

abujazar 4y ago

So I guess my comment is getting downvoted by people who don't understand «mission critical». >how can you run mission critical if most cloud services have SLAs two or three nines weaker than needed That's exactly it. Cloud providers usually provide SLAs in the range of 95-99%. Amazon doesn't provide a full refund until monthly uptime goes below 95 %. Elastic apparently doesn't provide an uptime guarantee at all, they only provide an SLA for support ticket response times. And only on gold and platinum subscriptions. This incident lasted for more than 24 hours («most» instances restored after 22 hours). It doesn't matter if it's someone else that has to wake up at 3 am to fix the issue, when they're unable to fix it within reasonable time. Mission critical apps simply can't be down for 24 hours. And it's fully possible to design HA elasticsearch deployments. Elastic Cloud just isn't one of them.

aenis 4y ago

Sadly, doing things in house is not inherently safer. Same type of people designing same type of processes. But yeah, how can you run mission critical if most cloud services have SLAs two or three nines weaker than needed?

LastTrain 4y ago

I don’t know, if they are able to recover the deleted clusters I would consider this a qualified success.