It should not be understated how bad this is. Your #1 expectation as a cloud database provider is to keep data safe and recoverable. I hope for at least their sake they took a backup of everyone's DB that could be restored in another region, but based on the fact that they didn't do a scream test, I doubt they thought about this either. This must have been forced upon by upper management, because there is no way some…
InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
231–240 of 278 posts
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#232Earlier quoted context omitted.
In case anyone else is wondering: > The Scream Test is simple – remove it and wait for the screams. If someone screams, put it back. The Scream Test can be applied to any product, service or capability – particularly when there is poor ownership or understanding of it’s importance. https://www.v-wiki.net/scream-test-meaning/
Maybe this is the scream test…just done badly
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#233Earlier quoted context omitted.
You know, I don't really care that mortgages get sold, but the fact that I need to go out of my way every time to make sure I update my information in their system is astounding.
Technically that shouldn't even be your problem.
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#234Earlier quoted context omitted.
You worded that better than I could have. I ignore most of my vendor's emails because they're simply trying to spam me at this point.
I was also thinking that salesmen will cold-call/email me at least three times before they give up. People with whom I have no business relationship try harder than a corporation taking someone's money.
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#235Earlier quoted context omitted.
> we made our best efforts to notify affected users You call three emails (the last of which was almost 2 months ago) "best efforts"? I had to read your message three times because this is so reality-defying preposterous I just couldn't believe I didn't miss anything. How about warnings on the dashboard? How about an intentional error (or limited service interruption) so that people would log in to their dashboard?
> How about warnings on the dashboard? They did have a warning on the dashboard, problem is a lot of people don't check the dashboard because they don't need to, as they just view everything through grafana, etc. They also had a notice on the status page
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#236Earlier quoted context omitted.
If it's backwards compatible why would they bump the major version? Either there should have been a breaking change in there or they don't understand symantic versioning
Not sure why the downvotes here, a database service misusing semantic version is itself a red flag in my opinion. If major releases don't indicate a breaking change I'm not as confident in what might be part of a minor or patch release.
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#237Earlier quoted context omitted.
I even (sort of) do this when I'm deprecating something which my team is the only user of, because sometimes it's hard to tell if something's really unused! First shut off the VPC access while leaving all the other infrastructure and data intact, wait a week or two and see if everything breaks, then get rid of everything else
There is another variant of this: if you can show that the code you are deleting never worked, there is no need to do a scream test. That is, if anyone cared about the code you are deleting, they would have already been screaming.
To use an ecosystem analogy, once you expose your software to the world beyond your own dev environment, even internally, you'll eventually find that something colonized it - much like everything on this planet that isn't being actively and regularly scrubbed.
In my own career, I've seen cases of this. For example, once we were tweaking a little embedded database that supported a half-finished feature meant for internal use, and only then we (as in everyone in the dev team) learned that somehow, the QA & deployment support people got wind of it, and were scripting against exposed parts of that DB for a good year. And, it turns out, it wasn't the only part of the software that we thought of as incidental phenotype (or didn't think of at all), and the other team considered stable behavior.
See also the so-called Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody."
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#238Earlier quoted context omitted.
When ovh sunsetted a class of VPSen and I'd completely failed to notice they were going to do that, I asked nicely in the support ticket I'd sent in and they turned it back on for a few days while I shifted the data to a replacement (which was still an ovh VPS, it had been Just Working long enough that I didn't feel like I'd been mistreated, more lulled into complacency by the lack of problems). I think requiring a t…
I mean this is why you do these projects on two different timelines: The internal timeline and the external timeline. Externally you communication: Different announcements each month, final notices at T+5M, System will be deleted at T+6M, data will be lost at that point and so on. Internally (at least at work) such a timeline is more that at T+6M, we cut access to the systems. Afterwards, systems not accessed for 2-4…
Agree absolutely wrt complacency, I believe I asked for less than a week because I actively preferred a situation where I had to get on it immediately.
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#239It seems this probably happened due to some regulation or other. The sunset date for the service should have been a month prior so that influx could have kept the data legally until the 30th in case of this situation happening. They wanted to have the euros flowing in right until the last minute. 1. Flash messages on all user facing consoles. 2. No new resource able to be created for 6 mo this. 3. Emails. 4. Service…
It's a cost-cutting measure that reeks of a company trying to cut costs as fast as possible.
A scream test would have been a better option in addition to the above.
Re: InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion
#240Hi, cofounder and CTO here. We notified everyone via email on February 23, April 6 and May 15th. We also offered to help migrate all users. I realize that it's not ideal that we've shut down this system, but we made our best efforts to notify affected users and give them options to move over to other regions. If you've been impacted by this, please email me personally and I will do my best to help out: paul at influx…
My opinion on best effort: I founded, ran, and sold a SaaS company used by some of the most well known companies in the world. Our "best effort" was a minimum of 12 months notice, with a six month grace period afterwards. Emails weekly. Phone calls at least once a month. Reach out to customer leadership if no response. Then scream test as others suggested.