Intel doesn't know how to be a foundry, Tim Cook reportedly said in 2011
tomshardware.com
tomshardware.com
I have no insight into the customer facing side
If you're an Intel foundry customer, you don't want your design or IP leaking across to Intel's product team, who might be a competitor.
That's like asking what could you learn from building plans ...
Tribal knowledge doesn't appear on management org charts or in human resource titles.
By any rights, the major systems manufacturers of the 2000s—Cisco, Dell, HP, IBM, Sun Microsystems—should have had an enormous leg up in becoming the planetary scale, "red shift" cloud computing providers of today. Let's kick major operating environment vendors of that era in for good measure—Microsoft, Red Hat, VMware. Maybe even Oracle and SAP. They had the technical capabilities, the economies of scale, the vendor ecosystems, the customer relationships, the financial might. "Permission to win." Yet, only a few have made it. Microsoft has made the transition with Azure, but it's been a long hard pull. Maybe a few participation trophies for IBM and Oracle. But as a group, where are they, cloud-wise? Not too impressive that AWS and Google and others that had no classic "required assets" or "permission to win" have wiped them off the playing field or kicked them deep into the "others" bin.
You can call that classic innovator's dilemma, and there's a lot to that. It's insanely, unfathomably hard to disrupt your own current successful business for new delivery models and aspirations. But there's something else as well: services and products are different beasts. They take different mindsets, expectations, business models, and metrics. All the best to Intel in becoming that new thing, a service provider. But it not just a side gig or slight extension. It's a radically different thing, and it's no wonder the highly successful product Intel of 2011 wasn't also a good service provider.
GCP and AWS came out of product focused companies that effectively converted to providing the services they used internally.
From a technical perspective, App Engine and Compute Engine were built on top of internal infrastructure (borg), but did not expose borg directly. And there were a number of interesting mismatches between the semantics that customers expected of VMs and what borg offered to its containers that eventually resulted in dedicated borg clusters with different configs for cloud. And some retrospectives on whether building on borg was a better option than going bare metal directly.
Org-wise, the App Engine team was first and not part of the internal-focused Technical Infrastructure teams. GCS came next, and it too was not part of the canonical storage org. Then GCE, which was only possible because it was either written off or at least tolerated as an experiment by most, with a few key people providing behind-the-scenes support to make it happen -- especially in networking. It likely also helped that GAE was in SF and the rest of GCP in Seattle/Kirkland initially, so geo provided some insulation too.
The dominant perspective internally was that Google's technical infrastructure was its secret sauce, so why would they give it away to others? It took a long time to change that.
[Disclosure/source: I was on GCE and helped get it launched.]
http://www.quora.com/How-and-why-did-Amazon-get-into-the-clo...
AWS was always purpose built and designed as a new product and Amazon Retail has a completely different architecture from AWS.
True, now some Amazon workloads have been moved over to AWS. But Amazon Retail is treated like an AWS customer.
Even internally, AWS employees use a different system to stand up internal sandboxes than CDO (Consumer Division Operations).
But they didn't and they aren't, and it doesn't matter anymore.
I am not trying to generate a phylogenetic tree of cloud services, but show organizational shift that allowed Amazon (the whole company) to be successful by enforcing cell walls.
We would agree that Amazon is a services platform? Both in retail as well as cloud?
GCP itself is an application that rides on Borg, but Google itself does not use GCP. So it never got the recursive self improvement effect that Amazon did.
But I will agree that Amazon is a services platform internally and externally.
But Amazon for the most part doesn’t run on AWS either and never at any point has Amazon Retail (CDO) and AWS shared any underlying architecture not even to the point that another commenter here who worked at Google described about GCP. Some of the new initiatives might. But AWS treats Amazon Retail as a customer and I heard ruminations that AWS Commercial Professional Services (the consulting division) even got involved with Amazon Retail projects or migrations.
I worked in the public sector division of ProServe (WWPS).
The only myth listed in your link is that Amazon made AWS to sell off excess computing capacity during periods of downtime.
This is from the CTO of Amazon himself:
>At Amazon we had developed unique software and services based on more than a decade of infrastructure work for the evolution of the Amazon E-Commerce Platform... The thinking then developed that offering Amazon’s expertise in ultra-scalable system software as primitive infrastructure building blocks delivered through a services interface could trigger whole new world of innovation as developers no longer needed to focus on buying, building and maintaining infrastructure.
There is almost no similarity between AWS and CDO. I’m telling you this as someone who worked on the inside.
At most they took some of the things they learned. But it’s not like they took the code from any Amazon Retail implementation and did the equivalent of a “git checkout -b aws”
S3, SQS and EC2 the early AWS services were not based on the Amazon Retail systems at the time.
The entire control plane of CDO is completely different than AWS and always has been
If you want to see what services look like thst started out on Amazon Retail and moved over to AWS with few modifications - look no further than Amazon Connect. It was a lift and shift of the call center software that Amazon Retail uses without any AWS integrations or even publicly available APIs at first. It’s gotten better since 2020 when I was at AWS.
AWS exists because Amazon had already developed the know-how and expertise in how to deliver computing infrastructure as a service and saw that offering this as a service to third-parties would be profitable. The only myth is that Amazon wanted to sell off excess computing.
Most people think the former and even now people seem to think that there is any similarity between how Amazon Retail (CDO) and how AWS runs. Again with the caveat that some of Amazon Retail’s workloads have been migrated to AWS or were born on AWS.
You seem to think the original claim is that someone took code from CDO and built AWS off of it, and no one said that. The simple claim which is reinforced in the very Quora link you provided is that Amazon had developed expertise in delivering computing infrastructure internally, and decided it would be profitable to offer this service externally.
Your claim that most people have a very specific belief about an implementation detail regarding whether literal code was reused or transferred is almost certainly false. The belief is that a company that developed expertise in an area that proved to be invaluable internally managed to leverage that expertise into a new product line that they could sell to other people, and nothing you have provided contradicts that.
“GCP and AWS came out of product focused companies that effectively converted to providing the services they used internally.”
They at most used thier know how. You and I are in agreement. But that’s not what is implied by the parent.
And GCP more or less started out as a classic PaaS. Azure really had more of an on-prem focus at first.
AWS: Bezos API memo -> internal infra services that were external ready -> polishing and exposing those one-by-one
GCP: Internal architectural/technical excellence -> new org that attempted to productize v2.0 of those services
Azure: Believe it was mostly ground-up build as a new org/product?
(No idea where Oracle cloud came from, internally)
http://www.quora.com/How-and-why-did-Amazon-get-into-the-clo...
AWS started from a one pager that two employees in the Capetown office wrote (forget their names, it's been years) about the potential to sell compute as a service from the newly revamped Amazon.com website backend and servers.
Once the commercial viability was clear, Amazon.com created Amazon Web Services. The term 'offshoot' is perfectly reasonable.
This is from working at AWS circa 2013, which was just a few years after it started.
Have you seen the difference between the architecture of CDO and AWS internally?
That is the Original Title. It could be edited as "Tim Cook told TSMC in 2011 that Intel did not know how to be a foundry" - That would still have been accurate with the date on.
Now the title has been editorialised, and meant or imply something else. Like most of the comments are already suggesting.
If you are interested in getting more context on TSMC, this is a great place to start.
https://www.acquired.fm/episodes/tsmc-founder-morris-chang
A tiny bit of this (excellent!) interview led to the story we're all commenting on.
The implication was that Intel lacked the customer-centric mindset required for a foundry business. Unlike TSMC, which tailors its process technologies to meet customer needs, Intel was used to designing and producing its own chips and struggled to adapt to servicing external clients. By contrast, Apple valued TSMC's ability to listen and respond to specific demands, something Intel historically did not do.On the other hand I can appreciate that Intel chips are more of a known quantity than the various ARM designs that are floating around out there.
Subdivisions that only work for one customer grow around all their idiosyncrasies and it's hard to adapt later
Actually putting the design work into something you can work with is hard work
You try to do something different, and every business process and management member is there to stop you because of what they learned previously … when working with a different customer or market.
The Steve Jobs story about resistance to developing a mouse in house is a good example.
https://www.youtube.com/watch?v=s4Cz49MLh4o
The general topic applies to what I mentioned but even just the specific mouse story is at this point in the video:
https://youtu.be/s4Cz49MLh4o?t=90
Folks who operate in a certain context / process or such and just can't imagine doing any differently and will stop you.
Companies just don't get it, that customer service is almost always the most important aspect of the company. The customer will put up with a lot of bullshit if communication is rock solid.
Handing off your customer service to agents that don't have reading comprehension, who don't have any authority, or who are completely non-understanding is going to hurt business.
And I'm not talking about customer service that can write flully emails thanking and apologizing and butt kissing, I'm talking about good customer service is when the agent understands the request, takes it seriously, runs it up the flag pole if needed, and can act on it.
Customers do come up with a bonkers ideas / UI that's horrendous or just unworkable internal logic. And yet if I sit with them and we talk about "what can we do to solve the problem / enhance the product / get your goal done" I find they often come up with some good ideas and are happy to discard their initial madness.
The current vision is very different: It's to somewhat separate the fabs and Intel's products, and the end goal is that Intel Products will just be another Foundry customer.
Whether they can achieve this is another story.
Apple’s senior leadership has always for better or worse had long memories and held even longer grudges. And they don’t like partners to speak for them, or create the impression—even if accurate—that Apple has a dependency on a single supplier.
But who is going to replace TSMC? Sure someone will in 15-20 years, but for now...
https://www.intc.com/news-events/press-releases/detail/1716/...
> Third-quarter GAAP earnings (loss) per share (EPS) attributable to Intel was $(3.88); non-GAAP EPS attributable to Intel was $(0.46).
The first 10nm chip Intel actually got out the door (in tiny quantities) had the entire GPU disabled because their high-density transistor library was broken. That's exactly what Apple would have been using for most or all of an Intel-fabbed iPad chip, so Intel would have not been able to maintain the fiction that their 10nm process was mostly or even somewhat healthy.
But actual company itself and products are bleeding internally from decades of mismanagement.
https://www.tomshardware.com/tech-industry/semiconductors/ta...
https://www.techpowerup.com/331104/tsmc-granted-government-p...
https://www.reuters.com/technology/tsmc-begins-producing-4-n...
So a blanket tariff would definitely apply even to the production of that plant. Which is why lots of CEO's (including Tim Cook) are trying to suck-up to Trump right now, to get an exception made for their imports.
If America wanted EULV fabrication, it had to be organized and funded by the state. American fabs already made their business decision.
It's pretty widely known and documented that Intel at that time was in a horrible position to be a foundry for outside designers, especially ones that wanted to be able to design for more than one foundry.
The DoE funded initial research in to EUV via the national labs and EUV LLC back in the 90s. The IP was licenced to ASML, whilst Canon and Nikon (the leaders in lithography at the time) were blocked.
We have had multiple rounds of "why are we paying for any of this?" In our federal government since then.
TFA says that the "Intel just does not know how to be a foundry" quote is from 2011 (14 years ago), and referred to Intel's lack of a "customer-centric mindset" rather than specific manufacturing capabilities.