An Introduction to Hybrid Applications

6 min read

The IBM Cloud Pak® for Multicloud Management enables organizations to securely manage applications, no matter how they are designed or where they are deployed.

The IBM Cloud Pak for Multicloud Management is a set of open, pluggable tools built around a core application and governance model. This core architecture helps organizations model applications and application dependencies, manage the lifecycles of both applications and infrastructure, consistently govern and secure applications and their deployment models, and deliver observability for the application’s full stack.

The IBM Cloud Pak for Multicloud Management now includes a Hybrid Application Model for application management.

Kubernetes and container technologies have developed rapidly in the past years. There is no doubt that IT infrastructure, in general, is moving in this direction. Before this technology arrived on the scene, virtual machine technology had become a popular platform for developing applications. At the same time, other technologies like cloud services were also trying to help modernize applications. Managing application components across these various platforms has become a nightmare for many enterprise IT departments.

This blog will introduce you to the Hybrid Application Model, which provides centralized application management across containers, virtual machines, cloud services, and more. This blog will also show you how to integrate with Jenkins for a simple CI/CD pipeline for continuous delivery of your hybrid applications.

What is the Hybrid Application Model?

The Hybrid Application Model is a specification and implementation model that provides flexibility to users to describe various application component form factors and manage them through centralized processes. Since Kubernetes and container technology is trending in popularity, this application model is defined and implemented on Kubernetes Custom Resources. This model starts with the Application definition in Kubernetes Special Interests Group (SIG-Application) and extends the definition with additional custom resources definitions (CRD) to create hybrid applications.

Applications

The Kubernetes Special Interest Group (SIG) introduces the Application project to define Applications so that they are interoperable across many support tools. In general, an Application is a group of resources. The Application definition in this project groups certain kinds of Kubernetes resources using labels and adds additional descriptors to those resources. This definition provides flexibility for users to include whatever components they need in an application, as long as the component is represented by a Kubernetes resource.

Deployables, channels, and subscriptions

Now that you have an understanding of the Application definition, what exactly can you group as an Application?

If you have just a single Kubernetes cluster, the answer is simple — an Application groups the Kubernetes resources in that cluster. This grouping can be achieved using the default SIG-App project. You might want to use a Kubernetes cluster to manage other platforms that are providing you with containers, virtual machines, cloud services, and more. In other words, the resources to group might not be deployed or executed in the management cluster. You need a way to describe the resources of an application so that the resources can be deployed to the desired platform. The actual resource that is being described can exist within a separate source controlled system or within the management cluster without any external dependencies.

To help group and manage these resources, the following additional custom resources definitions are added in the Hybrid Application Model:

  • Channel and Subscription custom resources are introduced to identify resources that sit outside a Kubernetes cluster. A Channel defines the access to where those resource are stored. A Subscription defines the filter to select resources from a specific Channel. This pair of custom resource definitions provide the Hybrid Application Model with a way to connect various continuous integration systems.
  • A Deployable custom resource is introduced to define a resource within the management Kubernetes cluster. A Deployable is an an aggregation of various form factors of the same application component. For example, a MySQL database is a MySQL database whether it is deployed as a virtual machine, or as a series of containers, or provided as a service by a cloud service provider. Only one Deployable resource is needed to represent that MySQL database component. Within that Deployable, the resource defines how that MySQL database is deployed when a different platform is picked.

Placement rules

After an Application resource is defined and its components grouped, the next step is to define the target platform where the resources need to be placed. The PlacementRule custom resource is introduced for users to use to define criteria to select the target platform where the application and its components are deployed. The PlacementRule target is determined first by the platform type and then by selecting one or several instances from the remaining candidate targets. Labels or other user-defined criteria are used to select instances.

Deployers

To represent or model the various platforms that you might want to use into a resource type within Kubernetes, the Deployer custom resource is introduced. This custom resource defines the resource type to classify itself within Kubernetes. Even with the same technology, you can have different Deployer types. For example, to deploy a resource into a Kubernetes cluster, Kubernetes Cluster Federation (KubeFed) and Red Hat Advanced Cluster Management are both valid options as a type of Deployer. Deployer instances that have the same type represent different systems for connecting to the same system or different access to the same system.

Manage applications with the Hybrid Application Model

The Hybrid Application Model is capable of managing application components across containers, virtual machines, and cloud services. We’ll go over an example to help demonstrate this management capability. Since every platform and component is represented by a Kubernetes custom resource, it is easier to start with an example that uses pure container resources.

The following example uses a guestbook application. This “Guestbook” example uses the open source automation server Jenkins to demonstrate how easily you can create Hybrid Application Model resources and integrate with a CI/CD system for continuous delivery. If you want more examples, the Kubernetes community provides many examples to help you deploy resources into a single Kubernetes cluster.

1. Create the application resources

 There are six (three pairs) resources in the Guestbook example:

  • A “frontend” Deployment and Service
  • A “redis-master” Deployment and Service
  • A “redis-slave” Deployment and Service

Six hybrid Deployable resources are created to wrap each of these resources. All of these hybrid Deployable resources share a label so that they can be later selected by the Application resource.

Placement rule (PlacementRule) resources are created and referenced by those hybrid Deployable resources to determine the managed cluster to which to deploy the Deployable resources. Since Kubernetes does not support using a Service to select a Pod in different clusters or namespaces, a Deployment and Service pair needs reference the same PlacementRule resource.

The last, but not the least, resource that is created is the Application resource. The Application selects the hybrid Deployable kind for the Deployable resources by using the common label that is defined within the resource definition for all six Deployable resources.

Samples for all of the referenced Hybrid Application Model resources are stored in the hybridapp.io community.

2. Manage the continuous delivery process with Jenkins

This example uses Jenkins, which is a popular open source tool for continuous integration and continuous delivery (CI/CD) processes. There are many plugins available for use with Jenkins to integrate with various assets, including GitHub and Kubernetes. While credentials to access GitHub and Kubernetes need to be securely protected in a real production environment, this example skips this protection to demonstrate the simplest approach for integration.

  • Step 1. Set up Jenkins to access the IBM Cloud Pak for Multicloud Management hub cluster: Copy the kubeconfig and other related files to your Jenkins server. Add the files to a folder that your Jenkins user account is able to access, such as var/lib/jenkins/config. Install the Kubernetes command-line tool (kubectl) on the Jenkins server. For more information, see Install and Set Up kubectl.
  • Step 2. Create the Jenkins pipeline to build and deploy the Hybrid Application Model resources:
    Create the Jenkins pipeline to build and deploy the Hybrid Application Model resources
    On the Configuration page, add a script to clone the sample resource files from GitHub and apply the files. Then, save the configuration:
    On the Configuration page, add a script to clone the sample resource files from GitHub and apply the files. Then, save the configuration.
    The following code snippet is a sample script to use for the pipeline. The GitHub repository that is referenced in this example is read-only. Change the repository to be your own repository that you want to use for continuous integration:
    pipeline {
        agent any
        options {
            skipStagesAfterUnstable()
        }
        stages {
            stage('Build') {
                steps {
                    echo 'Building'
                    sh "rm -rf samples"
                    sh "git clone https://github.com/hybridapp-io/samples.git"
                }
            }
            stage('Test') {
                steps {
                    echo 'Testing'
                }
            }
            stage('Deploy') {
              steps {
                   script{
                       sh "kubectl --kubeconfig=/var/lib/jenkins/config apply -f samples/guestbook/model/all-in-one.yaml"
                   }
                }
              }
        }
    }

3. Build and deploy the Application

After your pipeline is created, click the Build Now link in the Jenkins console to clone and deploy your application. The following image shows an example pipeline stage:

After your pipeline is created, click the Build Now link in the Jenkins console to clone and deploy your application. The following image shows an example pipeline stage:

Then, go to your IBM Cloud Pak for Multicloud Management console to verify that the Application is created. If you didn’t change the PlacementRule setting, the Application is not deployed to an actual cluster:

Then, go to your IBM Cloud Pak for Multicloud Management console to verify that the Application is created. If you didn’t change the PlacementRule setting, the Application is not deployed to an actual cluster:

Update the PlacementRule in your repository with the right cluster selection. Then, build the pipeline again in Jenkins. Finally, use the IBM Cloud Pak for Multicloud Management console to verify that the Application is deployed to the correct managed cluster:

Finally, use the IBM Cloud Pak for Multicloud Management console to verify that the Application is deployed to the correct managed cluster:

Getting started

You should now have an understanding of what the Hybrid Application Model is within the IBM Cloud Pak for Multicloud Management and how to leverage this model to manage your applications across your containers, virtual machines and cloud services. With this knowledge base, you are now ready to try hybrid applications for yourself.

Further reading

Be the first to hear about news, product updates, and innovation from IBM Cloud