|
There's actually no such thing as a multi-region anything. There also isn't such a thing as a single-region anything. Cloud infrastructure is built and managed as a sort of bizarre multi-layer cake, that is actually several cakes. It's like Escher's Cake. Multiple cakes cut into slices and pushed together, where one cake bleeds into another cake seamlessly. Every layer is actually more than one layer, and not. The way this works is pretty simple: cloud architecture is built on many different services. Those services may operate either on a "global" level, or "regional", or "zonal". By combining different services together into one solution, your solution will be affected by global changes, and by regional and zonal changes. So there's no way to completely isolate it from other areas, even at the zonal level. At some point, a change to a global, regional, or zonal service will affect whatever zone/region/multi-region thing you have, no matter how you architect it. In the cloud, anyway. (There would be if every single service in a cloud provider could be zonally segregated, but they can't. If you make an IAM change, that's global; no way to make it only affect one zone at a time, and no way to ensure it is applied in every zone. DNS is intended to be global; you could technically run your own nameservers and target specific ones in specific zones for a particular update. But even then you could not guarantee an update goes out to all zones, or even one zone) If you built an entire cloud provider from scratch, you could try to build literally every service to be zonal, and expand from there. But no cloud provider I'm aware of has that capability, and I'm not aware of anybody who has DIY'd their own PaaS that does it either. So you can claim you have a global platform, or a regional or zonal platform, but in practice, it is almost always an architectural Escher Cake and subject to the random whims of the universe. |