Hacker News new | past | comments | ask | show | jobs | submit login
Facebook and Heroku (heroku.com)
265 points by briandoll on Sept 15, 2011 | hide | past | web | favorite | 61 comments



Amazing. Way back in 2007 I taught myself how to code by making small Facebook apps. I started out by editing live PHP files on a shared server from A Small Orange ($3.33 a month!). After a few months I a few apps with traffic around 30k DAU. A Small Orange would automatically shutdown the apps every couple hours. I'd email them and complain about their shoddy hosting service. They'd always respond instantly apologizing and putting the apps back online. After a couple weeks I realized that I had a scaling problem and began learning how to setup a dedicated server. Over the next two years I spent about 80% of my time wrestling with hardware, setting up load balancers, configuring cache and db servers, and other operational nightmares. I had little time or energy to work on improving my apps or building new products.

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.


Out of curiosity, what makes you think our data services aren't reliable or scalable?


I'll jump in here, since you asked. Bad timing. About 2 hours ago we started getting these completely abstract errors 15 minutes before we were due to present to some VC folks:

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.


Did you try contacting support? Looking at that log line, I can tell you that it looks like your app took too long to respond to the request (service=30000ms) and our routing mesh timed it out (status=503, Error H12 (Request timeout).

If there's anything we can help with, definitely get in touch. Our support team is top notch.


You're right, the support team is very friendly and supportive. But my resolution times for recent issues have been 24-hour turnarounds, even when we were feeling some level of pain and labeled it "high". In this instance, which was definitely an "urgent", I just didn't have any confidence the issue would be resolved in time. Thankfully when we've had issues like this (mostly with development/staging environments) it's always easy enough to just spin up another app. But that doesn't make me very comfortable having my production stuff there.


Are you on the shared hosting DB plan? Are you using more than 1 dyno?

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.


Just eyeballing it we have about 40-50 apps using the shared DB. We don't have any dedicated DB stuff with Heroku, but we use varying dynos levels. (Most apps idle at 1, though.)


Probably that the cheap plans are on shared DBs and it's very expensive to use dedicated DBs and the dedicated boxes appear to be single instances of Postgres.

I'm not complaining, but what is the official Heroku approach to things like DB sharding, etc.


They actually have a very impressive dedicated database service: https://postgres.heroku.com/

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'm aware as we are running on heroku here, but it gets expensive quick and your options are more limited than if you roll your own. Then again, that goes for the whole platform.


I don't see how that has anything to do with the statement that I was referring to: "[their database services] don't seem reliable or scalable."


Unfortunately there is no official approach. The problem of partitioning and inconsistency to get more scalability is still evolving quite a bit.

I think things could be better, but it's not crystal clear what the right trade-off is for many people


My experience has been that the shared dbs are more performant than Ronin.

I have had a couple instances get inexplicably slow and needed to relaunch.

We're also looking into off loading our database needs elsewhere.


If you have any ticket links or more information about your problems please let us know, inexplicably slow should never happen, especially with a dedicated db.


I'd love to know which Heroku db service(s) (shared or dedicated) you used and what the problems were, so we can fix them.


I'd say that the biggest issue and the only issue I have with heroku is that when you guys have done some releases, you would prevent apps that have been placed into maintenance mode during the release from being taken out of maintenance mode.

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!


This is excellent! We are on a heroku stack at bizeebee.com now, and if we had to write a facebook app now, there's no question that we'd use this. I had written some apps right after fb platform was released and had to go through hoops to set up my own dev/production environments, manage configurations, deployments, source control etc.

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!


I should amend what I said below with a disclaimer: as long as Amazon AWS doesn't go down, and as long as heroku maintains its progress on ensuring the uptime of their cloud solution... :)


This is pure win. The screencast on this post shows that with one click you get a deployed app (in the language you choose) that ships with an app template that uses the Facebook APIs to get you started.

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.


The fact that the boilerplate app includes working examples of using the various Facebook APIs is the icing on the cake, as far as I'm concerned. I wrote a couple of apps back in the relatively early days of the API, and I remember being very frustrated by the state of the documentation and the lack of useful examples[1], and something like this would have saved me an absurd amount of time.

1: It's been a few years since I last had to do this, so the situation might have improved since then.


The graph API did improve the situation a lot, but when I worked with it last December (creating albums, posting photos) I did encounter a gap or two in the documentation. OAuth2 is definitely simpler than the old home-grown authentication system, which I never used because it looks insecure: They sign a string formed by concatenating name/value pairs without a delimiter between pairs.


It hasn't. You have to have a lot of knowhow to get these things working reliably. I'm extremely impressed with this effort.


Actually, that’s the thing – if you are starting now it’s not amazing, it’s normal. :)

It’s amazing to us fogies.


Exactly. Having started building webapps (when there just called CGI) in 1996 and seen all of the app servers and platforms come and go, there has never been a better time than now to be a web developer, thanks to products like Heroku, New Relic, SauceLabs, CloudBees, etc.. I'm constantly blown away by the improvements in developer efficiently being made seemingly every day right now. This is why you are seeing a ton of startups (even the well funded ones) only hiring a small focused technical team. What is rather funny is watching how fragmented the mobile development space has become, with some exceptions (PhoneGap, SpacePort, Mobify, etc.), especially considering that is where people are moving so rapidly to do their computing. But I'm no mobile expert so my perception is probably skewed.


Agreed. The barriers to start developing a web app now are incredibly low. You've got a server backend in Heroku, wand Facebook's gazillions of users right out of the gate.


It's certainly a win for both companies involved. I've thought about using Heroku, and making a Facebook app, and the 2 of them together now makes it a lot more likely that both will happen.


Ok, I'll be the mean one. While I am happy for heroky and everything, I am not sure why this move matters. Was hosting what was holding back the facebook app ecosystem? I was under the impression that the only successes there were Zynga and.. i'm sure there's others? Modernising hosting and support is great, but I thought it was the inconsistent policies and favouritism, and maybe the nature of the medium that killed that scene, not lack of hosting support.


It's not about the hosting. It's about speed to first code commit.

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.


I personally rarely ever log into Facebook, so perhaps if you're closeness to the platform is from arms length too, I can see where you might be missing the news.

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.


Well, as we saw with iOS, inconsistent policies and favouritism don't necessarily kill a platform.

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.


One of the major pains when writing facebook apps is that their documentation is either incorrect, out of date or non-existant.

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.


Totally agree. I don't think too many Facebook app vendors are worrying about scaling.

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.


I don't really get the idea of the app but anyway, TechCrunch Disrupt winner is Shaker.


You're right. I work full time on Facebook Applications and there are several things hindering the FB Platform. First is the lack of moderation of apps. Secondly, the approved advertiser list has too many companies promoting mobile offers (which are spammy) (http://developers.facebook.com/adproviders/). As a consequence Application ads are seedy. Think 'You have 1 new message' type ads, or "Are you smarter than Obama" type ads. Thirdly, the whole Permissions/Authentication system needs to be improved. The Permissions wall in its current embodiment advertise the negatives of adding an Application.

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-...


There are others, depending in part on your definition of success. Playfish & Playdom, for example. Non-game success stories are less common (afaik) but there are still some rising stars there, too - biggest example I can think of off-hand is RootMusic.


As a Python developer I was delighted to see Python in the list of supported languages. After cloning the repo you can notice it's just a standard Flask site with Jijna2 templates and helpers for accessing Facebook's API. I can see this as a really easy way to start developing for Facebook and also Python.



I've been expecting Heroku to add Python for a while now. There's a few Python-specific "cloud" providers popping up, but Heroku has a lot of stuff going for it, like the add-ons. I'll be really excited when they add full support for Python.


Anyone see a list of what framework is being used for each language? I created a Ruby app, and it's using Sinatra.

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

Node.js: https://github.com/heroku/facebook-template-nodejs

PHP: https://github.com/heroku/facebook-template-php


Python: Flask (http://flask.pocoo.org/)

Ruby: Sinatra (http://www.sinatrarb.com/)

Node: Express (http://expressjs.com/)

PHP: No framework


Heroku is killing it. It's great to see them adding features and functionality at such a brisk pace.


Am I the only one who wasn't aware that Heroku announced support for PHP?


They are only allowing Python and PHP for facebook apps right now. So no, you didn't miss it as it didn't happen.

Today's announcement probably means it will happen in the near future though.


I can't find it on the site right and was surprised also.


At Dreamforce a couple weeks ago I was wondering how sfdc was going to position Heroku since sfdc has already put a lot of time/effort into selling force.com. Seemed like they were trying to make the argument: "You use heroku for facebook apps and force.com for everything else!" This makes even more sense in that context.


Actually, it's more like this:

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.


I agree in practice, although I don't think that's the way sfdc's marketing team has presented it at all. In fact, I don't think I've ever heard anyone connected w/ sfdc ever use the phrase "limited scope of what our platform offers" for force.com's offerings, but I'm glad not everyone over there is drinking the kool-aid :-)


Why sinatra and not rails? I've been trying to teach myself ruby (on rails) for an app idea that I have, and this was great news as I'd been having trouble getting off the ground with rails and the koala gem. But for someone new to programming like myself, it seems like there is a ton more learning materials out there for the rails framework than sinatra.

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?


There are probably lots of reasons, but I'd imagine one of them is that a simple Sinatra app consumes less resources than a simple Rails 3.1 app, and if Heroku is going to be adding tens of thousands of them, the savings probably adds up.


Each dyno (isolated running process) is given the same type of container to run in and the difference in data storage is trivial (a couple megs of gems).

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.


The asset pipeline is completely optional. If you just put css and javascript files in the public directory, you can use them just like before.


Cool, thanks for the inside scoop!


Because Rails is overkill and tuned for large websites. Most Facebook apps are pretty tiny, so it makes sense to start with a lighter-weight framework.


Remind anyone of the Facebook/Joyent partnership 3-4 years ago?


That was just a marketing offer, where FB app developers got a month of Joyent for free. This is an integration that's much more impressive for getting developers past hosting, permissions, security, etc. to their first line of code much, much faster. It took me 10 minutes to get to "Hello, World."


This seems great. I know Facebook is switching (or has switched) to requiring 3rd party apps to use an SSL certificate. Since many of the Facebook apps I've been developing don't really require much (many times they're just informational pages, no user input) it seems like a waste to buy a full domain and SSL cert. Being able to just use Heroku's domain and piggyback SSL could be a big win there.


I noticed that they offer python hosting now. So I did a little tutorial on how to set up a Django app on Heroku.

http://elweb.co/programacion/how-to-host-django-apps-on-hero...


I am constantly impressed with Heroku's ability to identify market needs, create partnerships, and deliver product. I would love to see an article or book about their company and its evolution.


"Apps are created from one of four templates, based on the language choice you make at app creation time: Ruby, Node.js, Python, or PHP." Why no Java?


Awesome integration and I also noticed Python support. Win!


This seems like a last ditch effort to appease social app developers before they all jump ship to Google+. 4 years too late for me.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: