Part one of two on an exploration of distributed cloud architecture.
One of the latest trends in cloud environments is distributed cloud. Among other attributes, distributed cloud involves running the public cloud on your infrastructure. This architecture allows distributed cloud to overcome the following potential challenges with public cloud:
- Regulatory issues when migrating applications to the public cloud
- Lack of control over your public cloud
See the following video for a further explanation of distributed cloud:
Regulations and distributed cloud
Every public cloud vendor has a set of availability zones or regions in which they run. For example, IBM Cloud runs in the following availability zones:
- Dallas, Texas
- Washington, D.C.
- Frankfurt, Germany
- London, England
- Sydney, Australia
- Tokyo, Japan
These availability zones exist in limited areas. As such, your data and your workload on public clouds like IBM Cloud have to stay in your country. This is true especially for heavily regulated industries, such as financial services.
So, say you’re operating a bank, and you’d like to migrate an application to the public cloud. Many financial institutions have regulatory rules mandating that your workload and data must stay in-country, which prevents you from performing this task.
This situation provides an opportunity for distributed cloud to operate the public cloud itself in a client-defined location. With distributed cloud, you can actually operate your public cloud in a data center or in a data center colocation or even on a third-party cloud that may have available capacity in a country you’re targeting. Distributing public cloud services, or managed services, to different physical locations that you control is a key advantage for you when using distributed cloud.
More flexibility with distributed cloud
While operating our public cloud, we can install software wherever we want in our infrastructure. However, our distributed cloud vendor has the responsibility for fully managing several key processes, including the following:
- Lifecycle control
- Security, reliability and engineering
This division of labor means your vendor performs all the patches, upgrades, installs and deletions to keep your public cloud updated. Your vendor also handles compatibility issues so that one version of a service you use works well with another version of another service. In essence, your vendor is operating the cloud as a “mini-public cloud region,” just within your infrastructure that you control.
So, with distributed cloud, you take your public cloud service and create a mini-public cloud region to run those public cloud services. By definition, your public cloud is your entry point for observability and configuration of those services.
When creating a distributed cloud location, your services and workload run in the location. If the location and the cloud actually have a link or some kind of connection — which they would need to aggregate blogs, monitors and reports — everything still needs to run if you cut that link. Otherwise, you can’t get to your dashboards to configure the service on-premises because the network link was cut.
With distributed cloud, you can still execute your services, workloads and applications because you have a single control pane of one cloud that can configure your public cloud, even if the link is cut. This option is true for any distributed cloud vendor.
To learn more about how distributed cloud compares with other common cloud-computing architectures like hybrid cloud and multicloud, check out "Distributed Cloud vs. Hybrid Cloud vs. Multicloud vs. Edge Computing (Part 1)."
IBM Cloud Satellite: IBM’s version of distributed cloud
IBM Cloud Satellite is a distributed cloud offering that brings IBM Cloud services like managed Red Hat OpenShift on IBM Cloud to the infrastructure of your choice.
In the second part of this blog, I discuss how the architecture of IBM Cloud Satellite significantly differs from competing vendors in what the environment can offer you.