No offense to the Art.sy team, but this is just Heroku marketing copy. It lacks the detail we typically see on these sorts of high scalability "how we did it" posts. Non-trivial applications scale non-trivially, and when someone comes along claiming they have solved the scalability problem with the push of a button I am instantly skeptical.<p>I would really like to see more details about their architecture, especially about the MongoHQ integration.
I'd read this with a grain of salt. I remember looking at art.sy via the NYTimes link and thinking the site was terribly slow. I still find it moderately slow. I am not sure they really need mixpanel, google analytics, and kissmetrics, on every click and the api calls should take less than the 1-4 seconds I am seeing.
I'm just curious, how much traffic NYTime brought you guys. I'm also on Heroku and my app(<a href="http://www.tubalr.com" rel="nofollow">http://www.tubalr.com</a>) "survived" several articles around the web(Mashable, TechCrunch, The Verge, The Next Web, Japan LifeHacker, and several others) within a very short timespan. My bill has never been over $25, which includes no extra workers.. just extra DB storage and an upgraded DNS plugin.<p>Just curious, thanks!
Ugh! this is just a puff from heroku. Yes, I'm sure it's a great tech, but we have no idea of whether it is accurate or not. This piece has no analysis, no comparisons, and certainly no independence or objectivity.
I think this article can be a little misleading. Sure, with cloud tech you can easily spool up more instances. And yes, it is great to not have to worry about configuring a load balancer (I guess). But just because adding more instances sort of fixes a problem doesn't mean it is a good thing to do. Not "having to do calculations" is a very bad attitude. You should know where the bottle necks are, and if adding instances is actually necessary or just some scotch tape. Bad architecture and coding can bite you in ways that adding hardware cannot fix.