Live data from Hacker News

I just want simple S3

blog.feld.me

51–60 of 130 posts

Re: I just want simple S3

#51

Well, OP, your requirements section is seriously lacking. You need "s3", but only local, non horizontally scalable? You failed to answer why you even need s3... Why not a filesystem? Full stop. The entire point of s3 is distributed.

People write applications that work with the S3 API but may want to host their own storage for a variety of reasons. Personally I make use of S3-compatible services for pre-signed url access to data on disks I own. The distributed aspect is only one reason why someone might want an S3-like service.

Re: I just want simple S3

#53
Settled with SeaweedFS for replacing minio and getting a good chunk of S3 feature parity. I wonder about the problems OP is posting about. Never seen that behaviour but usually only having a bunch of smaller files.

Re: I just want simple S3

#54
Call me crazy, but wouldn't 15 minutes on GLM 5.1 produce a working implementation? I haven't looked at the code, but a non-production-grade Go implementation can't be that complicated.

Edit: Minio is written in Go, and is AGPL3... fork it (publicly), strip out the parts you don't want, run it locally.

Re: I just want simple S3

#55
Personally I would suggest that the "easiest S3" would be simply using NFS. You can get replication with RAID.

S3 is simple for the users, not the operators. For replicating something like S3 you need to manage a lot of parts and take a lot of decisions. The design space is huge:

Replication: RAID, distributed copies, distributed erasure codes...

Coordination: centralized, centralized with backup, decentralized, logic in client...

How to handle huge files: nope, client concats them, a coordinator node concats them...

How will be the network: local networking, wan, a mix. Slow or fast?

Nature of storage: 24/7 or sporadically connected.

How to handle network partitions, pick CAP sides...

Just for instance: network topology. In your own DC you may say each connection has the same cost. In AWS you may want connections to stay in the same AZ, use certain IPs for certain source-destination to leverage cheaper prices and so on...

Re: I just want simple S3

#56
post #15

I think we get a "S3 clone" about once every week or two on the Golang reddit. It strikes me as a classic case of "we need all the interested people to pull in one project, not each start their own". AI may have made this worse then ever.

I think it's like NES emulators. It's not that anyone needs one more. It's just that they're fun to make.

They're certainly a rabbit hole, too.

Re: I just want simple S3

#57
post #16
post #9

Earlier quoted context omitted.

Ah, thanks. Yeah I was confused because in his long list of vendors he didn't mention Wasabi, Backblaze etc. It appears that I do not know the context of his post.

or cloudflare R2 for that matter (very useful for egress-heavy workloads for which it is ~free)

I was curious why this didn't come up in the article

Re: I just want simple S3

#58

Personally I would suggest that the "easiest S3" would be simply using NFS. You can get replication with RAID. S3 is simple for the users, not the operators. For replicating something like S3 you need to manage a lot of parts and take a lot of decisions. The design space is huge: Replication: RAID, distributed copies, distributed erasure codes... Coordination: centralized, centralized with backup, decentralized, logi…

NFS in practice is too different from S3 to make this work.

I’ve been at a couple companies where somebody tried putting an S3 interface in front of an NFS cluster. In practice, the semantics of S3 and NFS are different enough that I’ve had to then deal with software failures. Software designed to work with S3 is designed to work with S3 semantics and S3 performance. Hook it up to an S3 API on what is otherwise an NFS server and you can get problems.

“You can get replication with RAID” is technically true, but it’s just not good enough in most NFS systems. S3 style replication keeps files available in spite of multiple node failures.

The problems I’m talking about arise because when you use an S3-compatible API on your NFS system, it’s often true that you’re rolling the dice with three different vendors—you have the storage appliance vendor, you have the vendor for the software talking to S3, and you have Amazon who wrote the S3 client libraries. It’s kind of a nightmare of compatibility problems in my experience. Amazon changes how the S3 client library works, the change wasn’t tested against the storage vendor’s implementation, and boom, things stop working. But your first call is to the application vendor, and they are completely unfamiliar with your storage appliance. :-(

Re: I just want simple S3

#59
post #15

I think we get a "S3 clone" about once every week or two on the Golang reddit. It strikes me as a classic case of "we need all the interested people to pull in one project, not each start their own". AI may have made this worse then ever.

> It strikes me as a classic case of "we need all the interested people to pull in one project, not each start their own".

And every few weeks in the cooking subreddit we get a new person talking about a new soup they made. Just think if we put all 1000 of those cooks in one kitchen with one pot, we'd end up with the best soup in the world.

Anyway, we already have "the one" project everyone can coalesce on, we have CephFS. If all the redditors actually hopped into one project, it would end up as an even more complex difficult to manage mess I believe.

Re: I just want simple S3

#60
Is the problem here that everyone wants a different like 45% of the S3 API? Or is it that minio sucked all the oxygen out of the air in this space by being good at this, and now we need something else to show up?
Post reply on HN