Earlier quoted context omitted.
Years of serious corruption bugs.
Gluster was that for me
Yup, still get nightmares about glusterfs.... still have one customer running on it.
Healthchecks.io now uses self-hosted object storage
21–30 of 82 posts
Re: Healthchecks.io now uses self-hosted object storage
#22Earlier quoted context omitted.
Gluster was that for me
Yup, still get nightmares about glusterfs.... still have one customer running on it.
I heard it got better, but we ran into the BOTF (billions of tiny files) issue around 2016. (For a genealogy startup this was a serious issue)
Re: Healthchecks.io now uses self-hosted object storage
#23Re: Healthchecks.io now uses self-hosted object storage
#24Earlier quoted context omitted.
The S3 API doesn't work like normal filesystem APIs. Part of it is that it follows the object storage model, and part of it is just to lock people into AWS once they start working with it.
> part of it is just to lock people into AWS once they start working with it. This is some next-level conspiracy theory stuff. What exactly would the alternative have been in 2006? S3 is one of the most commonly implemented object storage APIs around, so if the goal is lock-in, they're really bad at it.
> What exactly would the alternative have been in 2006?
Well, WebDAV (Document Authoring and Versioning) had been around for 8 years when AWS decided they needed a custom API. And what service provider wasn't trying to lock you into a service by providing a custom API (especially pre-GPT) when one existed already? Assuming they made the choice for a business benefit doesn't require anything close to a conspiracy theory.
And it worked as a moat until other companies and open source projects started cloning the API. See also: Microsoft.
Re: Healthchecks.io now uses self-hosted object storage
#25I don't get it, if it's running on the same (mentioning "local") machine, why does it even need the S3 API? Could just be plain IO on the local drive(s)
The S3 API doesn't work like normal filesystem APIs. Part of it is that it follows the object storage model, and part of it is just to lock people into AWS once they start working with it.
Apart from all these other products that implement s3? MinIO, Ceph (RGW), Garage, SeaweedFS, Zenko CloudServer, OpenIO, LakeFS, Versity, Storj, Riak CS,
JuiceFS, Rustfs, s3proxy.
Re: Healthchecks.io now uses self-hosted object storage
#26I don't get it, if it's running on the same (mentioning "local") machine, why does it even need the S3 API? Could just be plain IO on the local drive(s)
If the app was written using the S3 API, it would be much faster/cheaper to migrate to a local system the provides the same API. Switching to local IO would mean (probably) rewriting a lot of code.
Re: Healthchecks.io now uses self-hosted object storage
#27I'm sure it's a lot better now but everytime I see btrfs I get PTSD.
Same here. Had a production node running btrfs under heavy write load (lots of small files, frequent creates) and spent two days debugging what turned out to be filesystem-level corruption. Switched to ext4 and never looked back. The article doesn't mention what filesystem sits under Versitygw here, which seems like a pretty relevant omission for anyone thinking of replicating the setup.
Re: Healthchecks.io now uses self-hosted object storage
#28I don't get it, if it's running on the same (mentioning "local") machine, why does it even need the S3 API? Could just be plain IO on the local drive(s)
(Author here) There are multiple web servers for redundancy (3 currently), and each needs access to all objects.
Re: Healthchecks.io now uses self-hosted object storage
#29I don't get it, if it's running on the same (mentioning "local") machine, why does it even need the S3 API? Could just be plain IO on the local drive(s)
(Author here) There are multiple web servers for redundancy (3 currently), and each needs access to all objects.
with average object size of 8.5kB I'd honestly consider storing it as blobs in cloud DB, with maybe some small per-server cache in front
Re: Healthchecks.io now uses self-hosted object storage
#30Earlier quoted context omitted.
> part of it is just to lock people into AWS once they start working with it. This is some next-level conspiracy theory stuff. What exactly would the alternative have been in 2006? S3 is one of the most commonly implemented object storage APIs around, so if the goal is lock-in, they're really bad at it.
> What exactly would the alternative have been in 2006? Well, WebDAV (Document Authoring and Versioning) had been around for 8 years when AWS decided they needed a custom API. And what service provider wasn't trying to lock you into a service by providing a custom API (especially pre-GPT) when one existed already? Assuming they made the choice for a business benefit doesn't require anything close to a conspiracy theo…
WebDAV is ass tho. I don't remember a single positive experience with anything using it.
And still need redundant backend giving it as API