Facebook is the creator and maintainer of the most popular web framework in the world (React). This certainly doesn't mean they should do cloud computing, but let's not downplay their favor amongst developers.
The correct statement is some developers don't like Oracle. As for their business tactics, every business has to find viability in its own way. Obviously Oracle is providing services of value if they are able to consistently turn a profit on revenue in the tens of billions per year. This doesn't really answer the question why Facebook is not in the cloud business.
> Obviously Oracle is providing services of value if they are able to consistently turn a profit on revenue in the tens of billions per year
Not obvious; Oracle is known for underhanded marketing and lock-in. Or if you prefer: Successfully selling to the C-levels doesn't mean that you provide actual value.
Right, because C-level types are just spending $30B a year on Oracle services for zero value added. You shouldn't take your own opinions on a provider's services too seriously. No doubt there are some practices that are subpar but like any competitor in a crowded marketplace, there are going to be trade-offs between cloud providers. If the trade-offs between price, features, and value align with the needs of an organization, they will choose Oracle. That C-suite and devs have different needs shouldn't surprise you. There's always going to be some tension between those two groups, because their perspective on the business is filtered from a different set of parameters. That tension, by the way, will necessarily create a demand for different services and functions in the marketplace. You may not personally like Oracle, but don't pretend that some people don't, and don't imagine for one moment that it's purely out of ignorance.
Frameworks and Infrastructure tend to get chosen by different people with different requirements though.
"Move fast and break things" is okay/great if you can control the deployment of code and use tests to make sure it still works how you expect it to. It's less great if the infrastructure keeps failing (it's not failing, it's changing!) and you can't test before the roll out.
No, developers don't like React because of an infrastructure supported by Facebook. React is entirely selfhostable, and only as secure as your own dev environment. Built as an open sourced tool, with major contributions from thousands outside of FB.
You can't compare the two and their safety anf 'favor among developers', devs also fought against FB by having them change their licensing bc FB made the horrendous decision to essentially own any and all projects developed on it.
React is a piece of code that is versioned which the developer has full control over. A cloud service would be entirely controlled by Facebook, meaning your business can be bricked by Facebook on a whim, as has happened to many Facebook-hosted apps in the past. There's a reason why few take Facebook seriously as a developer platform these days.
Products and services have a very different risk profile. With products you generally can vet a lot of risk up-front, with services, you have more risk tied to future activities.
Google has never been implicated in a plot to hack the U.S. presidential election. Now, I don't actually Believe that the ads displayed on facebook had any real impact on how people voted. They were never on screen for very long, and they took up a small percentage of screen space compared to all the other user and advertiser generated content. But Zuckerberg did testify before congress on live TV and that's what people are going to remember.
Google and Twitter were targeted by the Russians as well. They just didn't go public when they found the evidence, unlike Facebook, until after Facebook did. Facebook bears the brunt in the press because it screwed over the press so much in recent years.
Not saying Google is an angel, but at least I don't recall them collecting phone numbers for 2FA while promising to not use them for ad targeting and then silently doing so.
This thread is filled with comments about how people don't trust Google enough to use GCP. It's hurting them too, and given how far behind AWS and all they are, it's a serious hurdle to overcome
The only reason anyone would ever call targeted ads "selling your data" is to make people who don't fully understand it believe it's scary. Completely misrepresenting what they are doing.
How about we, as a collective, say it for what it is instead of using words that mean something completely different and let people come to their own opinions instead of thinking for them?
The big miss for Facebook isn’t cloud computing platforms, but mobile platforms. Mark has admitted this himself when asked what his mistakes/regrets are. It was easy to miss in the context of social’s massive growth. But the dust is settling and it is clear that mobile platforms hold tremendous power over consumere.
I think you give Facebook too much credit for repositioning themselves. Facebook and the news feed was a natural product for mobile. There was no pivot at all. They merely saw where user attention was going and built for that surface. I would argue they got off track by building for mobile "web" and thinking native APIs weren't important. Then they course corrected. But I think the miss here is that social connectivity was a new thing happening to software and they could have made a strong play to influence the direction of the mobile OS. They don't have much leverage now.
Facebook did a huge company-wide refocus on mobile at a time when it was not at all clear smartphones were going to become the dominant platform. I really do give zuck et.al. a lot of credit for seeing that coming [source: I was an employee at the time]
It was definitely popular. It used to be the go to solution on r/AndroidDev for people wanting a simple backend solution without having much experience. Everyone switched to Google Firebase after Facebook shut it down.
The difference is that Parse ran on AWS. In my opinion, the real reason Facebook isn't in the cloud business, and why Parse was eventually shuttered, is that Facebook will never allow external code to run anywhere in their network.
Parse doesn't seem to have been any kind of general-purpose cloud at all.
Rather, it appears a highly targeted backend specifically for mobile apps only. The article says "back-end services for data storage, notifications and user management".
They're some pieces of a cloud, for sure. But it's worlds away from the general-purpose offerings like AWS and Azure that the author is talking about. So not surprised the author didn't bother to mention it.
because selling ads is higher margin business and more profitable.
they used to sell data (cambridge analytica etc) and that was also very profitable, not sure how it is now
I was under the impression they ran a variety of Facebook personality quizzes and aquired the data through that against the Facebook TOS. Do you have a source for them "buying them" from Facebook?
This is "fake news" (I hate this term but it seems very relevant in this case).
As far as I understand Cambridge Analytica used the publicly-available Facebook APIs to create a stupid web app (a personality test or similar) which asked users to log in and hand over a lot of data (both about them and about their friends).
While their end-goal was against Facebook's ToS, I don't think there's anything they could've done about it ahead of time as 1) removing those APIs would hurt legitimate usage (let's say for example I am building an alternative client or similar - I want to be able to see my friends' data on there) and 2) it is still the user that is willingly giving out their and their friends' data when logging into such an app (and Facebook makes it clear what data the third-party service will be able to access when you first log in).
In short it's idiots logging in and delegating their permission level (which allows them to see their friends' data) to a malicious third-party. Facebook isn't really to blame there. It's no different from someone telling me a secret and then I go around and tell it to everyone else.
This is also true for Google, though. Cloud is a low-margin business compared to everything else Google sells, and the bigger cloud becomes the worse Google's quarterly reports look.
Because that's not what they do, and they're too late to the game. From ex-Google friends who work there, FB's own core infra lags Google's by more than a decade in many cases.
One thing I like about Facebook, evil aside, is how Zuckerberg-centric it seems. They spent two billion on Oculus because Zuckerberg liked Ready Player One and thinks the chance of that is awesome. Zuckerberg publicly released a machine learning project in college and now Facebook is spending more on machine learning than anyone.
If you had effectively infinite money to make any idea you can think of into reality, would you use it building cool things that you are personally interested in, or would you use it to start another cloud company dedicated to prices so high it's practically highway robbery?
It would make sense if Facebook was ran by Larry Ellison, but money is pretty pointless as an end itself.
I don't think so; it seems like most of Facebook's decision-making in terms of expansion is arbitrary and whim-based. He admitted to that being the reason he bought Oculus.
It's possible that they are less focused than similar companies, but I would expect that it takes more to seal an acquisition than Mark Zuckerberg just going "let's buy that company, they look cool" and it being done.
Given google is already starting down the ultimatum path, seems like there's not space in this game outside of the big two. Probably a good business move not to get involved.
I don't think the positions are set though. We'll always want more compute, storage and smarter platform that is reliable and affordable.
As long as Google keeps on positioning itself as reliable and does a few things really well, they'll win those segments. They're already doing that with K8S but their recent emails about per hour pricing was just stupid. It sends a message that their VPs just don't understand what people really want.
Facebook's data center planning team for the last several years has been steered pretty effectively by engineers from "the Seven Sons of National Defense".
This is a term from the US Intelligence Community that refers to the 7 most prestigious universities in China that support the People's Liberation Army. This includes "Beinhang University" and "Northwest Polytechnical University". These schools are closer to the Army in China than say Westpoint is to the Army in the US. These schools guarantee some of the best paying jobs in all of China, and if you desire, a chance to reach the upper strata of the CCP hierarchy. For this, reasonably I think too, they expect a pretty large amount of loyalty measured in decades.
They have overruled consistently (there is nothing wrong with this I am just saying there were objections often) to massive capital infrastructures that make no sense in Facebook and that has always driven the finance people wild.
I don't think there is a conspiracy here. I do think that a lot of specific Chinese hardware manufacturers have gotten very very rich off of these decisions. Their architectural decisions are certainly really strange. They tripled-down on blueray DVD storage in 2009, even though massive cheap flash, then NVMe, then NVMe EVO Plus rolled out in quick succession.
All of these clouds are spawned out of already-large tech companies, many of whom have built a massive technical infrastructure to support their original businesses, then turn those resources into services to rent out in the form of cloud
This is a myth that’s been disputed several times by high ranking Amazon officials. Amazon never turned their internal infrastructure into AWS. It was always a completely separate initiative. Amazon was not on AWS for years.
Google also only uses GCP for a few internal services.
Wrong; it's true. I work on Google Cloud Storage. There are multiple layers of sharing at varying depths. The externally visible APIs to cloud storage are the tip of the iceberg, and the iceberg is very, very deep.
Assuming the basic assumptions hold. Google for example doesn’t really care much if individual searches are slightly less accurate so low data center temperatures should be less important for them than say a financial institution. https://www.cnet.com/news/google-computer-memory-flakier-tha...
Facebook’s hardware designs might generalize well, but perhaps not.
I...I don't think the article you're quoting supports your conclusions. It concludes that running (slightly) too hot doesn't meaningfully impact error rates, and that even if you run at the recommended temperature, memory errors will happen anyway.
So the conclusion is that, whether you're a financial institution or Google, you need ECC, at which point running too hot doesn't have any appreciable effect anyway.
“Previous research, such as some data from a 300-computer cluster, showed that memory modules had correctable error rates of 200 to 5,000 failures per billion hours of operation. Google, though, found the rate much higher: 25,000 to 75,000 failures per billion hours.”
First it’s old data, but google having observed higher error rates suggests different choices. Location, power supplies, motherboard design etc can all play a role. Further, they should be optimizing for slightly different things. Finally, they got data for temperatures from running their actual production system at these temperatures while assuming it would cause even more problems.
> but google having observed higher error rates suggests different choices.
Alternatively, it suggests better data from a larger, real-er world study.
>Finally, they got data for temperatures from running their actual production system at these temperatures while assuming it would cause even more problems.
I'm not sure what you're saying here. To be able to detect the effect of temp, they ran at both higher and lower temps and compared.
Better data, is unlikely to be the cases as these are simply reports of ECC faults. Every large data center can collect this information equally easily. The ranges are simply for location or time specific variations not some uncertainty metric. You can read other articles about their hardware choices and why that may be an issue.
> Every large data center can collect this information equally easily.
Right, but they aren't published in controlled studies, usually. The article mentions that prior to the Google study in question, the next best example used 300 machines.
So yes, compared to contemporary (and since then!) public studies of ECC faults, I'd say that the Google study is pretty darn authoritative. You're welcome to cite other recent examples to the contrary though (with DDR 1 and early DDR 2 RAM, of course. Modern sticks fault less).
> The ranges are simply for location or time specific variations not some uncertainty metric.
I'm not sure what you're talking about. Section 5.2 and 5.3 of the paper is about the effect of temperature and utilization. It shows that temperature has a negligible effect when controlling for utilization, while the reverse is untrue.
I disagree that 300 computers was simply not enough data to be useful benchmark. But, you can find studies using more RAM if you go looking.
Supercomputers of that era had far more than 300 nodes, and you can find studies of their memory error rates. The Roadrunner supercomputer for example had 19,440 compute nodes with 4GB of ram each.
PS: The architecture was odd with 6,480 Opteron processors and 12,960 Cell processors + 216 System x3755 I/O nodes, but it’s still using commodity RAM.
Just one example among many for the Jaguar supercomputer, with 18,866 nodes using DDR2. https://arch.cs.utah.edu/arch-rd-club/dram-errors.pdf. 250,000 correctable memory errors per month so quite a bit of data to work with.
This is simply a low effort type of paper on an important issue. So, there are plenty of them out there.
Many of GCP's services did actually grow out of Google's internal tools. For example, BigQuery is a public version of Google's internal Dremel. And Cloud Spanner is of course a public version of Spanner.
Yes, Kubernetes's design was inspired by Borg, but the code is not Borg's code. BigQuery and Cloud Spanner use most of the code of the internal versions. That's the difference.
But this is still backwards. Internal google services are being cloned into watered down versions for the public. Google isn’t moving to GCP internally.
EMR was obviously inspired by Google. And arguably the whole idea of using huge numbers of cheap x86 machines, rather than more expensive servers was inspired by Google’s search architecture.
Technical infrastructure = ability to build and run cost-efficient data centers at scale.
I'm not sure anybody's ever seriously claimed the software infrastructure was the same. The "origin myth" of AWS I've always heard is that many of their servers were going unused outside the Christmas season, so AWS was a way to monetize them the rest of the year. At a hardware level.
So all these tech companies have been able to leverage their technical infrastructure -- the hardware one.
There are many conflicting stories about the origin of AWS, but the whole "our infra is underutilized except during Christmas, let's rent it out!" is one that I never hear repeated by anyone with any claim to knowing what was actually happening. I think it's an "Omidyar Pez Dispenser"-tier story: fully bullshit.
It kind of doesn't even withstand a moment's scrutiny. What was Amazon going to do during Christmas? Like, if they lease all this spare capacity during non-peak, what happens to those customers during peak? There are spot instances now, but the first two AWS products, S3 and EC2, didn't come with some sort of, "Except during peak" contract. So Amazon needs exactly as much hardware to meet demand during Peak as it did before, and now it's got a bunch of customer workloads it also needs to serve during peak. I don't see how this would've solved any problems.
Most stories about the origin of AWS have a few things in common:
(1) There was limited support for the idea of AWS at senior executive levels
(2) The early AWS products were not used by for any significant Retail workloads within Amazon for quite a long time (as in, several years)
(3) As recently as a few years ago, there were major organizational pushes to move legacy Retail workloads onto AWS
(4) As recently as last year, there were still so many teams on Oracle that everyone with an Oracle dependency was required to have an OKR to get off it. I include this because IIRC this is public-- after Oracle was making hay with the "Amazon sells Dynamo/RDS but runs on Oracle" campaign, Amazon publicly released information about their Oracle Annihilation roadmap. So it supports the theory that it's taken Amazon quite a long time to shift certain Retail workloads to AWS, even in cases where an AWS product that's suited to the workload has existed for quite a long time.
I've never worked for Amazon, so I don't know, and it's impossible for all the stories I've heard from ex-Amazon people to all be true, but I think there's a pretty good argument against the "we should put this spare off-peak capacity to use" AWS origin myth.
I could totally imagine them being at capacity and buying more servers for Christmas in October then after Christmas renting the excess out all year (Jan thru dec). Then in October buy more server again, rinse repeat. Sell 2019s Christmas burst servers starting in 2020... How does that not pass the sniff test?
Obviously they wouldn’t pull the rug from folks and spot didn’t exist, but that doesn't mean it didn’t happen that way.
I guess I meant the web advertising business. Since they are the premier site hosting service, the dream would be to launch a site and have it pay for itself with ads, but they haven't gone there for some reason.
Or search. Seems like they could give Google a run. I'd assume they have the infra and the expertise. I'd also assume someone there has already had that idea and run the numbers and decided against it. Maybe they have a gentleman's agreement with Google that they won't compete and Google will reduce their ad rates.
They already do give Google a major run for their money in probably the most important search category - product search, where they have a 54 percent market share. That's the most ad friendly category - people looking to buy stuff! When you want to buy something - how often do you type it into Google, versus go to Amazon and type it into their search bar? I really doubt there's a gentlemans agreement - bezos does not seem like that kind of guy, and they are really causing a lot of pain for Google eating into what should be one of their most profitable advertising streams.
While they have competent infrastructure, an IaaS offering needs a platform whose capabilities are more complex than one where you're running only first-party applications. And even if they spent the time and effort, they'd be entering a commoditified, crowded field. All the big players can run servers, the value-add is from SaaS and/or surrounding PaaS, the latter of which they'd have to build from scratch.
Their previous forays into PaaS, done at a time when Twitter was also in this space, have faltered. And Facebook's pre-existing services are too far up the stack to be relevant to any IaaS ambition.
I doubt the 'trust issues' contribute significantly in Facebook's decision to not offer this, but I agree they'd be a factor for potential customers once the offering came to be. Facebook's branding is odd in that they've doubled down on the Facebook brand despite acquiring services that flourished in part for being "not Facebook". They seem resistant to rebrand into a holding company, and their choice supports the view that the company's tech mission is to remain tightly coupled with their flagship social network.
Without first-mover advantage, without the enterprise sales network it would be just foolish for FB to waste their time and energy on such highly competitive field without much of natural advantages. You don't really synergize social media with cloud infra.
And they know it too, so they rather compete in fields where they are good at, namely social media and apps. Maybe its part laziness, part lack of interest on their part too. But to me it would be wiser to focus on some promising new areas, rather than start catching up 2 laps behind the competition. Yet it's not easy, like VR/AR market shows. Maybe in ML services they could challenge Google a little more.
I'm not sure many people would be keen on deploying their entire cloud on Facebook either. Forget about privacy concerns and all that, it just doesn't make sense when they have the 'move fast and break things' philosophy.
The last thing you want in high availability cloud infra is a team of engineers who will sacrifice stability for innovation.
Even if they did do it, there's not a chance they could launch it under 'Facebook'.
Do they have a "move fast and break things" philosophy in 2020? I know they did a decade ago, but is that still true today? Further, does that philosophy apply to their core infrastructure, or just leaf-node feature development? Is there any indication that Facebook's cloud infra team sacrifices stability for innovation? When was the last time Facebook had a major outage that was traced to some core service? How does their infra track record stack up to AWS (I'm a happy AWS customer, but their infrastructure flakes on us in a major way several times per year)?
> You don't really synergize social media with cloud infra.
I think your first-mover and competitive industry points stand, but I don't see how retail and search synergize better with cloud infra than social. The cloud infra business model is (as far as I can tell) just building general purpose computing-at-scale features in a reusable, billable way and selling those to consumers. VM/container/database/serverless/etc orchestration isn't more aligned with retail than other businesses as far as I can tell.
Well with retail you are kind of already in the business of buying and selling hardware, so to me it doesn't seem that big of a stretch. In both you are handling big volumes with very high emphasis on cost-margins.
Search, yeah. Intrinsically maybe not, but Google has some very skilled engineers and researchers, who have pioneered a lot of the modern cloud applications/algorithms eg Borg/k8s, MapReduce, GFS and so on. So they have the know-how on how to build topnotch services, just not maybe as good business-savviness to sell them.
I wouldn't be surprised if they eventually did enter. I don't use FB personally, but I'm a big fan of the OSS efforts.
> biggest hurdle is trust, given its problematic record on data privacy
It is? FB is a corporation - much like Apple, Microsoft, Google & Amazon. Each of those have had their fair share of issues throughout the years.
Too easy to be polarised with stuff like this. FB produced good tech and supports it too - which is more than I can say for Google. But I'll use Google for their search & docs products, which is top notch. There are no heroes/villains.
Google and Facebook have particularly not-great privacy reputations because they are advertising companies whose business models are precluded on collecting your personal info.
Counterintuitively, you are more likely to be better at privacy if you are in the business of selling data, especially in the current regulatory climate.
The websites that have been the worst at maintaining my privacy were those that primarily sold physical products or medical services. You'd be amazed how many organizations broker data now.
You make money if you are the #1 or #2 player in a market. If you are more like #4, you will just lose money. If Facebook tried to enter the cloud market today, they would be way behind. Without a unique advantage that would induce customers to switch, why would anyone switch? And if they tried to compete by cutting prices they would just lose money.
I agree with your statement, but there's still a lot of room for improvement. AWS is dominant, but their software/tools are horrendous. Their web admin UI looks, feels, and has the general usability of some horrible Java enterprise tool designed by a committee of Windows developers in the mid-00s, because that's exactly what it is. I don't know how Azure and GCloud compare, but they cannot possibly be worse. AWS does what people need, but I don't know anyone who likes working with it. Except maybe Windows admins from the 00s.
Agreed, I feel like AWS has the worst UI of them all, followed by Azure's Metro/Visual Studio-style UI and then GCP is OK on the UI front, but lacks when it comes to monitoring and configuration options for things like CloudSQL for example.
Yeah. My AWS experience is on small-scale deployments--up to a few dozen servers. It's painful to manage them through the Amazon UI. When I left that client, the devops team there was transitioning to TerraForm and other deployment and configuration systems, and connecting to in-house monitoring systems. That's the right approach. It's out of reach for smaller teams who can't afford the extra engineering; they're better off with something like Digital Ocean. DO has a fantastic UI and a decent API, but doesn't support anywhere near the level of enterprise features that AWS does.
Omg.. yes. Their UI is awful. CloudWatch gives me ulcers. But! At the same time, infra engineers live on the command line using their CLI and what not.
I feel seen and heard. AWS' console, client libraries, documentation, naming, etc. never fail to disappoint. Do I think Facebook would do better? No clue.
I had a chunk of credit to spend on GCP, and it's been much better, and seems to be about the same price. (We went with AWS at work because, at the time, it was simply cheaper for us).
Dev facing FB interfaces are hard to navigate and chaotic. Not a fan personally.
What would be interesting though is infrastructure that leans on what they know best in terms of architecture and development.
GraphQL APIs, React frontends, PHP, JS, MySQL... Stuff that works for them is widely adopted by the webdev world as well and webdevs want convenient, scalable infrastructure.
Oh and they also have people working with/on Haskell right? I bet tons of Haskell devs would love use FB infrastructure if Haskell support was provided. A niche market for sure, but I suspect it is one that longs for something like this.
Google Cloud has an amazing interface, and their new developer experience is really nice. I normally don't have a lot of positive things to say about Google but they definitely did a good job there.
But who really cares? The web console is something that you only use once in a blue moon. What AWS did right was make a workable command line and API so that you don’t have to point and click all day.
Cloud infrastructure requires a massive, massive, massive amount of up-front investment. And below a certain % of the market, it becomes impossible to pay back that investment or even keep it going.
The industry is closer to large airplane manufacturers (e.g. only Airbus and Boeing), search engines (Google and a little bit of Bing), and similar.
Shoes, jam, and hosting services all require minimal investment. (Cars require a lot of investment too, but not at the level of building a cloud. Which is why there are more than 4 brands of cars, but not 4,000 like shoes or hosting services.)
EDIT: In response to comments below, I'm not talking about physical infrastructure here, which does scale rather than being largely up-front. I'm talking about the absolutely massive software investment in tooling and reliability. Not only are you building 1,000's of API endpoints across dozens of services, but you need to also guarantee 99.99% uptime and virtually zero data loss when required. And sure, a company like Facebook is the type of company that can engineer that stuff -- but it still costs $$$$$$$$$$$$ to build.
There are dozens of providers outside of the top 3, like DigitalOcean and Packet. FB already has a massive investment for their own infrastructure so the marginal cost is greatly reduced.
Digital Ocean is doing well. They're #4 as far as I remember. Maybe Oracle Cloud is suffering but that's because no one trusts Oracle - custom chipset or otherwise.
Every large company has certain dependencies (compute, networking, and storage in this case, although you could argue for ex. food service, HR, maybe financial tooling), and those dependencies entail cost and risk, with more risk from using external vendors. So eventually, big enough companies build their own. They build their own datacenters, write their own provisioning tools, design their own network setups, flesh out their own HR departments. And then they look at it and say, "hey, if we can safely sell this, we can recoup the costs of building it, and maybe turn a profit." And if their system is general enough, and they can deal with security well enough, then usually they do just that. Compute is easy to rent out. Networks require some work for security but it's quite doable. HR tends to be too specialized and/or sensitive to resell. (But not always, and sometimes you do see companies reselling employee portals and whatnot.)
336 comments
[ 2.3 ms ] story [ 282 ms ] thread$26.7B in 2019
https://www.forbes.com/sites/greatspeculations/2019/06/21/or...
Not obvious; Oracle is known for underhanded marketing and lock-in. Or if you prefer: Successfully selling to the C-levels doesn't mean that you provide actual value.
"Move fast and break things" is okay/great if you can control the deployment of code and use tests to make sure it still works how you expect it to. It's less great if the infrastructure keeps failing (it's not failing, it's changing!) and you can't test before the roll out.
You can't compare the two and their safety anf 'favor among developers', devs also fought against FB by having them change their licensing bc FB made the horrendous decision to essentially own any and all projects developed on it.
Devs don't trust facebook, such as no one should.
Though I doubt that's the reason GCP is where it is, it doesn't really help your point.
Sure they have. The very same election as Facebook (and Twitter), in fact.
https://www.zdnet.com/article/google-russian-groups-did-use-...
You can't actually buy anyone's data from Facebook, you can only buy ad targeting.
How about we, as a collective, say it for what it is instead of using words that mean something completely different and let people come to their own opinions instead of thinking for them?
As bad as a news outlet.
1) being too late in the game, at this stage.
2) unable to rebrand themselves as a trustworthy service for enterprises. They're stuck with the "social" and "fun" label.
Mobile was the best thing that happen to them.
https://techcrunch.com/2013/04/25/facebook-parse
https://insights.stackoverflow.com/trends?tags=parse-platfor...
The article is referring to IaaS from my initial read.
https://www.facebook.com/workplace
Rather, it appears a highly targeted backend specifically for mobile apps only. The article says "back-end services for data storage, notifications and user management".
They're some pieces of a cloud, for sure. But it's worlds away from the general-purpose offerings like AWS and Azure that the author is talking about. So not surprised the author didn't bother to mention it.
“... a hypothetical ‘Facebook cloud’ could offer very attractive, differentiating services beyond the basics of compute, storage, and network.”
As far as I understand Cambridge Analytica used the publicly-available Facebook APIs to create a stupid web app (a personality test or similar) which asked users to log in and hand over a lot of data (both about them and about their friends).
While their end-goal was against Facebook's ToS, I don't think there's anything they could've done about it ahead of time as 1) removing those APIs would hurt legitimate usage (let's say for example I am building an alternative client or similar - I want to be able to see my friends' data on there) and 2) it is still the user that is willingly giving out their and their friends' data when logging into such an app (and Facebook makes it clear what data the third-party service will be able to access when you first log in).
In short it's idiots logging in and delegating their permission level (which allows them to see their friends' data) to a malicious third-party. Facebook isn't really to blame there. It's no different from someone telling me a secret and then I go around and tell it to everyone else.
If you had effectively infinite money to make any idea you can think of into reality, would you use it building cool things that you are personally interested in, or would you use it to start another cloud company dedicated to prices so high it's practically highway robbery?
It would make sense if Facebook was ran by Larry Ellison, but money is pretty pointless as an end itself.
As long as Google keeps on positioning itself as reliable and does a few things really well, they'll win those segments. They're already doing that with K8S but their recent emails about per hour pricing was just stupid. It sends a message that their VPs just don't understand what people really want.
This is a term from the US Intelligence Community that refers to the 7 most prestigious universities in China that support the People's Liberation Army. This includes "Beinhang University" and "Northwest Polytechnical University". These schools are closer to the Army in China than say Westpoint is to the Army in the US. These schools guarantee some of the best paying jobs in all of China, and if you desire, a chance to reach the upper strata of the CCP hierarchy. For this, reasonably I think too, they expect a pretty large amount of loyalty measured in decades.
They have overruled consistently (there is nothing wrong with this I am just saying there were objections often) to massive capital infrastructures that make no sense in Facebook and that has always driven the finance people wild.
I don't think there is a conspiracy here. I do think that a lot of specific Chinese hardware manufacturers have gotten very very rich off of these decisions. Their architectural decisions are certainly really strange. They tripled-down on blueray DVD storage in 2009, even though massive cheap flash, then NVMe, then NVMe EVO Plus rolled out in quick succession.
I recommend this report and web app from the Australian Strategic Policy Institute: https://unitracker.aspi.org.au/.
This is a myth that’s been disputed several times by high ranking Amazon officials. Amazon never turned their internal infrastructure into AWS. It was always a completely separate initiative. Amazon was not on AWS for years.
Google also only uses GCP for a few internal services.
Facebook’s hardware designs might generalize well, but perhaps not.
So the conclusion is that, whether you're a financial institution or Google, you need ECC, at which point running too hot doesn't have any appreciable effect anyway.
First it’s old data, but google having observed higher error rates suggests different choices. Location, power supplies, motherboard design etc can all play a role. Further, they should be optimizing for slightly different things. Finally, they got data for temperatures from running their actual production system at these temperatures while assuming it would cause even more problems.
Alternatively, it suggests better data from a larger, real-er world study.
>Finally, they got data for temperatures from running their actual production system at these temperatures while assuming it would cause even more problems.
I'm not sure what you're saying here. To be able to detect the effect of temp, they ran at both higher and lower temps and compared.
Right, but they aren't published in controlled studies, usually. The article mentions that prior to the Google study in question, the next best example used 300 machines.
So yes, compared to contemporary (and since then!) public studies of ECC faults, I'd say that the Google study is pretty darn authoritative. You're welcome to cite other recent examples to the contrary though (with DDR 1 and early DDR 2 RAM, of course. Modern sticks fault less).
> The ranges are simply for location or time specific variations not some uncertainty metric.
I'm not sure what you're talking about. Section 5.2 and 5.3 of the paper is about the effect of temperature and utilization. It shows that temperature has a negligible effect when controlling for utilization, while the reverse is untrue.
Supercomputers of that era had far more than 300 nodes, and you can find studies of their memory error rates. The Roadrunner supercomputer for example had 19,440 compute nodes with 4GB of ram each.
PS: The architecture was odd with 6,480 Opteron processors and 12,960 Cell processors + 216 System x3755 I/O nodes, but it’s still using commodity RAM.
This is simply a low effort type of paper on an important issue. So, there are plenty of them out there.
PS: If you want to compare here is one for DDR3 https://www.cs.virginia.edu/~gurumurthi/papers/asplos15.pdf
> technical infrastructure to support their original businesses[0], then turn those resources into services[1] to rent out in the form of cloud[2]
[0]: i.e. Borg
[1]: i.e. Kubernetes
[2]: i.e. GKE
Edit: and https://cs.opensource.google. It’s this product: https://developers.google.com/code-search
I'm not sure anybody's ever seriously claimed the software infrastructure was the same. The "origin myth" of AWS I've always heard is that many of their servers were going unused outside the Christmas season, so AWS was a way to monetize them the rest of the year. At a hardware level.
So all these tech companies have been able to leverage their technical infrastructure -- the hardware one.
It kind of doesn't even withstand a moment's scrutiny. What was Amazon going to do during Christmas? Like, if they lease all this spare capacity during non-peak, what happens to those customers during peak? There are spot instances now, but the first two AWS products, S3 and EC2, didn't come with some sort of, "Except during peak" contract. So Amazon needs exactly as much hardware to meet demand during Peak as it did before, and now it's got a bunch of customer workloads it also needs to serve during peak. I don't see how this would've solved any problems.
Most stories about the origin of AWS have a few things in common: (1) There was limited support for the idea of AWS at senior executive levels (2) The early AWS products were not used by for any significant Retail workloads within Amazon for quite a long time (as in, several years) (3) As recently as a few years ago, there were major organizational pushes to move legacy Retail workloads onto AWS (4) As recently as last year, there were still so many teams on Oracle that everyone with an Oracle dependency was required to have an OKR to get off it. I include this because IIRC this is public-- after Oracle was making hay with the "Amazon sells Dynamo/RDS but runs on Oracle" campaign, Amazon publicly released information about their Oracle Annihilation roadmap. So it supports the theory that it's taken Amazon quite a long time to shift certain Retail workloads to AWS, even in cases where an AWS product that's suited to the workload has existed for quite a long time.
I've never worked for Amazon, so I don't know, and it's impossible for all the stories I've heard from ex-Amazon people to all be true, but I think there's a pretty good argument against the "we should put this spare off-peak capacity to use" AWS origin myth.
Obviously they wouldn’t pull the rug from folks and spot didn’t exist, but that doesn't mean it didn’t happen that way.
https://marketingland.com/amazons-booming-ad-business-grew-b...
https://www.searchenginewatch.com/2019/08/01/amazon-google-m...
Their previous forays into PaaS, done at a time when Twitter was also in this space, have faltered. And Facebook's pre-existing services are too far up the stack to be relevant to any IaaS ambition.
I doubt the 'trust issues' contribute significantly in Facebook's decision to not offer this, but I agree they'd be a factor for potential customers once the offering came to be. Facebook's branding is odd in that they've doubled down on the Facebook brand despite acquiring services that flourished in part for being "not Facebook". They seem resistant to rebrand into a holding company, and their choice supports the view that the company's tech mission is to remain tightly coupled with their flagship social network.
And they know it too, so they rather compete in fields where they are good at, namely social media and apps. Maybe its part laziness, part lack of interest on their part too. But to me it would be wiser to focus on some promising new areas, rather than start catching up 2 laps behind the competition. Yet it's not easy, like VR/AR market shows. Maybe in ML services they could challenge Google a little more.
The last thing you want in high availability cloud infra is a team of engineers who will sacrifice stability for innovation.
Even if they did do it, there's not a chance they could launch it under 'Facebook'.
I think your first-mover and competitive industry points stand, but I don't see how retail and search synergize better with cloud infra than social. The cloud infra business model is (as far as I can tell) just building general purpose computing-at-scale features in a reusable, billable way and selling those to consumers. VM/container/database/serverless/etc orchestration isn't more aligned with retail than other businesses as far as I can tell.
Search, yeah. Intrinsically maybe not, but Google has some very skilled engineers and researchers, who have pioneered a lot of the modern cloud applications/algorithms eg Borg/k8s, MapReduce, GFS and so on. So they have the know-how on how to build topnotch services, just not maybe as good business-savviness to sell them.
> biggest hurdle is trust, given its problematic record on data privacy
It is? FB is a corporation - much like Apple, Microsoft, Google & Amazon. Each of those have had their fair share of issues throughout the years.
Too easy to be polarised with stuff like this. FB produced good tech and supports it too - which is more than I can say for Google. But I'll use Google for their search & docs products, which is top notch. There are no heroes/villains.
The websites that have been the worst at maintaining my privacy were those that primarily sold physical products or medical services. You'd be amazed how many organizations broker data now.
I had a chunk of credit to spend on GCP, and it's been much better, and seems to be about the same price. (We went with AWS at work because, at the time, it was simply cheaper for us).
What would be interesting though is infrastructure that leans on what they know best in terms of architecture and development.
GraphQL APIs, React frontends, PHP, JS, MySQL... Stuff that works for them is widely adopted by the webdev world as well and webdevs want convenient, scalable infrastructure.
Oh and they also have people working with/on Haskell right? I bet tons of Haskell devs would love use FB infrastructure if Haskell support was provided. A niche market for sure, but I suspect it is one that longs for something like this.
The industry is closer to large airplane manufacturers (e.g. only Airbus and Boeing), search engines (Google and a little bit of Bing), and similar.
Shoes, jam, and hosting services all require minimal investment. (Cars require a lot of investment too, but not at the level of building a cloud. Which is why there are more than 4 brands of cars, but not 4,000 like shoes or hosting services.)
EDIT: In response to comments below, I'm not talking about physical infrastructure here, which does scale rather than being largely up-front. I'm talking about the absolutely massive software investment in tooling and reliability. Not only are you building 1,000's of API endpoints across dozens of services, but you need to also guarantee 99.99% uptime and virtually zero data loss when required. And sure, a company like Facebook is the type of company that can engineer that stuff -- but it still costs $$$$$$$$$$$$ to build.
Citation needed. If anything, it's the opposite, it scales up very linearly.
ps: i think it will be public cloud someday