4 ms·

It's probably true that now (in 2020) Google has cloud services that do everything which Reader needed, but it wasn't true when Reader was shut down in 2013. Fo

It's probably true that now (in 2020) Google has cloud services that do everything which Reader needed, but it wasn't true when Reader was shut down in 2013. For instance, cloud Bigtable launched to the public in 2015. (I don't know whether current Google products mainly rely on the public services, or internal near-equivalents to the public services, or significantly different internal services. I assume it's mainly either the first or the second.)

acituan 6y ago
Well the point is there is no “secret sauce infra”, let alone Google specific infra as the OP speculates. If we were to claim timing as a factor, AWS was available since 2006.
- lrem 6y ago
  You really missed the point. It does not matter if the "secret sauce infra" is better than equivalents. What matters is that the code you have is based on it. And since literally everything is based on Stubby, which has a hard dependency on Borg, once you remove the bits of the backend's code that are secret-sauce-dependent you're left with a Makefile ;) Disclaimer: I work in Google, but the above is easily inferred from the SRE books.
  - acituan 6y ago
    > It does not matter if the "secret sauce infra" is better than equivalents. That is what the OP suggested. > What matters is that the code you have is based on it It is the nature of infrastructure is to be independent from business logic. I’m not saying any migration would be trivial, but it is also not as cost prohibitive as you seem to be arguing for. RPC is a very old and generic concept, so unless reader was depending on Google specific RPC mechanics, the cost of swapping one RPC tech with another is not going to be to the extent of warranting uttering of concepts like anti-trust.
    - dodobirdlord 6y ago
      The distinction is less important at Google, where all of the code is in a monorepo and all of the infrastructure was custom-built to support the products.
      - acituan 6y ago
        Monorepo doesn’t mean a monolith, it is about code repositories, not about the extent of software reuse. You could convert the entirety of open source code into a monorepo too, but it wouldn’t mean they magically reuse each other. > all of the infrastructure was custom-built to support the products. That tells me you might not have experienced software development in a large company. I don’t know the specifics of Google, but custom tailoring infra is a combinatorially explosively problem if you have hundreds/thousands of products you need to “custom tailor” to. And if you could, would the result be really custom tailored anymore or general enough to have universal use? Your argument is self contradictory.

acituan 6y ago

Well the point is there is no “secret sauce infra”, let alone Google specific infra as the OP speculates. If we were to claim timing as a factor, AWS was available since 2006.

lrem 6y ago
You really missed the point. It does not matter if the "secret sauce infra" is better than equivalents. What matters is that the code you have is based on it. And since literally everything is based on Stubby, which has a hard dependency on Borg, once you remove the bits of the backend's code that are secret-sauce-dependent you're left with a Makefile ;) Disclaimer: I work in Google, but the above is easily inferred from the SRE books.
- acituan 6y ago
  > It does not matter if the "secret sauce infra" is better than equivalents. That is what the OP suggested. > What matters is that the code you have is based on it It is the nature of infrastructure is to be independent from business logic. I’m not saying any migration would be trivial, but it is also not as cost prohibitive as you seem to be arguing for. RPC is a very old and generic concept, so unless reader was depending on Google specific RPC mechanics, the cost of swapping one RPC tech with another is not going to be to the extent of warranting uttering of concepts like anti-trust.
  - dodobirdlord 6y ago
    The distinction is less important at Google, where all of the code is in a monorepo and all of the infrastructure was custom-built to support the products.
    - acituan 6y ago
      Monorepo doesn’t mean a monolith, it is about code repositories, not about the extent of software reuse. You could convert the entirety of open source code into a monorepo too, but it wouldn’t mean they magically reuse each other. > all of the infrastructure was custom-built to support the products. That tells me you might not have experienced software development in a large company. I don’t know the specifics of Google, but custom tailoring infra is a combinatorially explosively problem if you have hundreds/thousands of products you need to “custom tailor” to. And if you could, would the result be really custom tailored anymore or general enough to have universal use? Your argument is self contradictory.