Prevent multicloud mayhem

As services scale, there is an increasing need for applications to be distributed across different clouds. For example, an app on your phone could be using compute resources from one provider, while pulling static images from another. Using more than one provider’s cloud is simply the way things will be. But working across multiple clouds from multiple vendors may create problems that can only be solved with effective management.

In a previous article, I demonstrated the consistency of Red Hat OpenShift on different vendor clouds to show the neutrality of the platform. I explained the process of taking an application (for a fictitious healthcare company called Example Health), which consists of three microservices running in an OpenShift cluster on IBM Cloud, and splitting it up to run on three different non-IBM clouds, thereby demonstrating a lack of vendor lock-in. I used the following diagram to describe the result:

diagram of proposed multicloud application

The outcome looks simple, but the article glossed over some of the nontrivial legwork involved with getting all three services implemented. Differences across providers include:

  • Account set-up
  • Service provisioning
  • External access configuration
  • Separate credentials
  • Monitoring strategies

While there are benefits to spreading your workloads across multiple clouds, my exercise is certainly not production ready. As it stands, if any one of the three providers I chose suffers an outage, the entire application fails. Clearly, that would not be ideal in a production environment.

Benefits of multicloud management

If you are working with IBM Cloud and other providers, you can benefit greatly from using IBM Cloud Pak for Multicloud Management, as it provides a solution to all the shortcomings listed above when working across multiple clouds. The Cloud Pak itself has many working parts, but adding managed cloud providers can be handled from a single screen in the web console. Adding clusters to be managed is as easy as a single command and, once issued, you can see them on an overview screen like this:

screen capture of first sample cluster in Cloud Pak for Multicloud Management

This screen capture was taken after I added my first cluster. The cluster already existed before I added it to be managed, but with the optional Terraform & Service Automation Module, you can create clusters from within the UI. Notice that the Cloud provider is listed in the summary section, which in this case is IBM. To fully execute my original exercise, I will need a couple more clusters. They will be hosted by IBM as well, but as far as IBM Cloud Pak for Multicloud Management is concerned, they could just as easily be hosted by additional cloud providers (or even something local, on-premise that you have set up yourself).

screen capture of Overview page in Cloud Pak for Multicloud Management

In Cloud Pak for Multicloud Management, infrastructure orchestration is independent of the application layer. You can add and remove clusters at will without interrupting running workloads. Once your clusters are set up, you can then describe your application and the Cloud Pak will do the work of distributing the services across the clusters.

Applications are managed by declaring them as custom resource definitions (CRDs), a concept native to Kubernetes. The basic building block in Cloud Pak for Multicloud Management is a channel. A channel can be a Kubernetes namespace, an object store, or, as in the case of deploying the Example Health use case, a Helm repository:

apiVersion: app.ibm.com/v1alpha1
kind: Channel
metadata:
    name: ExampleHealth
    namespace: ExampleHealth
spec:
    type: HelmRepo
    pathname: https://10.12.107.150:8443/helm-repo/charts
    configRef:
      name: insecure-skip-verify

Next, a placement rule can define onto which particular clusters a channel can be deployed (they must have the same tag). By combining a channel and a placement rule to create a subscription, you start to get the idea of how an application is described. Once implemented, you can see a diagram of the Example Health application under the Resource topology section:

Screen capture of Resource topology section in Cloud Pak for Multicloud Management

Conclusion

By experimenting with Cloud Pak for Multicloud Management for this article, I can see how it could help anyone looking to operate at scale. This is surely a domain set that will become more important as more organizations journey to the cloud. Watch this space for an upcoming code pattern that further describes the implementation of a Example Health use case, as well as scenarios demonstrating resource redistribution and application monitoring.