Why is Multi-Cloud a Hard Problem?
planetscale.com
Why is Multi-Cloud a Hard Problem?
1–10 of 30 posts
Re: Why is Multi-Cloud a Hard Problem?
#2Re: Why is Multi-Cloud a Hard Problem?
#3Re: Why is Multi-Cloud a Hard Problem?
#4Re: Why is Multi-Cloud a Hard Problem?
#5> Two reasons: Disaster recovery and freedom from vendor lock in.
In my experience, those two reasons are almost never sufficient to warrant a multi-cloud solution. The costs for multi-cloud are enormous. Another commenter mentioned egress costs, but there are numerous other costs:
1. You've added a lot of complexity on top of existing cloud solutions. That complexity can make things fail in unique ways that may make some of your cherished reliability benefits moot.
2. You are always coding to the "lowest common denominator" of any cloud service, meaning you're missing out on a ton of productivity by forgoing useful services.
I'm just curious if anyone can comment that has experience actually using multi-cloud, and was it worth it?
Re: Why is Multi-Cloud a Hard Problem?
#6> Why use true multi-cloud clusters? > Two reasons: Disaster recovery and freedom from vendor lock in. In my experience, those two reasons are almost never sufficient to warrant a multi-cloud solution. The costs for multi-cloud are enormous. Another commenter mentioned egress costs, but there are numerous other costs: 1. You've added a lot of complexity on top of existing cloud solutions. That complexity can make thi…
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.
Re: Why is Multi-Cloud a Hard Problem?
#7Re: Why is Multi-Cloud a Hard Problem?
#8One key missing factor: live replication across three clouds is not just a technical problem, but a cost problem, because the egress costs will be murderous.
Re: Why is Multi-Cloud a Hard Problem?
#9One key missing factor: live replication across three clouds is not just a technical problem, but a cost problem, because the egress costs will be murderous.
Not everyone rips you off on egress fees the way Amazon/MS/Google do. Quite a few of the 2nd tier providers (eg. Vultr, Linode, Digital Ocean, Upcloud, etc) offer $0.01/GB for public outbound bandwidth with a free allowance each month (usually anywhere from 1-10+TB/month/instance depending on what you deployed). Some companies even waive fees for companies they're partnered with (eg. if you use Wasabi or Backblaze B2…