3 ms·

> 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 s

> 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.
- joshuamorton 6y ago
  > and stripping of for-profit status will be way better than splitting it. The US can't just make a company suddenly a non-proft. The current shareholders would have, in the case of Google, about a trillion reasons to complain.
  - anticensor 6y ago
    They would receive their respective share capitals in the liability payment stage of utilisation process, the business would continue too, so no valid reason to complain.
acituan 6y ago
> It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. Completely foreign platform is moving the goalposts here. I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions. Besides, the giant leap the OP and you make is that cost prohibition is the reason these spin-offs don't occur. I've been arguing not only the cost is not as high as you make, it is also unlikely to be the reason for us not seeing spin-offs. To invert your premise, if cost of giving the keys of any killed Google product to someone else was less than the money they could get, would they really transact away all of those products? I voted a strong no since my first reply to OP. > 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) Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. As I stated, that accommodation game becomes combinatorially explosive. Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Which is why the internal and external versions of could offerings don't diverge but converge too, their infrastructure is general purpose enough. > 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. I explicitly stated multiple times that I am not claiming 100% API/service parity, so you are fighting a strawman here. Not being identical, while being are sufficiently convergent, doesn't prove cost prohibition at all. > Yes, you claim this, and you were and continue to be incorrect. > But these aren't opinions. You're just factually, demonstrably wrong. I don't hear any demonstrations or facts, only your willful assertion that "it is so". Which is fine in a pseudonymous forum, because as I mentioned we don't need to spill our credentials to just win an argument, but also like I said, don't ask people to ascribe any more authority to it than mere opinion.
- joshuamorton 6y ago
  > Completely foreign platform is moving the goalposts here. No it's not, because you are consistently overestimating how similar the internal and public platforms are. I don't know how I can make this any more clear. Your estimation is incorrect. You are misinformed. > everything Reader depended on is very likely to be available on GCP This is, probably, approximately true. > is very likely to be in a form that is very similar to its internal versions. This is demonstrably wrong, and I and others have already provided examples, which you've ignored. > I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions. Moving from stubby to GRPC is a lot of effort. Moving from Google's internal user ACLing to OAuth or whatever is a lot of effort. Switching the APIs used for Google's internal monitoring infra with the ones that are used by GCP is a lot of effort. Removing dependencies on borg particulars is a lot of effort. Doing all of those things is a lot of a lot of effort and reasonably cost prohibitive. And that's ignoring a lot of other sources of "a lot of effort". > Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. You have this backwards. It is precisely because the internal infra supports thousands of engineering teams doing complex things, up to and including hosting the external infra, that it must be significantly more flexible. Note however that this is irrelevant to the broader point, which is that even if they're exactly the same flexible, they're not the same, and as a result, you have to rewrite every place where you interact with an external system, which means essentially rewriting the entire application. > Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Yes, which is more flexible than the external infrastructure. Put simply, the internal infrastructure is what the external infrastructure runs on. This may mean that sometimes you can run things on the external infra, but when you can't, the internal infra is strictly more powerful, since it hosts the external infra. > I explicitly stated multiple times that I am not claiming 100% API/service parity Nor did I say anything about 100% parity. I said, and continue to say cost prohibitive. To rephrase, since you misunderstood: if they need to better align them, that means that there are large enough differences that porting (or perhaps just interoperation) is cost prohibitive, and so they need to change how the systems work to make it easier to move between them.

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.

joshuamorton 6y ago
> and stripping of for-profit status will be way better than splitting it. The US can't just make a company suddenly a non-proft. The current shareholders would have, in the case of Google, about a trillion reasons to complain.
- anticensor 6y ago
  They would receive their respective share capitals in the liability payment stage of utilisation process, the business would continue too, so no valid reason to complain.

acituan 6y ago

> It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. Completely foreign platform is moving the goalposts here. I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions. Besides, the giant leap the OP and you make is that cost prohibition is the reason these spin-offs don't occur. I've been arguing not only the cost is not as high as you make, it is also unlikely to be the reason for us not seeing spin-offs. To invert your premise, if cost of giving the keys of any killed Google product to someone else was less than the money they could get, would they really transact away all of those products? I voted a strong no since my first reply to OP. > 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) Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. As I stated, that accommodation game becomes combinatorially explosive. Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Which is why the internal and external versions of could offerings don't diverge but converge too, their infrastructure is general purpose enough. > 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. I explicitly stated multiple times that I am not claiming 100% API/service parity, so you are fighting a strawman here. Not being identical, while being are sufficiently convergent, doesn't prove cost prohibition at all. > Yes, you claim this, and you were and continue to be incorrect. > But these aren't opinions. You're just factually, demonstrably wrong. I don't hear any demonstrations or facts, only your willful assertion that "it is so". Which is fine in a pseudonymous forum, because as I mentioned we don't need to spill our credentials to just win an argument, but also like I said, don't ask people to ascribe any more authority to it than mere opinion.

joshuamorton 6y ago
> Completely foreign platform is moving the goalposts here. No it's not, because you are consistently overestimating how similar the internal and public platforms are. I don't know how I can make this any more clear. Your estimation is incorrect. You are misinformed. > everything Reader depended on is very likely to be available on GCP This is, probably, approximately true. > is very likely to be in a form that is very similar to its internal versions. This is demonstrably wrong, and I and others have already provided examples, which you've ignored. > I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions. Moving from stubby to GRPC is a lot of effort. Moving from Google's internal user ACLing to OAuth or whatever is a lot of effort. Switching the APIs used for Google's internal monitoring infra with the ones that are used by GCP is a lot of effort. Removing dependencies on borg particulars is a lot of effort. Doing all of those things is a lot of a lot of effort and reasonably cost prohibitive. And that's ignoring a lot of other sources of "a lot of effort". > Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. You have this backwards. It is precisely because the internal infra supports thousands of engineering teams doing complex things, up to and including hosting the external infra, that it must be significantly more flexible. Note however that this is irrelevant to the broader point, which is that even if they're exactly the same flexible, they're not the same, and as a result, you have to rewrite every place where you interact with an external system, which means essentially rewriting the entire application. > Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Yes, which is more flexible than the external infrastructure. Put simply, the internal infrastructure is what the external infrastructure runs on. This may mean that sometimes you can run things on the external infra, but when you can't, the internal infra is strictly more powerful, since it hosts the external infra. > I explicitly stated multiple times that I am not claiming 100% API/service parity Nor did I say anything about 100% parity. I said, and continue to say cost prohibitive. To rephrase, since you misunderstood: if they need to better align them, that means that there are large enough differences that porting (or perhaps just interoperation) is cost prohibitive, and so they need to change how the systems work to make it easier to move between them.