Multi-cloud is mostly just a meme. Especially if you’re trying to run an active-active multicloud environment. You can try it, but it will always suck, and never work properly.
If you want to be service provider agnostic, run everything in your own kube and host your own CI/CD tooling. You won’t have real-time RTOs, but you’ll be able to get yourself up and running basically anywhere pretty quickly if you have to.
Also, the single biggest lock-in feature for AWS is IAM, and most people never even think about it. So be careful with how you use that if you want to be able to move smoothly.
Edit: and if you’re going to run your own kube, use Knative. Makes it so much easier.
So are you better off being focusing on being able to pick up and move (provider agnostic), rather than trying to spread your servers across multiple clouds?
If it’s possible to find service providers that you can trust to host you (whether they’re providing colo/VPS/“cloud”... doesn’t really matter), then you’re much better off making your infrastructure as portable as possible. That way if one service provider decides to unexpectedly censor you, then you can just pick up and move.
If you want to build a service that is actually resistant to censorship, then you need to build a properly distributed or decentralized system. That’s a much more complex type of system to design (there’s really only a handful of such systems in the world).
Building a multi-cloud service brings all of the challenges of building a distributed system, but without actually achieving much resistance to censorship. At the end of the day, you’re going to need to end up being hosted by a service provider willing to give you service. So you’re much better off just looking for those service providers to begin with.
The rather niche usecase where multicloud (almost) makes sense is if you want to protect against a major service outage at one cloud provider. But even then, it’s a tremendous amount of effort for very little return. You could do “multicloud” by building a service in AWS that you could restore to Azure in say 30-90 minutes if you wanted to. That would be significantly less complicated, but it’s not the sort of active-active configuration that most people think of when they hear that term.
Maximizing portability makes sense in any case, because vendor lock-in is always going to be a risk, whether you’re concerned about censorship or not.
yeah multi cloud in general
And if is there any orchestration tools to set that up so you can have networks from 3 different clouds connected up and balancing traffic etc
or does it need to be rigged up manually?
Multi-cloud is mostly just a meme. Especially if you’re trying to run an active-active multicloud environment. You can try it, but it will always suck, and never work properly.
If you want to be service provider agnostic, run everything in your own kube and host your own CI/CD tooling. You won’t have real-time RTOs, but you’ll be able to get yourself up and running basically anywhere pretty quickly if you have to.
Also, the single biggest lock-in feature for AWS is IAM, and most people never even think about it. So be careful with how you use that if you want to be able to move smoothly.
Edit: and if you’re going to run your own kube, use Knative. Makes it so much easier.
So are you better off being focusing on being able to pick up and move (provider agnostic), rather than trying to spread your servers across multiple clouds?
Depends on your threat model.
If it’s possible to find service providers that you can trust to host you (whether they’re providing colo/VPS/“cloud”... doesn’t really matter), then you’re much better off making your infrastructure as portable as possible. That way if one service provider decides to unexpectedly censor you, then you can just pick up and move.
If you want to build a service that is actually resistant to censorship, then you need to build a properly distributed or decentralized system. That’s a much more complex type of system to design (there’s really only a handful of such systems in the world).
Building a multi-cloud service brings all of the challenges of building a distributed system, but without actually achieving much resistance to censorship. At the end of the day, you’re going to need to end up being hosted by a service provider willing to give you service. So you’re much better off just looking for those service providers to begin with.
The rather niche usecase where multicloud (almost) makes sense is if you want to protect against a major service outage at one cloud provider. But even then, it’s a tremendous amount of effort for very little return. You could do “multicloud” by building a service in AWS that you could restore to Azure in say 30-90 minutes if you wanted to. That would be significantly less complicated, but it’s not the sort of active-active configuration that most people think of when they hear that term.
Maximizing portability makes sense in any case, because vendor lock-in is always going to be a risk, whether you’re concerned about censorship or not.