3 ms·

This situation has been and maybe always will be common. Those who view themselves as integrated manufacturers of products often cannot equally package, deliv

This situation has been and maybe always will be common. Those who view themselves as integrated manufacturers of *products* often cannot equally package, deliver, and sell their component *services*. No matter how good those services are at delivering the end product—and sometimes they are completely world-class or genuinely unique—they're almost always highly designed, refined, and evolved over years to map to the specific end products and their one business. They are NOT designed, refined, or evolved to be reusable, retargetable capabilities for all interested parties. 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.

gsibble 2y ago
Counter-Point: GCP and AWS came out of product focused companies that effectively converted to providing the services they used internally.
- ethbr1 2y ago
  I'd never really thought about "How did hyperscale cloud providers become cloud providers?" And it's surprisingly distinct. 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)
  - scarface_74 2y ago
    AWS was never an offshoot from Amazon. http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business?share=1 http://www.quora.com/How-and-why-did-Amazon-get-into-the-clo...
    - LinuxAmbulance 2y ago
      That's not true. 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.
      - scarface_74 2y ago
        Again the link I posted was from Werner Vogels. The architecture that the CDO (Amazon Retail) uses is completely different than AWS. Have you seen the difference between the architecture of CDO and AWS internally?
- twunde 2y ago
  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
- scarface_74 2y ago
  This is not true as far as AWS and this is a myth that needs to die. http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business?share=1 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).
  - kridsdale1 2y ago
    Confirm that the majority of Google first party stack is not sitting on GCP. They are parallel.
    - sitkack 2y ago
      If Google had self hosted on GCP the way that Bezos dictated that Amazon have hard service boundaries, they would be the top Cloud provider right now. But they didn't and they aren't, and it doesn't matter anymore. https://www.phind.com/search?cache=fvljl85u7ll9u4wwncsrilfq https://www.phind.com/search?cache=fvljl85u7ll9u4wwncsrilfq
      - deleted 2y ago
        [deleted]
      - sitkack 2y ago
        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.
        2y ago
- alex-mohr 2y ago
  Also a myth for GCE. 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.]

This situation has been and maybe always will be common. Those who view themselves as integrated manufacturers of *products* often cannot equally package, deliv

gsibble 2y ago

Counter-Point: GCP and AWS came out of product focused companies that effectively converted to providing the services they used internally.

ethbr1 2y ago
I'd never really thought about "How did hyperscale cloud providers become cloud providers?" And it's surprisingly distinct. 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)
- scarface_74 2y ago
  AWS was never an offshoot from Amazon. http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business?share=1 http://www.quora.com/How-and-why-did-Amazon-get-into-the-clo...
  - LinuxAmbulance 2y ago
    That's not true. 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.
    - scarface_74 2y ago
      Again the link I posted was from Werner Vogels. The architecture that the CDO (Amazon Retail) uses is completely different than AWS. Have you seen the difference between the architecture of CDO and AWS internally?
twunde 2y ago
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
scarface_74 2y ago
This is not true as far as AWS and this is a myth that needs to die. http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business?share=1 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).
- kridsdale1 2y ago
  Confirm that the majority of Google first party stack is not sitting on GCP. They are parallel.
  - sitkack 2y ago
    If Google had self hosted on GCP the way that Bezos dictated that Amazon have hard service boundaries, they would be the top Cloud provider right now. But they didn't and they aren't, and it doesn't matter anymore. https://www.phind.com/search?cache=fvljl85u7ll9u4wwncsrilfq https://www.phind.com/search?cache=fvljl85u7ll9u4wwncsrilfq
    - deleted 2y ago
      [deleted]
    - sitkack 2y ago
      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.
      - 2y ago
alex-mohr 2y ago
Also a myth for GCE. 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.]