tmm_
Re:The Trello Aquisition – The Missing Piece of the Puzzle
on Thursday March 16, 2017 @01:06PM (#13886719)
Interesting catch. I'm wondering how Jira was very successful in the early days without spending much on marketing / sales and without mojo :)
Re:Consistency Models of Cloud Storage Services
on Wednesday November 30, 2016 @10:53AM (#13071693)
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.
Consistency Models of Cloud Storage Services
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @03:05PM (#12923779)
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.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @12:46PM (#12922518)
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.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @12:09PM (#12922146)
Thanks. I'll correct that typo asap but currently I don't want to clear the cache :)
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @12:07PM (#12922119)
I know, but it's the limitation on characters for headlines on HN. Isn't it clear with S3, which is storage only?
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @12:05PM (#12922095)
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.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @12:00PM (#12922059)
Thanks! We'll address this in our documentation.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:56AM (#12922029)
Sounds amazing. I'll make sure to reach out to you tomorrow.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:55AM (#12922015)
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: [email protected]
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:43AM (#12921933)
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.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:32AM (#12921835)
Definitely a good alternative until we have a Python SDK :)
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:30AM (#12921825)
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.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:25AM (#12921754)
Thanks! Will fix that soon.
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:24AM (#12921742)
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?
Re:Show HN: Amazon S3, Microsoft Azure, Rackspace, Backblaze via a Sin...
on Thursday November 10, 2016 @11:10AM (#12921601)
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 Sin...
on Thursday November 10, 2016 @11:04AM (#12921539)
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.