3 ms·

> you're merely writing the glue code between your application and those systems, none of which is application specific. Yes, but if you have to modify every i

> you're merely writing the glue code between your application and those systems, none of which is application specific. Yes, but if you have to modify every interaction with an external API (you do), or even many interactions between internal APIs (you also do), you have to rewrite the application. Most of an application is moving data, if you have to change how you move data, you have to change the majority of the app. > No, they don't. Trying to spin up your custom internal infra (or demanding special internal accommodation from externally available infra) will require justifying to management why you're not using the existing one, and most of the new products coming from these guys are nothing that specialized in terms of infra needs. Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. > Let me put it this way, majority of {Google, Amazon, Microsoft} services could be ported to run on each others cloud platforms, let alone on the external APIs of their own platforms, which means there is no secret sauce and there is no reason for smaller players to be complaining about it other than not having economies of scale thus pricing levels. This is also wrong (i mean for some value of ported including "completely and entirely rearchitect", yes this is trivially true). But no, hosting AWS on GCP or Google search on AWS would not be, by any stretch of the imagination, a relatively simple process. There are well known examples of systems that one service has, that another can't support. A simple example would be Spanner. But that's a different conversation than the one we were having. The original claim was > Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, etc. Which is true. You seem to be taking "can't" to mean "cannot technically, even given infinite resources" and not the much more likely "cannot reasonably". And this would be true in general, ask anyone who has tried to move an app GCE to AWS, and see if it was pleasant. It's not.

acituan 6y ago
We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is not the point of this exercise. The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. (In fact the inverse case happens pretty frequently, whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending). No need to make it more complicated than that. > Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. They are all entitled to their own opinion. I'm open to being proven wrong, but I'm sure you can guess how different opinions can be even in 'those companies' so let's not assume there is a clear, unquestionable truth they have access to. It is hard to attest anyone's credentials on a pseudonymous forum and that is OK.
- joshuamorton 6y ago
  > The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. > I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. Yes, you claim this, and you were and continue to be incorrect. > whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget. But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions. > They are entitled to their own opinion. But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. To address your other comment: > You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc. Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.
  - anticensor 6y ago
    > This is valid even if Google's internal infra is strictly worse than what is available openly. Indeed it is, because Sod's, Parkinson's and Wirth's laws. > This is insane and a sign that something is deeply wrong in Google. Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce. Given such a massive rewrite will not be possible without bankrupting the company, and such an open source would just amount to going non-profit (they would essentially lose all trade secrets and profit-making advantages), forcing a public domain of intellectual property, replacing the top executives without severance and stripping of for-profit status will be way better economically, than splitting it.
deleted 6y ago
[deleted]

acituan 6y ago

We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is not the point of this exercise. The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. (In fact the inverse case happens pretty frequently, whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending). No need to make it more complicated than that. > Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. They are all entitled to their own opinion. I'm open to being proven wrong, but I'm sure you can guess how different opinions can be even in 'those companies' so let's not assume there is a clear, unquestionable truth they have access to. It is hard to attest anyone's credentials on a pseudonymous forum and that is OK.

joshuamorton 6y ago
> The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. > I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. Yes, you claim this, and you were and continue to be incorrect. > whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget. But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions. > They are entitled to their own opinion. But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. To address your other comment: > You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc. Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.
- anticensor 6y ago
  > This is valid even if Google's internal infra is strictly worse than what is available openly. Indeed it is, because Sod's, Parkinson's and Wirth's laws. > This is insane and a sign that something is deeply wrong in Google. Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce. Given such a massive rewrite will not be possible without bankrupting the company, and such an open source would just amount to going non-profit (they would essentially lose all trade secrets and profit-making advantages), forcing a public domain of intellectual property, replacing the top executives without severance and stripping of for-profit status will be way better economically, than splitting it.

deleted 6y ago

[deleted]