Live data from Hacker News

Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

cloudrail.com

1–10 of 69 posts

Re: Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

#3
This is our brand new unified API for enterprise cloud storage providers. It's part of the CloudRail API Integration Solution which consists of multiple unified APIs for different categories like social, payment, consumer cloud storage etc. Our value props are: A single API for multiple providers & No API changes since we keep the integrations up-to-date. All that without a hosted middleware. So we never touch the data. Looking forward to hear your feedback.

Re: Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

#4
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 to a customer. But this doesn't seem to have an equivalent?

Re: Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

#5
post #2

Open source alternative: Rclone -- http://rclone.org/

I switched to Rclone recently for personal backups and it's unbelievable how slick, stable, and well-behaved this program is.

As far as I can tell though, it does not expose an API beyond its command line interface though.

Re: Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

#6
post #4

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 integrations running forever.

Re: Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

#9
post #6
post #4

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…

so how exactly would changes in API be handled?

Re: Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Single API

#10
post #6

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…

so how exactly would changes in API be handled?

Our system monitors the APIs and informs us about changes or the provider does. This happens usually months before the integration would actually break. Afterwards CloudRail updates the SDKs and informs the affected users via email and in the portal. And affected means really affected, so only if you use this specific (broken) function. All you need to do then is update the SDK to it's latest version. We are also working on a optional and completely automated way to update the SDK. But most developers want to test it before. Btw, any opinions on the auto update here?
Post reply on HN