After a lot of comments around consistency to our last post (https://news.ycombinator.com/item?id=12921389) we decided to cover that in a blog post and compare all services. Happy reading.
CloudRail doesn't touch the data. Everything flows P2P between the app and the provider. It's like if you integrate the native AWS SDK. So even if CloudRail goes completely down, your integrations will keep running.
As I understood it, it is more a solution for dev-ops to create the infrastructure. Like a provider agnostic CloudFormation. CloudRail is about making it super simple to integrate APIs into an app.
Even if you don't want to switch and believe in non changing APIs, it is easier to integrate with CloudRail :) But as already mentioned, this interface is really part of a bigger offering. We want to handle all your integrations eventually and enterprise cloud storage has to be part of that.
We have a very simple interface for email here: https://cloudrail.com/unified-email-api/ But it just offers sending emails. What you described is actually a potential candidate for a next interface. Would love to discuss that use case with you. Feel free to reach out: support@cloudrail.com
Very good question. Of course all services behave a little differently which is out of our control. To be honest, I don't have an exact answer on that. In my first tests I could chain a download directly after the upload with all services. But I don't know if that's because they're all guaranteed to be read-after-write or some were eventually-consistent just really fast. In general, if one service is read-after-write and you want to switch it for one that isn't you might get problems, unless you've programmed defensively (checking for existence before proceeding).
Give us some time to check that and run some more tests.
Nope, we don't use it but it is a very cool project. We have SDKs for Android, Objective-C, Swift, Java and Node.js so far. That's why we couldn't us it anyways. We don't want to compete with open source projects like this. Our goal is to offer easy integrations for all platforms and all major use cases (not only cloud storage). Btw, to support open source, we made our solution free for non commercial projects.
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?
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.
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.