I was one of the individuals who helped put this together and hopefully can answer your question. Specifically about complexity and the productivity of going multi-cloud.
Here is what we found, previously when people talked about going to the cloud the state of the art was everything is done targeting a specific cloud provider, you put your software in immutable AMI's and you use ASG, and ELB, along with S3 and EBS to have really robust systems. You instrument everything with CloudWatch and make sure everything is locked down with IAM and security groups.
What we have seen lately is that because of Kubernetes that has all changed. Most systems being designed today are being done very much provider agnostic, and the only time you want to be locked into a specific technology is when the vendor provided solution doesn't really have an alternative in a truly vendor agnostic stack. Part of what this service is doing is taking the last true bit of Gravity for a cloud provider and removing it, you can now run in both clouds just as easily as if you were all in on one of them. There are some additional costs if you are transferring all your data across the wire, but that is where the power of Vitess's sharding comes in. You can run your service across two clouds, while minimizing the amount of cross talk, until you want to migrate off.
Also while this post makes a big deal about being multi-cloud, this also gives you true multi-region databases. Thats something that was really only available with Spanner or CosmosDB previously, both of which require you to target them explicitly. PlanetScaleDB lets you use your existing MySQL compatible software.
Thanks for the response. While I certainly see the value of being provider agnostic, I just don't see the value of being multi-cloud within the same app or service.
I worked at a company that wrote an internal infrastructure/deploy management tool based on Kubernetes. You could deploy an app either to our colo facility (we were an old business transitioning to the cloud), or you could deploy it to AWS. As a developer I never interacted with the AWS console, this internal tool just hid it all from me. However, while I had the option of deploying to our colo or to the cloud, it was one or the other; the service was only running in one platform in prod.
And after a multi year push to the cloud, the company actually had to stop that huge push because costs were spiralling out of control. Managing all the costs across a huge enterprise of many services (some micro, some not) became a huge challenge. Can't even imagine the additional cost or complexity if some of those services spanned multiple cloud providers.
Here is what we found, previously when people talked about going to the cloud the state of the art was everything is done targeting a specific cloud provider, you put your software in immutable AMI's and you use ASG, and ELB, along with S3 and EBS to have really robust systems. You instrument everything with CloudWatch and make sure everything is locked down with IAM and security groups.
What we have seen lately is that because of Kubernetes that has all changed. Most systems being designed today are being done very much provider agnostic, and the only time you want to be locked into a specific technology is when the vendor provided solution doesn't really have an alternative in a truly vendor agnostic stack. Part of what this service is doing is taking the last true bit of Gravity for a cloud provider and removing it, you can now run in both clouds just as easily as if you were all in on one of them. There are some additional costs if you are transferring all your data across the wire, but that is where the power of Vitess's sharding comes in. You can run your service across two clouds, while minimizing the amount of cross talk, until you want to migrate off.
Also while this post makes a big deal about being multi-cloud, this also gives you true multi-region databases. Thats something that was really only available with Spanner or CosmosDB previously, both of which require you to target them explicitly. PlanetScaleDB lets you use your existing MySQL compatible software.