Facebook and Heroku
blog.heroku.com
blog.heroku.com
Then I discovered Heroku. I would have done anything to have this when I started out. The platform teaches (forces) you how to build a scalable architecture. You can try out new ideas for apps for essentially nothing (1 dyno is zero dollars). Since moving to Heroku I spend about 5% of my time working ops. The craziest thing is I've actually saved money since switching from dedicated hardware to Heroku. I was really bad at configuring servers and the stuff I built was inefficient and expensive. Heroku's cloud stacks are optimized better than my old hardware environment.
Heroku's architecture is great for wild traffic swings common with Facebook apps. Well except for their database services. They don't seem reliable or scalable. I prefer RDS.
In sum, Facebook and Heroku is a great starting place for learning to build web apps. I would have done anything to have this tech four yeas ago.
2011-09-15T18:34:33+00:00 heroku[router]: Error H12 (Request timeout) -> GET [redacted]-staging.heroku.com/ dyno=web.1 queue= wait= service=30000ms status=503 bytes=0
I have absolutely no indication what part of our stack is having trouble. After much freaking out, we spun up an entirely new app and demoed with the seed data. This weird sort of stuff has been happening to us at an alarming rate over the last 3 months or so. Not being able to deploy, having to put in a ticket, and waiting 24 hours for a someone in support to fix it is another example.
Please don't take this the wrong way: I love you guys as people. I pushed for Heroku adoption at our shop. I absolutely love the concept of Heroku. Until a few months I felt like you guys were doing it way better than anyone else. (Left EngineYard to migrate everything to Heroku.) But these past few months have been really scary. There is a growing consensus at the office that we'll end up migrating away from Heroku to a platform where we can actually understand what's going on and be responsible for what's going on under the hood. After I began using Heroku, I never thought I'd want to go back to that again.
EDIT: Provided a more clear example that is less obviously suspect of a timeout.
If there's anything we can help with, definitely get in touch. Our support team is top notch.
We are running 4 dynos, 2 workers, and the Ronin DB plan and we haven't had any problems other than a 10 minute downtime due to a bad deploy by Heroku.
I'm not complaining, but what is the official Heroku approach to things like DB sharding, etc.
It supports scaling vertically by throwing in more cache, faster CPU, etc. Once you outgrow that, it supports horizontal scaling by replicating to read-only slaves.
I think things could be better, but it's not crystal clear what the right trade-off is for many people
I have had a couple instances get inexplicably slow and needed to relaunch.
We're also looking into off loading our database needs elsewhere.
This becomes a problem when the maintainers of the app in question are not aware of your release schedule. The solution, it seems, would be to either a) do a better job of communicating downtime; b) do rolling deployments and failover so that apps may continue to function; c) a bit of both.
While our app is not important enough for the above to bother us a great deal, we do have paying customers. As soon as one of them comes knocking telling us that we screwed up, and in reality it wasn't fully our fault, we will be a bit more adamant about the above suggestions :)
For the time being, great job!
Heroku had taken care of all of that for non-fb apps, and now with tight fb integration, I might just write a few quick fb apps again!
Thanks for the good work, fb and heroku!
We're witnessing a Facebook app that creates real living Facebook apps. Heroku continues to impress with insanely easy onboarding of folks new to deploying web apps, and building features the way things should work.
It must be amazing to start programming in the age of Heroku.
1: It's been a few years since I last had to do this, so the situation might have improved since then.
It’s amazing to us fogies.
When you're setting up your first Facebook app, there's a bunch of docs to read, you need to create keys/IDs, figure out the URLs you need to populate, understand how FB Connect works, etc. As someone who tinkers with FB apps and not actually launched one, it took me most of a day to setup a fresh EC2 instance and get everything configured. However, it took me only 10 minutes to get my first "Hello world" app launched, without having ever used Heroku before. That's the big step forward here -- a turnkey skeleton app that eliminates the initial frustration.
For big app developers, this is of no value. It's for tinkerers like the rest of us to get to baseline faster, and is designed for us to get sold on Heroku and get our feet wet with FB app development.
Let's use photos as an example to demonstrate the power and size of Facebook. This infographic shows the scale of photos stored in the Library of Congress, Flickr, and Facebook: http://s3.amazonaws.com/fromus/blog_posts/largest_photo_libr...
I work at New Relic, so I see a lot of companies (startups and otherwise) that have apps deployed on Facebook. The traffic they get is _insane_ and I don't see any indication that it's slowing down.
Games are an obvious category where Facebook dominates, but they are quickly becoming an obvious destination for new apps to launch, given the access to their social graph and the viral nature of the apps in general.
This isn't about hosting. This is about creating a living Facebook app in 5 seconds.
I think this is a big deal because the law of demand is a big deal. What the Facebook/Heroku partnership means is that if I'm some 19 year old with a cool idea, I don't need money or experience in hosting, I just have to write the code to do it. Calling that "modernising" is missing the point entirely.
To return to the iOS analogy, there were a lot of people who said "well, yeah, so Apple made an integrated platform for developing and selling software - but what does that get us that we didn't have before?" The answer to that question depends on whether you consider $1.7 billion in revenue novel or not.
If you create a facebook app using heroku, it looks like you get something akin to a facebook-boilerplate app that is already deployed.
I would imagine the people at Heroku / Facebook spending some effort in keeping their boilerplate app / demo up to date with any api changes that may occur.
If Facebook wants to get more developers to embrace their dying platform (when was the last time you heard about an exciting new FB app?), they'll need to silence the voices screaming from every corner of the Internet about their lame documentation and support.
Buy as usual, instead they do a song and dance announcing a new initiative and then completely forget about it, like their Stack Overflow support system which does not seem to have nearly enough participation from actual Facebook employees who can answer questions.
Even if you disagree with the above, you should agree that an API that accounts for 10% of a site's traffic, like Facebook's, is a struggling ecosystem. Src: http://www.businessinsider.com/facebook-news-feed-apps-2011-...
Edit: here's links to all the app templates, for anyone interested:
Python: https://github.com/heroku/facebook-template-python
Ruby: https://github.com/heroku/facebook-template-ruby
Ruby: Sinatra (http://www.sinatrarb.com/)
Node: Express (http://expressjs.com/)
PHP: No framework
Today's announcement probably means it will happen in the near future though.
Use Force.com for rapidly developing an app that integrates with Salesforce or fits within the limited scope of what that platform offers. For everything else, use Heroku.
So in a way this seems to me like a very easy way to get a simple app up and running, but I lose all the help that's out there that's specific to the rails framework. Am I being naive in thinking that the little that I've learned about the rails framework won't apply to sinatra?
In this case it's more about making it simple to get started. Rails has a fairly large learning curve, and the asset pipeline in 3.1 has only made it worse.
http://elweb.co/programacion/how-to-host-django-apps-on-hero...