AppHarbor (YC W11) launches add-on ecosystem using Heroku's (YC W08) API(blog.appharbor.com)
blog.appharbor.com
AppHarbor (YC W11) launches add-on ecosystem using Heroku's (YC W08) API
http://blog.appharbor.com/2011/06/27/announcing-add-ons
7 comments
At least in the case of Cloudant (CouchDB) the servers are in the same facility as AppHarbor.
http://blog.cloudant.com/dot-net-couchdb-cloudant-appharbor/
http://blog.cloudant.com/dot-net-couchdb-cloudant-appharbor/
[deleted]
IMO the appharbor add-ons page is a poor replication of the already poor UX of the heroku add-ons page.
I get that your a heroku clone but it probably wouldn't hurt to show a little innovation.
I get that your a heroku clone but it probably wouldn't hurt to show a little innovation.
[deleted]
Nice that they have add ons and pricing for them but I wish they'd sort out their own preliminary prices first...
http://appharbor.com/page/pricing
Until there is solid pricing and a decent story around support it's very hard to use for anything that matters.
http://appharbor.com/page/pricing
Until there is solid pricing and a decent story around support it's very hard to use for anything that matters.
I'm not to familiar with .NET, but it is interesting to see other providers come up that are similar to Heroku. The add-on system that is developing is great. All of the providers are specializing in what they do best.
This is a great addition! I'll have to start experimenting with moving off of SQL to Mongo.
Why's Redis so significantly more expensive than other services?
We don't set prices for add-on providers offerings, but note that Redis is an in-memory database and that memory is more expensive -- per GB -- than disk. (I'm an AppHarbor co-founder)
I know you guys don't set the price, just found it odd. It's persistent in-memory according to wikipedia, doesn't that make it like mongodb?
But Redis should have at least as much RAM as you have data and will only use the data from RAM. You cannot swap or store it on a slower disk, while Mongo can use a disk file.
Redis can backup or journal to disk, but this is just so the data is persistent between restarts, not used in queries or runtime.
* Updated based on comments: I originally wrote that redis requires as much ram as data (technically more) but I'm correcting this to state that Redis CAN use disk, but Salvatore, the man behind redis, publicly states that he does not recommend it as a solution.
Redis can backup or journal to disk, but this is just so the data is persistent between restarts, not used in queries or runtime.
* Updated based on comments: I originally wrote that redis requires as much ram as data (technically more) but I'm correcting this to state that Redis CAN use disk, but Salvatore, the man behind redis, publicly states that he does not recommend it as a solution.
This is incorrect. Redis can swap out to virtual memory when it runs out of RAM. Although, it should be leveraged with some care (http://news.ycombinator.com/item?id=2606096)
Thank you for the link. I actually do remember reading that, and I guess I completely forgot it was even possible. After reading about it, I told myself that redis will be in-memory only for the solution I was using it for. I'd definitely be curious to see some real world performance numbers for redis using the disk VM before considering it an option.
Ah okay, that makes a lot more sense. Not sure who downvoted you but thanks for explaining it.
I did because it was wrong.
Technically it was wrong but practically it was not. see: http://news.ycombinator.com/item?id=2606096
In particular: "I trust Redis-on-disk every day less." --antirez (author of redis)
which he then qualifies in the comments as some slim use-case where it makes sense to have redis persist data to disk.
In short, it's not the intended use-case and you damned well better know what you are doing.
In particular: "I trust Redis-on-disk every day less." --antirez (author of redis)
which he then qualifies in the comments as some slim use-case where it makes sense to have redis persist data to disk.
In short, it's not the intended use-case and you damned well better know what you are doing.
[deleted]
I've never used this kind of services but the first impression is that just the RTT between your server and the third party's one will have a huge impact performance-wise, removing every advantage you could have from the use of these DBs.
And what about security? Are memcache/redis/mongoDB/etc... made to be exposed to the public internet (requests content and format are carefully inspected by the server and during development, the implementation have been tested carefully with fuzz testing or similar techniques) or these hosted solutions add an additional layer that increases security/safety?
These issues could be mitigates (not resolved) when both parties are on the same platform, but not everyone is on EC2/Heroku.