I think the biggest takeaway here is "don't reinvent the wheel", which I think is also a big problem for every engineer/hacker. Because we tend to build our own solutions as soon as we don't like an element or how something is handled etc. But this also causes that you lose focus and forget the bigger picture ("our users don't care whether we wrote the db ourselves").
If my software engineering course left me with one thing, it was to remember the three rules of software, "reuse, reuse, reuse". I think it might have been quoted from Deitel & Deitel C++.
Even the 30+ million is not relevant, Facebook with already have all of those users. So they didn't buy any users, no revenue, no profit, just some technology which they much have been able to build themselves for a fraction of the price.
30+ million users relevant to Facebook? Of course not.
30+ million users relevant to a talk about scaling? Absolutely. The title of the article is "How To Scale A $1 Billion Startup" - but it's a tech talk about how to scale to support their userbase, not a business talk about how to increase quarterly profits. Hence, the number of users is far more relevant to the discussion than how much they were bought out for.
It is relevant since this was a technical talk. The speaker didn't even mention the Facebook acquisition; he just said that they've been in the news lately and can't talk about it.
Fantastic to think 2 engineers can scale it so far. It is exciting to think that a small team from anywhere in the world can think up the next big thing and scale it easily from wherever.
I was at this talk, and I think that by far the most important point was that you should get great advisers and mentors. Instagram started with an okay stack and terrible configuration. They ended up doing great on both counts; now they have almost no downtime, they deploy several times an hour, and their comprehensive tests take only 5 minutes to run. Some of that came from skill and prior knowledge, but the majority from adaptability and the willingness to switch quickly when advisers (e.g. Adam d'Angelo) suggested better alternatives.
Really complicated? While I'm sure some of the deep details are messy, the overall architecture is textbook standard.
A search engine (SOLR), a load balancer (HAProxy), an app server (django), a replicated/sharded database (postgres) and a replicated k/v store (redis).
