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.

Regulations and distributed cloud

Every public cloud vendor has a set of availability zones or regions in which they run. For example, across six time zones in areas across the globe, but local regulations could specify that data on the public cloud has to stay in-country.

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 operate your public cloud in a data centre or in a data centre 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:

Governance
Evolution
Lifecycle control
Security, reliability and engineering

This division of labour means your vendor performs all the patches, upgrades, installations 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 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.

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.

Enjoy complete flexibility

IBM Cloud Satellite is a distributed cloud offering that brings IBM Cloud services like the managed Red Hat OpenShift on IBM Cloud to the infrastructure of your choice. Unlike other distributed cloud vendors, IBM Cloud Satellite can run on your own infrastructure or on any third-party cloud. If you want an appliance to build a cloud automatically, we can sell that to you. Our distributed cloud can run on a data centre colocation or on a third-party edge networking environment.

The other differentiator: More variety

Our vision for distributed cloud is to allow the entire IBM public cloud catalogue to be run in a distributed cloud location. IBM Cloud Satellite locations already support a number of PaaS services from the IBM Cloud catalogue, such as our managed Red Hat OpenShift service, IBM Cloud Databases, IBM Watson Studio and IBM Watson Machine Learning. These offerings are managed services — the same IBM Cloud services with IBM Cloud support doing all security, reliability and engineering. More services will continue to be added until we reach our vision.

Additionally, IBM Satellite Locations support all IBM Cloud Pak solutions, the software section of the IBM Cloud catalogue and Red Hat Marketplace.

Compare that approach to Google’s distributed cloud, where there are software packages you must install and manage. As for other major distributed cloud vendors, Microsoft Azure offers Kubernetes, virtual machines and databases, but not their other set of PaaS services. Amazon Web Services has fixed hardware appliances you have to buy to get a more flexible set of services, including their virtual machines, containerisation, Kubernetes and more.

Another key IBM distinction: Built on Kubernetes

As IBM Cloud is built on top of Kubernetes, you get the following additional advantages that can help when using IBM Cloud Satellite:

Our PaaS services are almost entirely based on open source projects.
All of our services are containerised and run on Kubernetes.

The first advantage allows us to manage all instances of those PaaS services at scale. Those services are all best-of-breed open-source solutions.

By being containerised and running on Kubernetes, we can more easily migrate these services to run on other IBM Cloud regions that we create and potentially do the same on IBM Cloud Satellite. We can basically lift the same Kubernetes configurations and operations templates and run them on containers and a Kubernetes system running in a distributed cloud location.

Other vendors use proprietary solutions that build their services with varying technologies that are not always based on Kubernetes. Some have their own containerisation approach or custom software approach. That setup makes it difficult for the vendors to move those services somewhere else in cloud regions.