To head off regulators, Google makes certain words taboo

So if you have on prem infra that you can't migrate to the cloud (for legal reasons or because it's some big hefty SAP server or whatnot, or because you want to migrate but can't yet), but still want to have some stuff be cloud-y, and maybe have that stuff communicate, you can use anthos to make that work.

And that's the best I can give you.

You are not writing any of those systems, you're merely writing the glue code between your application and those systems, none of which is application specific.

I explicitly made the point that cross-infra porting is not necessarily trivial, but it is also not cost prohibitive as the OP makes, and certainly there is no secret sauce involved to the extent of justifying a break-up.

> except for some of the business logic

You mention this in the passing, but barring mechanical limitations of the new infra, reusing your business logic means retaining your APIs, auth models, data models, even database schemas, replication and deployment design decisions and tons of portable code. That is where the overwhelming majority of engineer hours go in an ordinary product anyway.

> three do run divergent platforms simultaneously, today, right now

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. I'm not saying there is a perfect external/internal service&API parity, but certainly convergence is the normativity here, not divergence.

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.

But the document in question is not a training document for the purpose of curtailing employee complacency and remaining vigilant in the face of competition. It's a document specifically discussing ways to avoid anti-trust regulators. That's an important distinction.

If employees already believed it because of their internal training, there'd be no need to "remind" them what not to say.

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.

These words aren't more accurate in all cases. In some cases these substitutions will be/are used they are less accurate or misleading.