21–30 of 69 posts
https://github.com/andrewgaul/s3proxy
It has compatibility with local filesystem, Backblaze B2, Google Cloud Storage, Microsoft Azure, and OpenStack Swift. Note that this is software and not a service.
[S3Proxy author plug]
I was looking for the same thing but for email providers. I would like to let users to subscribe to mailchimp,aweber,getresponse etc using a single integrations instead of having to integrate each one of them.
It's a nice feature-set, looks well-designed, and handy - but anyone using one of these APIs would find it super trivial to implement this themselves? I'm not sure I see the cost-benefit making sense here? I'm keen to be convinced, though - what's the killer use case? (I'm not aware of APIs changing or being deprecated in any big way) Edit: ah, the other APIs make way more sense to me. You can offer multiple options…
This allows you to easily integrate multiple of these providers if necessary or easily switch. Of course you can integrate them one by one on your own but that takes a lot of time time. With CloudRail it's one API which works even cross platform. Our ultimate goal is to handle all your integrations and not only cloud storage. So unified APIs for fast API integrations and API Change Management to keep your integration…
The Rackspace API is OpenStack Swift, a project used by many more public and private cloud providers than just Rackspace. I've been working on Swift for the past 6 years, and I'd be happy to help with your OpenStack Swift API integration. See my profile for contact info.
Do all these services provide equivalent or abstractable guarantees? Amazon S3, for example, provides 'read-after-write' consistency, meaning once you've received a positive response to a put operation, you can expect to be immediately able to retrieve that object. But it used to be 'eventually consistent', meaning it was possible to receive a positive response to a put, but then not be able to read the object immedi…
Do all these services provide equivalent or abstractable guarantees? Amazon S3, for example, provides 'read-after-write' consistency, meaning once you've received a positive response to a put operation, you can expect to be immediately able to retrieve that object. But it used to be 'eventually consistent', meaning it was possible to receive a positive response to a put, but then not be able to read the object immedi…
You can compare these guarantees and results from testing: https://github.com/andrewgaul/are-we-consistent-yet
No monthly fees, support open source: http://jclouds.apache.org/ Wouldn't surprise me if that's what they're using behind the SaaS
Earlier quoted context omitted.
This allows you to easily integrate multiple of these providers if necessary or easily switch. Of course you can integrate them one by one on your own but that takes a lot of time time. With CloudRail it's one API which works even cross platform. Our ultimate goal is to handle all your integrations and not only cloud storage. So unified APIs for fast API integrations and API Change Management to keep your integration…
I see what the feature is, but I don't see the use case or benefit - in this particular case! The social, payment, consumer storage, I definitely do. But it feels a little like the age-old example of abstracting away your database layer, in case you wanted to change which database you use later. (It's incredibly rare to do it!)
Do all these services provide equivalent or abstractable guarantees? Amazon S3, for example, provides 'read-after-write' consistency, meaning once you've received a positive response to a put operation, you can expect to be immediately able to retrieve that object. But it used to be 'eventually consistent', meaning it was possible to receive a positive response to a put, but then not be able to read the object immedi…
S3 only has read-after-write consistency for PUTs to new objects (not overwrites), and if you do a HEAD/GET before the PUT that degrades into being eventually consistent. http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction....
Netflix have turned the S3 metadata eventually consistent problem into s3mpr metadata eventually consistent problem. The difference is that they can now inspect and reason about s3mpr's metadata.
Spotify have had to do the same thing for Google Cloud Engine. I can't help wonder if eventually consistent object stores will go the way of NoSQL databases, when a consistent, scalable hierarchical filesystem appears.