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.
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:
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.
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.
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 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 :)
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!
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.