Hybrid Enhancements Across IBM Cloud Private and IBM Cloud

(Some of my hintervision thoughts are posted elsewhere. Here is an article from our Cloud Engagement Hub publication on Medium)

The goal of many enterprise clients is to be able to modernize key applications and run them wherever they want: On a private cloud in their own data center (where their sensitive data lives), on a public cloud (where they get scale, world-wide reach), or even better, on both private and public…where it becomes a true hybrid application taking advantage of the best of both environments.

In late March, IBM shared how clients could run their modernized applications in a hybrid environment across IBM Cloud Private and IBM Cloud Kubernetes Service in IBM Cloud. This essential capability, captured in the following video, showcases how a client can transform their application, where both development teams and cloud ops teams can both be delighted.

Watch: A Consistent Cloud Journey with IBM Cloud Private and IBM Cloud

Today, I am thrilled to share enhancements that make it even easier to create clusters, manage catalog content, and deploy developed apps across hybrid cloud environments. Specifically, with this latest enhancement of IBM Cloud Private 2.1.0.3, Fix Pack 1, users can extend a new or existing IBM Cloud Private deployment with the following capabilities:

  • Create additional Kubernetes clusters using a template from IBM Cloud Private
  • Curate which services developers have access to, and let them provision on either private or public clusters with self-service capability
  • Deploy a custom app into both private and public environments from the same developer environment

Create additional private and public Kubernetes clusters from your IBM Cloud Private Catalog

The first enhancement is the ability for any authorized user to provision a new IBM Cloud Private cluster or IBM Cloud Kubernetes Service cluster.

Here’s what you will need:

  • IBM Cloud Private
  • IBM Cloud Automation Manager
  • IBM Cloud account (with proper authorization)
  • Apply IBM Cloud Private patch

For example, once you install IBM Cloud Automation Manager onto your IBM Cloud Private cluster, you can create a brokered service (with customized variables limiting and controlling what options are available) that will let any authorized user create the IBM Cloud Kubernetes Service cluster onto your IBM Cloud account. An optional VPN can be automatically deployed to securely connect the two clusters, if desired.

Figure 1: Multiple clusters created from one IBM Cloud Private cluster

Here are the steps you will follow. For each step, I’ve added a link to the Knowledge Center (product documentation) that provides step-by-step instructions.

First, install and open IBM Cloud Automation Manager.

Figure 2: IBM Cloud Private catalog entry for Cloud Automation Manager

Second, add a “Cloud Connection” to IBM Cloud that uses your credentials.

Figure 3: Select “Manage Connections” to create a new connection to IBM Cloud using your account to create the Kubernetes cluster.

This connection will use your IBM Cloud account’s API key to communicate between Cloud Automation Manager and IBM Cloud. Be aware that once you set this up, Cloud Automation Manager will use your account to create IBM Cloud resources. Be sure that your IBM Cloud account has the necessary user permissions and can support the billing for your estimated product usage.

Third, create a custom service using an IBM-provided template to deploy an IBM Cloud Kubernetes Service cluster (with optional VPN connection) and publish it into the IBM Cloud Private catalog.

Figure 4: Select “Services” to create a new service in Cloud Automation Manager

This is really where you will harness the power of Cloud Automation Manager and its IBM-provided templates. Think of it this way: where in the past you would have to manually run commands or navigate a user interface to define the IBM Cloud Kubernetes Service, and then customize many details every time you provision a cluster, Cloud Automation Manager has provided all the details in a template. By creating this service, you provide a simple way to have your team provision a cluster when they need it, using the account (and limits) that you specify.

In addition to the previous link, here are some tips to creating the “Provision IKS Cluster” service (Figure 5):

Figure 5: Customizing parameters for your “Provision IKS Cluster” service

  1. Make cluster_name a service parameter so your user can specify it when they deploy.
  2. Specify private_vlan_id and public_vlan_id for the IBM Cloud region you want to deploy into. To find the values, run the following command in your IBM Cloud CLI (enter any location. In this example, ‘dal10’ is the location I want to deploy into): bx cs vlans dal10
  3. Make num_workers (the number of worker nodes for the cluster) a service parameter so your users can decide how many worker nodes their cluster needs. Note that this should be an array of the number of workers you authorize your users to select from. Maybe start with offering 2–5 worker nodes.
  4. Default machine_type so users can only select machines of the kind you default. To select your default, simply click the value column and all supported machine types will appear.

Note that you can optionally add a VPN template into your “Provision IKS Cluster” service so that you can privately communicate between your IBM Cloud Private cluster and your IBM Cloud Kubernetes Service cluster. If you choose to add the optional VPN connection, there are some IBM Cloud Private instructions for installing StrongSwan VPN, and IBM Cloud Kubernetes Service instructions and considerations to study.

Once you publish the service into the IBM Cloud Private catalog, you will allow other users a simplified way to create their own clusters.

Figure 6: IBM Cloud Private catalog with the service to provision IKS cluster that you just created

Fourth, deploy the “Provision IKS Cluster” service from the catalog. You’ll notice in Figure 7 that there are just a few parameters for the individual to fill out (the service you defined earlier filled in most of the defaults).

Figure 7: Deploying an IKS cluster from IBM Cloud Private

Now that your service is created, your development teams can deploy as many IBM Cloud Kubernetes Service clusters into the public cloud as they need.

Curate, to your enterprise standards, production services sourced from IBM Cloud Private and IBM Cloud Kubernetes Service into a single catalog.

The second enhancement is the ability to deploy production middleware into either IBM Cloud Private or IBM Cloud Kubernetes Service, all from your IBM Cloud Private catalog. This enhancement, coupled with the new IBM Cloud Private capability to limit what users have access to in the catalog, allows a cloud admin to give a developer a curated view of what they can deploy. Further, with IBM Cloud Automation Manager’s brokered service support, the cloud admin can create a service with multiple plans, so when a developer selects a plan in their catalog, IBM Cloud Automation Manager will deploy the proper version of middleware that maps to the selected plan.

For example, you may want to let a user “Create a database,” but without burdening them with all the specifics that a database Helm chart requires. Further, you have specific versions in mind, depending on where they deploy and who the user is. For instance, you may want to have only “dev” versions or “production” versions of the middleware on certain clusters, or even an open source Postgres database in IBM Cloud Kubernetes Service. With this new enhancement, you can create a brokered service through IBM Cloud Automation Manager to present a simplified view for the user to select their desired plan, hiding all the gritty details so that they can answer a few questions, deploy what they want, and you can manage the database instances far easier.

Here are the steps you will follow. For each step, I’ve added a link to the Knowledge Center that provides step-by-step instructions.

First, for Db2, IBM MQ, and Liberty, download your production middleware content from Passport Advantage. If you want to use development versions for Db2, IBN MQ, and Liberty, those are already available in IBM Charts.

Second, import the production Helm chart and container image into each cloud. Each platform has a “Passport Advantage Importer” tool to simplify this step. Click here to import into IBM Cloud Private, and click here to import into IBM Cloud Kubernetes Service. Note that once you import production versions of IBM MQ, Db2, and WebSphere Liberty, you are licensed to use them.

To import production middleware into IBM Cloud Kubernetes Service, you can either store the Helm charts in your local file system, or you can upload them into a private Helm repository. If you want to upload the charts into a private Helm repository, you will need to first deploy one into your cluster. IBM Cloud Kubernetes Service does not currently have a private Helm repository, so I recommend you install ChartMuseum, which will give you the needed private Helm repository in your IBM Cloud Kubernetes Service cluster.

Third, open IBM Cloud Automation Manager in IBM Cloud Private to create the brokered database service, or whatever brokered service you want. As you did before, click “Create Service,” and this time, open “IBM Cloud Private,” which will show all the Helm charts you can add to this service.

Figure 8: Create a “Data Service” in Cloud Automation Manager

One concept that you need to know: Since the goal is to have one service deploy charts into either IBM Cloud Private or IBM Cloud Kubernetes Service, the list of Helm charts listed in IBM Cloud Automation Manager needs to be the union of Helm charts available in both targets. For you, this means that your IBM Cloud Private cluster needs to add the Helm repo URL of the IBM Cloud Kubernetes Service cluster so that the charts show up in this list.

Fourth, now that you have your customized service created, you can curate (filter, limit) what services show up for your developer, Jane. As you can see from the Cloud Automation Manager capabilities above, you can surface most any service from any cloud to your developers, customize and limit what parameters they can edit, and now with IBM Cloud Private 2.1.0.3, you can filter the catalog so Jane can only see what you want her to.

For example, while earlier in Figure 6 the admin has 54 items in the catalog, Figure 9 shows that Jane can see only seven!

Figure 9: Filtered catalog view for “Jane” the developer. Notice “Database-Service” and “Provision-IKS-Cluster”.

To filter the catalog, add a team like “Application Developers” in the Manage > Teams view (Figure 10).

Figure 10: Showing teams in IBM Cloud Private

Once created, click the team name, and the “Resources” tab. This will show all resources the team is authorized to. What I really like is that teams can be authorized to a variety of resources across IBM Cloud Private:

  • Kubernetes namespace (for increased isolation and access control)
  • Helm repo (so devs can access only the collection of Helm charts you want)
  • Individual Helm charts
  • Individual brokered services

In Figure 11, you can see what application developers are authorized to. Notice that the database service we created previously has two plans, and the developers are authorized to both. However, you could authorize them to only one plan. This means that you could create one service and authorize portions to different teams…far easier to manage.

Figure 11: The resources available to application developers

Transform, develop, and deploy your application onto both IBM Cloud Private and IBM Cloud Kubernetes Service

The third enhancement revolves around helping developers migrate WebSphere apps and then deploying them into IBM Cloud Private using a pipeline to multiple Kubernetes clusters.

Here’s what you will need:

  • IBM Cloud Private
  • IBM Transformation Advisor
  • Microclimate

For example, to migrate a WebSphere application, start by running Transformation Advisor from your IBM Cloud Private instance. Transformation Advisor provides a data collector to add next to your WebSphere app, and it will provide recommendations on how to migrate it into a containerized WebSphere Liberty runtime on IBM Cloud Private.

In Figure 12, Transformation Advisor shows the results of its analysis. As you can see, each file is shown, the issues (how complicated it would be to migrate), and a migration plan.

Figure 12: The resources available to application developers

In the migration plan for each file (Figure 13), Transformation Advisor shows all the deployment files it would create and provides a link to deploy the bundle.

Figure 13: The detailed migration plan for a specific bundle

To actually deploy the bundle, Transformation Advisor integrates with Microclimate. Microclimate is the end-to-end development environment that runs right inside IBM Cloud Private.

Figure 14 shows Microclimate and the projects that were created:

Figure 14: Microclimate and its projects

Once you select a project that you imported, you could update the Git repo with source code and soon you can update code, view logs, and even view app-level metrics like in Figure 15:

Figure 15: Coding and unit testing apps all within Microclimate

In fact, if you want to use one of the sample Microclimate apps , you can try it yourself.

Finally, to deploy the app to additional clusters (like a remote IBM Cloud Private or IBM Cloud Kubernetes Service), you can set up deployment pipelines additional clusters using these instructions.

Summary

As you can see, if you need to run your app in a hybrid environment that makes it easier for developers to provision services they need (wherever they may reside), and if your developers need faster ability to deploy across multiple Kubernetes clusters, these enhancements will be quite welcome since now, with IBM Cloud Private 2.1.0.3, Fix Pack 1, users can:

  • Create additional Kubernetes clusters using a template from IBM Cloud Private
  • Curate which services developers have access to, and let them provision on either private or public clusters with self-service capability
  • Deploy a custom app into both private and public environments from the same developer environment

I hope you give this a try, and if you need any help, contact IBM Cloud Private support here: http://ibm.biz/icpsupport

Resources:

Hybrid Modernization

Cloud Automation Manager

Passport Advantage — Production Middleware

IBM Cloud Private

Transformation Advisor

Microclimate

IBM Cloud Kubernetes Service

Related Posts Plugin for WordPress, Blogger...

3 thoughts on “Hybrid Enhancements Across IBM Cloud Private and IBM Cloud

Leave a Reply

Your email address will not be published. Required fields are marked *