Our prices will aways be lower than Amazon S3, I can tell this for sure.
But our main advantage is support - you can always open a ticket and get an answer on your question within 24 hours, but usually much faster.
Presumably, Amazon gets enormous volume discounts for the disk drives that would be a main cost of running S3, and they run their business with notoriously tiny margins. It would seem nearly impossible to undercut them for the same product at the same level of service.
Each file is stored at 3 different servers at the same time. Hot files are moved to RAM automatically and will be served very fast without even touching the disks. Our tests shows that each servers group has about 500Mb/s free bandwidth capacity at this time. And it can be increased to several Tb/s in a matter of days if needed.
Additional servers will be added in 2-3 days do the server group if necessary.
Current design was build by developers, not designers and will be renewed once the professional design is ready.
We put all our efforts on backend and storage subsystem development and completely forgot about our temporary public website.
Site images were taken from various public stock image services, I hope we didn't violate any rights by using these images.
Like I asked, can you let me know the stock image services you used? I really like that cloud that Salesforce uses and would love to be able to use it myself.
Also, if you go to http://rest.s3for.me/ (the URL you use to calculate uptime) the error message in the document tree says 'The AWS Access Key Id you provided does not exist in our records'.
You mentioned S3 stands for Storage Should be Simple, what does AWS stand for in your company? Unfortunately cloud software isn't my forte, I would love to know what that acronym stands for.
My naivete leads me to believe that your status check is hosted with Amazon, and that your uptime checker would in fact be checking Amazon's uptime but I am surely mistaken.
These headers are part of S3 implementation an we left them to avoid any possible problems with S3 clients.
Some clients are very strict on protocol validation and refused to work in some cases.
The purpose of these headers are to track all requests and be able to find any problems with any particular request. You must include them when contacting support with problems with some request. This is true both for Amazon and S3For.Me
Why is your key id called 'AWSAccessKeyId', why does your error message say 'AWS Access Key Id does not exist in our records' why is your error message identical to the letter of what S3 would return. Surely the error message text isn't required for protocol validation.
This looks like you just took an open source S3 REST API clone (there are many) and stuck it on a Hetzner server without bothering to change any variable names.
To me there are a lot of questions, the most obvious tell is that I highly doubt Salesforce would use a stock image as the logo for their cloud database solution considering the level of investment they made in it.
'AWSAccessKeyId' is part of XML Schema and can not be changed.
You are right regarding AWS text in error messages, I removed it, thank you for noticing this.
This was the first thought - to take an open source S3 REST API clone, install it on Hetzner servers and work this way, but it is not the case. Any of the available solutions fit to us for different reasons. All core software is build by our team. We use Open Source software a lot, but the core of S3For.Me was developed from the first to the last line by our team.
I've checked Salesforce site and do not see anything similar to our logo. It will be replaced in the nearest future anyway.
Hmmm... Well you may want to actually put that on your website. And you probably want to be careful, since you've posted comments on here like "all the rest documentation can be found at Amazon S3 documentation site, it is basically the same with small differences" and you have "Amazon" on the sign, which is above the "fold" on my screen and pretty much the first connection I made on S3. If your entire website doesn't scream "we are just like Amazon S3" then I must be missing something.
I would seriously reconsider putting that button on a page more than once or twice. It makes it look unprofessional.
It looks like an interesting storage service, but like others mentioned, you should consider renaming it. I was convinced you were reselling Amazon S3 storage when I visited the site.
We are using our own self-written software to implement S3 protocol. We do not support all enterprise-features like extended ACL, regions, encryption, this makes our software much simpler and easier to develop.
You can find basic documentation here https://my.s3for.me/client/docs/index, all the rest documentation can be found at Amazon S3 documentation site, it is basically the same with small differences.
Edit: can't post comments for some time (You're submitting too fast...), will reply later.
Can you share more about your implementation? (Disclosure: I'm very interested since I work on OpenStack Swift.)
Starter questions:
How does data placement work?
How is data checked for correctness?
How do you do listings at scale?
During hardware failures, do you still make any durability or availability guarantees?
How do you handle hot content?
How do you resolve conflicts (eg concurrent writes)?
> How does data placement work?
Each object bigger than some size is split in small parts, these parts are linked to the metadata object with all information, such as name, bucket, size, date, checksum, etc.
All data is split in server groups - each group is at least 3 mirrored servers with no more than 5TB of data to make system flexible. Server groups can be added to increase system capacity or removed to decrease.
> How is data checked for correctness?
With checksum. Once the data is uploaded by user he will receive its checksum and must compared it with local checksum to make sure that it was correctly transfered and stored. The same checksum is used to ensure server-side data correctness.
> How do you do listings at scale?
There is a trick - we support only one delimiter (/), this means that we can use very simple listing algorithm which scales very easy.
> During hardware failures, do you still make any durability or availability guarantees?
Yes, all data is split in server groups by 3 servers each. If one of 3 servers will fail, this group will still running like nothing happened, some running requests may fail though. If 2 servers will fail at the same time, then this group and all data in it will be put in read-only mode to avoid any possible data damage.
> How do you handle hot content?
It is cached in RAM by OS, we do not perform any additional measures. OS does a pretty good job.
> How do you resolve conflicts (eg concurrent writes)?
Some conflicts are resolved by the software if possible. Unrecoverable conflicts are returned back to user with HTTP 400, 500 errors to make him know that something is wrong and he must run request again.
For concurrent writes we use simple rule - the last one wins.
Interesting, and thanks for the response. If I may probe a little further, I have a couple of follow-up questions.
1) Server groups of at least 3 mirrored servers, with a max of 5TB.
This seems like an interesting design choice. What do you mean by "at least"? Does this mean you'll have some data with more replicas? Are these server pools filled up and then powered down until they are needed? How do you choose which server pool to send the data to? And since you have a mirrored set of servers, when do you send a response back to the client?
Is the 5TB number something that is a limit for the storage server (ie 15TB total for a cluster of 3)? That seems rather low. It also doesn't divide evenly into common drive sizes available from HDD vendors today. So what kind of density are you getting in your storage servers? How many drives per CPU, and how many TB per rack? Since you're advertising on low price, I'd think very high density would be pretty important.
2) You say you split data into smaller chunks if it crosses some threshold. Let's suppose you split it into 1MB objects, once the data is bigger than 5MB. And each 1MB chunk is then written to some server pool which has replicated storage (via the mirroring). How do you tie the chunks back to the logical object? Do you have a centralized metadata layer that stores placement information? If so, how do you deal with the scaling issue there? If not, another option would be to store a manifest object that contains the set of chunks. But in either case, you've got a potentially very high number of servers that are required to be available at the time of a read request in order to serve the data.
Just as an example (and using some very conservative examples), suppose I have a 100MB file I want to store and you chunk at 10MB. So that means there are now 10 chunks replicated in your system, for a total of 30 unique drives. Now when I read the data, your system needs to find which 10 servers pools have my chunks and then establish a connection with one of the servers in each server group. This seems like a lot of extra networking overhead for read requests. What benefits does it provide that offset the network connection overhead?
And what happens when one of the chunks is unavailable? Can you rebuild it from the remaining pieces (which would essentially be some sort of erasure encoding)?
Overall, the chunking and mirroring design choices seem to me like they would introduce a lot of extra complexity into the system. I'd love to hear more about how you arrived at these choices, and what you see as their advantages.
In order to not make my long post even longer, I'll not pursue more questions around listings, failures, or hot content.
1) I've made a typo, not "at least", but "at maximum", meaning that each server can store up to 5TB of data, it's 2x3TB hard drives servers. The density is very low because we use cheap hardware which fail regularly and such a small data amount means high recovery speed. 5TB is a soft limit and can be different for server groups, but it is not at the moment. Each group of 3 servers has a total capacity of 5TB because data is mirrored.
2) We have a centralised replicated metadata layer which is stored on the same servers as the data itself. All object chunks are stored at one servers group at the same time, so there is no need to connect to multiple servers to serve a file, it is enough to connect to one server from server group to get all the data. Metadata may be stored at different server group though.
All chunks are replicated to 3 servers at the same time using a sequential append-only log to ensure that all servers has the same data. This may introduce replication lag and if it is too big for some server then it is removed from the server group until replication lag back to normal (1-3 seconds usually).
Actually, it is much simpler than I explained, data layer with replication, data consistency and sharding is completely transparent to the application layer and it is really-really small and simple. Email me at [email protected] and I'll share with you software details and you will understand how simple it is.
