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.]
I'll reply to myself since the parent comment is unalived.
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.
I killed my reply because it was repetitive with my other reply and not well thought out in hindsight.
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 Quora link reinforces OP's point though, it doesn't contradict it at all.
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.
Even today, if you look at the architecture and systems used by CDO and AWS, it’s clear that AWS was designed from the ground up to be sold to customers. The architecture used by Amazon Retail was not suitable for third party customers.
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.
But none of those claims contradict the point that was made. It's not really clear what you're disputing.
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.
There is a huge difference between “we have the know how to create AWS” and “we used spare capacity to sell to customers” or “we took code we used from Amazon Retail and created AWS”.
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.
Exactly, there is a huge difference, that's the point!
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.
AWS was obviously not going into building datacenters and taking a modern service oriented architecture approach cold. But, as you say, the pervasive myth is that AWS started out by using excess retail computing capacity and presumably the same architecture which, by all accounts, is simply untrue.
And GCP more or less started out as a classic PaaS. Azure really had more of an on-prem focus at first.
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.
It's rare but does happen. And frankly I'd only include AWS in the counterpoint. Google really struggled with GCP. Outside of Bigquery and Spanner many/most of the services were custom built for GCP and were not used internally. Hell they built a VM service when basically everything ran on Borg internally
GCP and AWS came out of product focused companies that effectively converted to providing the services they used internally.