4 ms·

> 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

> 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.
- acituan 6y ago
  > This is demonstrably wrong, and I and others have already provided examples, which you've ignored. I don't know what exactly you consider to be an example to demonstrate your point, but I must have missed it because I haven't read anything factual on the matter. If you think merely listing a bunch of infrastructure components and deeming the difference between external and internal versions is sufficient evidence, I have already stated that it doesn't convince me. Maybe we have vastly different experiences in the software development we have participated in our careers, but I think the root of our estimation mismatch is you equivocating rewriting the infra glue code with the entirety of the application. I certainly don't see it that way. > 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". To my point, I have explicitly stated this infra glue code will be in need of re-writes. While "a lot" doesn't help quantifying your proposition much, you (or others in this thread) seem to equivocate this to designing and implementing the whole application from scratch, and that is where I disagree. Sure this going to be application specific, but I would estimate the engineering hours spent on replacing the infra glue code to be much less than that went to developing the business logic. I don't deem that to be cost prohibitive when we are talking about a company potentially selling that IP, much less so if it is going to run in their public cloud platform. Besides, I don't know much about Borg, but if an application like an RSS aggregator is taking dependencies on implementation details of their replicated task scheduling and provisioning system, I think they must have been doing it very, very wrong. > I don't know how I can make this any more clear. Your estimation is incorrect. You are misinformed. Keeping repeating your assertions is definitely not going to help making anything clearer. Let your arguments do the talking, let the readers arrive to the conclusion on who is wrong or possibly misinformed. You are bordering on shallow dismissals which HN guidelines frown upon. It is bad form, please don't keep doing this.
  - deleted 6y ago
    [deleted]

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.

acituan 6y ago
> This is demonstrably wrong, and I and others have already provided examples, which you've ignored. I don't know what exactly you consider to be an example to demonstrate your point, but I must have missed it because I haven't read anything factual on the matter. If you think merely listing a bunch of infrastructure components and deeming the difference between external and internal versions is sufficient evidence, I have already stated that it doesn't convince me. Maybe we have vastly different experiences in the software development we have participated in our careers, but I think the root of our estimation mismatch is you equivocating rewriting the infra glue code with the entirety of the application. I certainly don't see it that way. > 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". To my point, I have explicitly stated this infra glue code will be in need of re-writes. While "a lot" doesn't help quantifying your proposition much, you (or others in this thread) seem to equivocate this to designing and implementing the whole application from scratch, and that is where I disagree. Sure this going to be application specific, but I would estimate the engineering hours spent on replacing the infra glue code to be much less than that went to developing the business logic. I don't deem that to be cost prohibitive when we are talking about a company potentially selling that IP, much less so if it is going to run in their public cloud platform. Besides, I don't know much about Borg, but if an application like an RSS aggregator is taking dependencies on implementation details of their replicated task scheduling and provisioning system, I think they must have been doing it very, very wrong. > I don't know how I can make this any more clear. Your estimation is incorrect. You are misinformed. Keeping repeating your assertions is definitely not going to help making anything clearer. Let your arguments do the talking, let the readers arrive to the conclusion on who is wrong or possibly misinformed. You are bordering on shallow dismissals which HN guidelines frown upon. It is bad form, please don't keep doing this.
- deleted 6y ago
  [deleted]