Is it possible to host Facebook on AWS?
blog.sqlizer.io
blog.sqlizer.io
This post has two contradictory quotes in my opinion:
"It’s worth noting that this AWS price wouldn’t be what Facebook paid in this hypothetical situation. Much like Snapchat and Netflix, Facebook would be a heavy and influential user"
"Facebook’s years of specialization for running Facebook are in contrast to AWS, whose storage is designed for multi-purpose (albeit-heavy) use." - Amazon already has several tiers of storage (S3, S3 - Infrequent Access, Glacier, CloudFront)... who is to say that they wouldn't be motivated to introduce more classes by a large customer like FB.
"Netflix will most likely exist even if we don't provide them server services as there exist other cloud providers and / or Netflix is big enough to roll their own, so we might as well have a piece of our competitor's success by having their infra spend come to us."
That's not to say it might not be a worthwhile approach over the long run but it would be a huge strategic investment in something that has essentially nothing to do with what they view as their core differentiating service to customers.
Would Netflix have done things differently if they had known they'd reach this level of usage? Perhaps. But disentangling now would be very difficult and almost certainly disruptive--including a likely reduction in quality of service.
And disentangling be disruptive? Stand up your new datacenter and shift your apps over with DNS when they're ready to serve production traffic. If you can move traffic between regions, you can move it between on prem and cloud.
Here is a blog post (2010) describing the decision to move out of our own data centers:
https://medium.com/netflix-techblog/four-reasons-we-choose-a...
So they already have their own system. As as some below have mentioned, they could simply move to Azure if they wanted without much trouble.
The way he thinks about things is it's not a threat to his business to have competitors in his space not just because he is prepared to undercut them on cost but because he knows that his true focus is on customer satisfaction. And competition, whether through providing customers with a choice or encouraging his own systems to provide better services is good for his business.
But in this case it's really just because Netflix is too insignificant to matter to Amazon overall. It's just a tiny fraction of their revenue and what they're trying to do.
And if you want to be Machiavellian of course it's good because then Amazon has leverage of Netflix.
Seriously how would it look if Amazon turned down a company because they were competing? It would be an admission of defeat and weakness for AZ. That's not how an "apex predator" thinks.
Keep your friends close, and your competitors....
It looked shitty when it happened with Amazon and Apple
The latter decision has been reversed now though https://techcrunch.com/2017/06/05/amazons-prime-video-app-is...
I found this to be really stupid behavior of Amazon. Seemed like they only wanted to push their competing product (Fire TV).
It's good they figured things out, though. A Prime Video app was announced at WWDC.
It would look bad: https://www.wired.com/2015/10/amazon-apple-tv-chromecast/
Amazon's selling. Netflix is buying. It'd be stupid to refuse the money. Netflix wouldn't lose much sleep over it–at their size, building their own infrastructure can't be much worse than renting.
Plus you'd get the idea out there that Amazon isn't the sort of reliable utility company their marketing suggests. They have their fingers in so many markets, a third of their customers would start to fear being cut off.
AWS is also a separate division within Amazon, and probably not lacking self-confidence. The people are judged by the numbers of AWS, and they'd probably resist attempts to get them to forgo revenue just for the sake of some other division's feeling.
A lot of big companies that compete with Amazon in some vertical have a no-Amazon policy for infrastructure. Some even require their business associates (vendors, etc) commit to contracts to do the same.
Amazon seems to want to be in every business sector there is, so almost any company could end up competing with them.
The real question isn't "can FB be hosted on AWS?", it's "why isn't FB competing with AWS?" because what they've already got is much better for the range of applications that they deploy.
How does this affect libraries like preact?
Acting like this is some landmine that allows Facebook to just put anyone they dislike out of business is ridiculous. Other JavaScript frameworks like Angular and Ember don't even include patent clauses, so even if Facebook revokes the patent grant, that leaves you in the same position that you're in by default with Angular. The license even specifically allows you to counter-sue Facebook if they already have a lawsuit against you.
Any confusion that arises from deciding to depart from well-understood licenses is fairly laid at their door, in my view.
That's true; however,
> React isn't known to be patent-encumbered.
That's a useless assertion. Many patents only become known once the lawsuits start. Facebook has amassed a patent portfolio, and patents are a legal instrument that can only be used offensively.
Remember, the claim I was disputing was that "only a fool will use reactjs" because the patent license is conditional. All I'm saying is that I don't see any reason to be more concerned about React than, say, Angular.
Facebook is a (among many other things) a software company, and software companies do warfare with patents. It might be their least favorite weapon, one they have yet to use - but "unthinkable" can only refer to your beliefs -- it is actually extremely thinkable, even if at this point in time improbable.
I'm really concerned about zstd working its way into some future de-facto standard file format, though - I think the name "zstd" is marketing genius (of the evil kind).
(1) can afford to roll your own framework
(2) can afford the lawyers required to point out that this doesn't hold water
It's incredibly permissive (nearly the same as the MIT license), and does not allow for the concept of having it "revoked".
Would you believe that Apple today would use react in their products?
What would Steve Jobs say to someone who suggests using react in apple software/saas?
downvoting on HN is being abused here, just because someone is a big fan of reactjs and disagrees with me, they automatically downvote a valid opinion based on facts.
see for yourself, from react patent clause "The license granted hereunder will terminate, automatically and without notice,"
If you are in doubt, the license that could terminate is just the patent grant. The copyright license would remain in effect.
The TL;DR is: "That is just a patent license, and most OSS doesn't even include a patent license at all, so it seems weird to be super-concerned in this case in particular."
here's the issue when picking reactjs vs others (like vuejs)
Choice A. by picking reactjs I'm in a clear violation of FB patents, but I'm covered as long I don't sue FB.
Choice B. by picking others (like vuejs), I may or may not be violating FB patents, (virtualDOM has some prior art, as some people claim)
why it's so hard for people to understand that "May or Maynot" is a better choice of "definitely" violating FB patents in case I need to sue FB if they are killing my business by copying my patents.
I know that suing for patents is not best business model. But, having that weapon (even defensively) is better than not having one.
still people downvote for gray areas?
> Choice A. by picking reactjs I'm in a clear violation of FB patents
Please tell us what Facebook patents one is "violating" by using React.
your argument of where are the FB patents on react is an example of your naivety
my position all along has been, using other libs than react is LESS likely to violate FB patents, and thus gives more freedom to compete with FB. if that's your definition of load-of-crap, well, that's not my definition.
(Not that I'm criticizing Facebook. Open-sourcing code is hard -- see Borg.)
The point was that yes, Open Compute exists, but its existence is only partially relevant when one claims that Facebook has opened their "infrastructure." The two sentences in GP are basically what I'm responding to -- mainly the verbatim "FB open sourced their infrastructure" -- and I guess the implied context of Facebook infrastructure was lost when I said "nothing to run on it," sorry. I meant Facebook code. So this is clear: Open Compute is good, and I'm appreciative of Facebook, just want to make sure we understand what "open infrastructure" means and its limitations in this case.
The latter is just a necessary tool. But, you're not going to threaten FB 's mission by simply building out an identical (or even superior) infrastructure. So, there's virtually zero-risk to them in open-sourcing it.
This. When they bought Parse I thought for sure they would get into the same business as AWS / Azure / etc but then they phased it out. Their have so much network infrastructure I thought for sure they would want to offer such services and yet they still have not.
I'm starting to think they won't ever get into the same business.
Also to recognize: Amazon is a store, not an application. It doesn't need specialized hardware or whatever. Its customers care much more about package delivery speed / cost, etc than whatever hardware is running in the background. So it can box the same generic web servers it uses and sell them at scale. Facebook is entirely digital. It needs to specialize everything hardware-wise in order to stay ahead. The things it optimizes for, in terms of hardware, likely has no relevance to 99.9999% of basic CRUD apps out there. So they stick to what they do best. Their own platform.
Their focus should be solely on what is going to likely end up being one of the three or four greatest money producing machines in world history (of those owned by a traditional corporation that is).
Cloud computing profits are - and will remain - a joke compared to the $20 billion in net income they'll yield in just a few more years from what they're already doing. Their focus should remain fairly narrow, they're a mere 13 years in at this point. Diving into cloud computing would be making the same exact mistake that Microsoft made with Bing, and that Google made with all their laughable social attempts, and so on. Facebook would split the market further and likely still end up #2 or #3 at best. Their best engineering talent should be solely focused on the golden goose social monopoly, which nobody else has and nobody else can compete with.
I think the market for cloud computing is very, very large.
Consider that it's a composite of "all server hardware vended or leased" and "a significant fraction of middleware and server software vended".
Microsoft are in it because they follow their existing rivers of gold as they shift. Google are in it because they desperately need a second river of gold to allow them to survive unexpected collapses in advertising revenue.
Business are different.
Margins also means more vulnerable.
Amazon doesn't like margins. Andy Jessy routinely mock "the old guards"' obsession with margins.
The possibility that fb is Suddenly dying because of some new competitor probably is 10* of Amazon. Just random statement, you get the idea.
As for siganifance, cloud computing is much bigger, it runs the actual computing that produce things that is more valuable than ads. This is in general sense, I do not want to judge their social impact.
Companies don't "produce money", that would just devalue currency.
I gusss you had a good go at making it sound cool.
A naive guess would be that providing services for users you don't control is harder than for users you do control.
As well as inflation, and all manner of other totally irrelevant concepts.
Ten years ago, four-core Barcelona Opterons were so hot and in high demand that, if you wanted to be on the latest servers, you had to show a performance boost worth the premium. Sometime this year you'll be able to buy dual processor Naples systems with 64 cores (128 threads).
Notice how the 1B has only 6 zeros. The awesome part is that this mistake evens itself out later, yielding a correct number for "The of servers".
Large enterprises of any significance, and especially flagship/strategic customers, don't pay list prices.
Every cloud provider has private pricing and enterprise discount programs. That goes for all hardware vendors (e.g. Cisco, Palo Alto Networks, Oracle, etc selling to any company) as well.
I'm sure Netflix pays nowhere near public pricing on AWS and I'm sure AWS pays less than anyone in the world for an Intel CPU.
Disclamer: I work for AWS.
Hope you don't work with any anything to do with scale at AWS.
You're looking more towards 1 Exabyte a month...
You wouldn't run it the same as if you had your own infrastructure though, and probably you would run it more horizontal and cached but it could be done much cheaper than this estimate. On your own environments you can use larger servers, dbs and sharding or clustering is closer. But the cloud is different and you'd be able to run it but differently. The cloud definitely influences architecture.
Those are read-heavy properties (yes, even Reddit, a miracle of aggressive caching). Don't underestimate Facebook's write load, which is the bloody difficult thing to scale.
Little bit (somewhat outdated) here: http://highscalability.com/blog/2013/8/26/reddit-lessons-lea...
User actions like upvoting vs liking per user probably falls in reddits favor but the content being shared on facebook is much larger in size.
No way this can be true. Facebook scaled primarily using CDNs like Akamai. Akamai is the largest CDN in the world and has no more than 300k-350k servers all over the world. It's one of the largest distributed system in the world. I worked there, so I know this for sure.
Facebook has recently been moving their data in house, but they do not have 830,000 servers. That's almost 3 times Akamai. At this point, Facebook would be more profitable letting people use their server infrastructure instead of using it for themselves.
Running Facebook over AWS is a CDN problem that was solved by Akamai!
Not to be a jerk, but, running Facebook over AWS is not a CDN problem. That's crazy talk. There are far more Facebook requirements that AWS can meet that Akamai cannot. You have to look beyond their content delivery reqs.
Also, they could absolutely have 800k servers. I don't think comparing their size to Akamai is fair. The requirements of each company are drastically different.
Do I think the 830k is accurate? No, but only because these estimates are usually wrong (unless informed by an inside source).
The problem is mostly a CDN one, crunching data and writing to the servers are second to actually serving users fast.
For example, I don't necessarily need to see the latest posts, comments, etc. so you can queue up the writing and sync data later, but when I hit fb.com, I have to see stuff...
Using the cloud you don't need X,Y,Z and presumably will need less of W. Assuming a 100+k/year salary, that's like 200+k/year total cost of employment. If X+Y+Z-ΔW ~= 1000, then the cloud provides a 200M savings on that front. The real number is probably 2x 3x higher, but I'm not going to bother going back and updating the guesstimates.
AWS is still a huge boon to startups from a cash flow perspective - it's like leasing equipment rather than buying it, except you're also leasing a very small fraction of all the folks you need to build/operate the equipment. It's also very cheap compared to trying to build and run the infrastructure yourself at small scale.
And don't kid yourself -- you still need SREs in AWS. They're working on different issues, but AWS introduces as many issues in an SRE's scope as it removes.
Take for example, Dropbox stated they are moving off AWS -- except in Europe (and other non-US areas I'm sure). Having boots on the ground abroad, operating 24/7, dedicated to the mission of the company where they have not even visited ... near impossible.
https://blogs.dropbox.com/business/2016/09/making-european-i...
Why? Hiring people around the globe is hard who are going to remove that HDD 24/7 is pretty hard. Hiring lawyers to understand foreign law is hard. Keeping your company focused abroad and building a culture abroad is very hard.
How long does it take for a company to expand to India on their own? In AWS, you just change your CloudFormation template to another region.
1,000,000 users / 180,000 servers = 5,556 users per server
Should be
1,000,000,000 users / 180,000 servers = 5,556 users per server
... but apparently no efficiency gains in 5 years to reduce the number again? Faster processes, more cores, more ram, better storage, more senior-developer-hours, bespoke datacentres... ?
This is surprising since 1) Facebook is most likely using Hack and 2) it could save a lot of money by moving to Go.
> Facebook’s entire site runs on HHVM (desktop, API and mobile)
Isn't Facebook running mostly on React? I'm guessing HHVM only really powers the API, business logic, etc.
The majority (all?) of the front end and mobile apps are powered by React and React Native, respectively.
Go outperforms HHVM by a wider margin than 20%. I've seen benchmarks as high as 50%. Sure, benchmarks aren't real world applications, but it's safe to say that generally speaking Go is significantly faster than HHVM.
That's why they invented Hack and HHVM in the first place -- it was a cheap-enough compromise that didn't require rewriting the whole code base.
Wouldn't most of the pressure be on whatever the data layer is?
PHP is the presentation layer. Much of the actual logic is in C++, Java, and maybe even Go by now.
Another fun bit from that deck was a newsfeed-related PHP function with something like over 70 arguments across a dozen lines -- basically template data to render that had organically grown over time. It earned its own slide. There was an audible gasp from the room when it was revealed in all its glory, and they talked about the work it takes to refactor stuff like that (which is extensive).
The VAST majority of online serving code at Facebook is written in Hack (PHP) and is part of a gigantic codebase called fbwww. Backend services that do heavy lifting (mostly search, feed ranking, ad matching, TAO, various caches, proxies, etc) are fairly light on business logic and written in C++.
It isn't a microservices architecture at all: they only move stuff to C++ for latency and efficiency reasons. For instance most of the ad stack is written in Hack, but certain key pieces use C++ for better performance. I'm not aware of any Java or Go code that is part of the online serving stack.
Its just an observation of having worked on systems at scale and I dont see the microservices / containers used.
I am curious if anyone else has.
The more I am around containers and the network complexity/issues that are created the less I am convinced it is the most optimal way and I am looking for opinions that differ from mine so I can learn
This is like the guy in these threads saying $400k a year for a software engineer is "market rate" and/or "easily achievable."
Microservices are probably a bad idea (for now) if you aren't large enough for such a team.
But you've constructed your question to exclude the companies that work this way, which I think any reasonable person would call "at scale."
[citation needed]
So "only" everything except UI (which is run by the browser, not FB's servers), then. And that's only for browsers that use it at all, as they still need to render a lot of stuff from the servers both for speed and for people who turn off js or use older or limited browsers.
And this is a weird thing to say anyway, nothing runs "on" react; both the framework(s) and the business logic run on something else.