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