Creating Your Distributed Cloud using IBM Cloud Satellite

This is the second article in the “Journey to a Distributed Cloud” series focused on how clients can achieve a hybrid Multicloud platform anywhere their apps need to run, yet still maintain “as a service” capabilities.

This is part 2. You can jump to part 1, part 3, or view all videos here.

Introduction

In my last article here, I introduced how clients who are on their journey to a distributed cloud can achieve these three desired outcomes:

• Build, deliver, and manage our applications across a hybrid multicloud environment
• Bring the best of cloud wherever we need it to run, yet maintain the simple “as a service” experience
• Use a common control plane to manage our apps, platform, and security across our multicloud platform

This article will focus on the foundational step of building a distributed cloud. I’ll show how to do this by using IBM Cloud Satellite. Before we start, if you are a visual learner, you can watch this video. I still suggest reading below since there is some additional content below.

Welcome to IBM Cloud Satellite

Think of IBM Cloud Satellite as a “Hybrid Cloud Mesh” that creates distributed cloud regions anywhere you have infrastructure (Factories, Edge environments, on-premises locations, even your home!). Through this hybrid mesh you can manage each location from a common control plane. Cloud Satellite does this by attaching remote infrastructure in a remote location to your Cloud Satellite control plane. This location can then be used by IBM Cloud services as deployment targets.

The benefits to you: You focus on innovation, while IBM SRE teams focus on managing the service you are using. In other words, you can start using Red Hat OpenShift, data services, AI services, developer services that are all SRE managed by the same hyperscaler team in IBM Cloud that already manages thousands of instances of that same cloud service.

Concepts

Here are the main IBM Cloud Satellite concepts you need to know:

• Cloud Satellite creates locations that IBM cloud services can use as additional targets to deploy their services.
• Each location has a local control plane where Cloud Satellite manages all provisioned services and communicates back to the central Cloud Satellite control plane.
• At least three hosts are required for a minimal control plane (recommended six).
• Additional hosts are required for each provisioned service.
• As with any other managed cluster, you need to plan for scaling the cluster and design it for resiliency, so having a handful of “stand-by hosts” will enable the Cloud Satellite control plane to add worker nodes if needed.

First, the End Result

The ultimate value is showing how easy it is to add a cloud service anywhere in the world you need the service to run. It takes three steps: Open the catalog, select the satellite location, create the service! It’s quite easy. Let’s take a closer look.

Open Cloud Catalog

As I mentioned earlier, since IBM Cloud Satellite is like a hybrid cloud mesh, it simply presents all Cloud Satellite locations as just another deployment target for IBM Cloud services. In this graphic you see the cloud catalog, and on the left is a “Satellite Enabled”. The list of services that support targeting is continually growing so for our example, I’ll use Red Hat OpenShift.

Select Satellite Location

Once I select to provision OpenShift, I see three main options, and one of them is “Satellite”. In the graphic, take notice of two things:

Resource Group: Even though I may be provisioning this service into a remote location, I can still centrally control access with IBM Identity and Access Management. This way all my resource groups, access groups, and individual access policies can be applied quite simply.

Location: This is my list of Cloud Satellite locations. In my environment, I can choose to create an OpenShift cluster in my AWS account, an IBM internal data center in Munich, a “Cloud Pak System” appliance in a dedicated IaaS location, and a few other isolated IaaS environments.

Identify Worker Pools

Once your location is selected, location-specific options are presented. In this example, I selected my AWS location where I have the Cloud Satellite control plane evenly spread across three availability zones. I can select to spread this OpenShift cluster across all three as well, and even select the type of compute I want and how many worker nodes per zone.

While some locations won’t have multiple availability zones, you can still specify multiple “zones”. The zones might be different rooms, different racks, or simply different server boxes.

When choosing the compute type (vCPU and Memory), you are actually selecting preference types that Cloud Satellite will use when selecting available hosts in the location but are still unassigned to use for this service. I’ll get into details later, but my recommendation is to have a handful hosts available as “stand-by hosts” so that at any time you can create a new cluster or Cloud Satellite can grow capacity of existing clusters.

One more thing: When creating an OpenShift cluster, I suggest you select the “Enable cluster access for Satellite Config” since this will add a number of multi-cluster management capabilities that we will discuss in a future article.

Create and Start Innovating!

Once you select create, the cluster will take 10–15 minutes to provision and configure onto the location you selected (just like it would if you selected to create a cluster in an IBM Cloud region).

Once it’s created, your OpenShift cluster will appear along with all your other managed clusters. In this figure I’ve got quite a few clusters created…some in Cloud Satellite locations, some in IBM Cloud.

Further, the new cluster will be managed by IBM SRE teams just like all the other clusters, where updated, patches, and other management activities will happen on your behalf, while other tasks are a shared responsibility. See this detailed list to see exactly what are the shared responsibilities.

Digging Into Cloud Satellite

Now that you see how easy it is to take advantage of existing Cloud Satellite locations, let’s walk through creating one.

Create Cloud Satellite Location

To create your Cloud Satellite location, simply open the Satellite UI and click Create. You will be shown three options:

• Amazon Web Services
  This option provides a Schematics workflow (using Terraform) and if you provide your AWS access keys, Cloud Satellite will provision the needed IaaS, as well as the number of EC2 instances you request (3 for the control plane, and all others for future clusters).
• Manual Setup
  This option is great for deeper configuration options in AWS or for any other locations.
• Satellite Infrastructure Service
  This option provides a complete end-to-end managed service by IBM Services to configure (and even stand up) infrastructure, the control plane, and all services and provide management of that environment.

In this example I’ll choose “Manual” and manually set up an AWS location. I simply name the location and click “Create”. The result is just an empty shell awaiting you to provide it the hosts to attach so it can fully configure the local control plane.

Attach Hosts

To configure the satellite location, I need to attach hosts. To prepare, I open the newly created location and download the “Attach Hosts” script. This script will be run on the hosts and “call back” to IBM Cloud to configure the location and establish the secure Satellite Link connection. It’s important to note that the location is designed to run behind your firewall, so as long as the hosts you select have egress to IBM Cloud, the hosts can be used as Cloud Satellite hosts.

To add hosts to the location, I open up my AWS EC2 dashboard, and in my case, I create a launch template. With the launch template I can select the RHEL7 image I want to use, the kind of VM (4x16 minimum), I select an existing VPC (Virtual Private Cloud) and then I can add the attach script to the User Data section.

In my example, I selected to create 14 instances: 6 for the local control plane (you can start with three), then eight VMs for future services. Of course, you will need to either use an existing VPC or create your own with the proper security group and ACL settings.

Once the EC2 instances were provisioned, the script ran automatically and called back to Cloud Satellite. After a few minutes, the Cloud Satellite location showed “Unassigned” hosts where I then assigned three to the control plane and left the rest to be used when deploying clusters. Remember earlier when I showed the Worker Pool? These are the hosts that the Create OpenShift cluster will select from. I also left a few hosts as unassigned since those would act as “stand-by” hosts for future capacity needs.

This graphic shows my location after it’s been living for a while: I have my control plane hosts, two OpenShift clusters, and a few stand-by hosts.

User Access

Once the IBM Cloud services are running in your location, your users can access them just like they would other cloud services. For OpenShift, all I need is to pass the OpenShift URL to the development team, or use the ibmcloud CLI to access. But remember, the cluster is running behind your firewall (or in an isolated VPC in AWS), so your devs will need direct access to that VPC in order to use the cluster.

Conclusion

Now that I have my Cloud Satellite location running, and I’ve got some OpenShift clusters running, I am now running a distributed cloud. This enables me to focus on innovating, managing my workloads, and let IBM SREs manage my cloud services like they do in thousands of instances around the world.

Stay tuned for how we start using this distributed cloud to build, deploy, and manage applications across this distributed cloud!