GCP would probably have been better off if the "AWS marketplace" had worked out... E.g. instead of "GCP runs machines + offers PaaS databases/caches/etc." and

GCP would probably have been better off if the "AWS marketplace" had worked out... E.g. instead of "GCP runs machines + offers PaaS databases/caches/etc." and "AWS runs machines + offers PaaS databases/caches/etc.", then now both the "run machines" + "PaaS offerings" must be identical, it'd be much easier if cloud providers got out of the PaaS business. That way both GCP and AWS just "run machines", and instead there is some sort of vendor / marketplace API where database vendor X can run in both AWS and GCP, and caching vendor Y can run in both AWS and GCP. And so you use the db APIs and the cache APIs, with some sort of service discovery within each cloud, and ideally the management UIs for the db and cache are both hooked in the GCP/AWS consoles. So, it's not "use Dynamo in AWS" vs. "use Bigtable in GCP" and they're kinda/sorta the same, it'd be "use (say) Voldemort in both" and they really are the same, and managed by the same vendor. (And not "you start vendor X's AMIs/images in your account and then play sysadmin", but "you use vendor Xs already-running/multi-tenant APIs from your app".) That said, it's not in AWS's interest to let others provide the PaaS part of the machine in a generic way. And, realistically, I don't think other (non-cloud) vendors could have successfully provided the PaaS offerings that AWS has, at the same multi-tenant scale. E.g. pre-AWS, all of the vendors (like a DB startup) were focused on "scale single-tenant solutions", and not "scale multi-tenant solutions", which is likely an order of magnitude or more harder. So it made sense for AWS to do it instead (plus the obvious benefit to them of more AWS lock in).