According to Gartner, “Distributed cloud is the distribution of public cloud services to different physical locations, while the operation, governance and evolution of the services remain the responsibility of the public cloud provider.” Analysts go on to explain that the distributed cloud provides a flexible agile environment for applications and data that require low-latency, data cost reduction, and data residency.
This idea is not new; I’ve used it to remove latency and/or comply with data sovereignty laws from time to time. At its essence, the advantage is for end-users to have cloud computing resources closer to the physical location where the business activities happen, thus reducing latency.
Of course, analyst groups love to assign buzzwords to emerging patterns, and I’m no different (although more people listen to a large analyst firm than to me). However, lately we seem to be naming things that are…well…already a thing. Distributed cloud falls in that category.
First, public clouds have been distributed for some time, allowing developers and architects to assign specific processing and data storage to a single geographical region or regions. Second, leveraging regions to tune processing and data storage for security, performance, and compliance has been a best practice for years.
Let’s look at the merits of the distributed cloud and see if this should be an option for your cloud-based workloads.
Distributed clouds need some centralized control. Moving processing and data out to different regions is actually pretty easy. We’ve all assigned regions when provisioning storage or compute resources. However, you do have to think about coordinating these resources, including synchronizing data and distributing processing. Fortunately, we’ve done this for single distributed public clouds and multicloud also. The solutions are pretty well understood, and the technology works effectively.
More than one cloud provider leverages the distributed concept. Multicloud is the way that most will experience distributed clouds. Not only will you be distributing processing and data across a single cloud provider, it could be as many as five providers, with processing and data existing on multicloud deployments. This will increase the number of regions you’re deployed on, multiplied by the same number of cloud brands that you’re using.
I don’t mean to pop the distributed cloud balloon. It’s a sound architectural option, but you need to understand when to use it and why.