z/OS Cloud Broker Enables z/OS Resource Consumption
IBM z/OS Cloud Broker enables the consumption and lifecycle management of z/OS resources through a standard cloud environment such as IBM Cloud Private.
To give developers a friendly user experience when developing for IBM Z*, we need to shift away from traditional models of resource consumption and understand how resources are readily consumed in the rest of the development world. With the click of a button, developers can now receive databases, application servers, message queues and seemingly endless other resources. Developers’ ability to manage their own environments is now a staple. Without it, agility and efficiency is lost. This is precisely where IBM z/OS Cloud Broker helps bridge the gap for workloads on z/OS.
IBM z/OS Cloud Broker enables the consumption and lifecycle management of z/OS resources through a standard cloud environment, such as IBM Cloud* Private (ICP), by implementing a specification called the Open Service Broker (OSB) API. This specification has been adopted in many cloud environments, from Kubernetes, to Cloud Foundry, OpenShift, IBM Cloud and more.
Catalog Management and Provisioning
Using IBM z/OS Cloud Broker, developers can log into a common cloud platform such as ICP and view a catalog of resources consisting of traditional distributed or containerized services, as well as resources available on z/OS environments in their IT ecosystem. This enables developers to bridge the skill gap when creating applications on both z/OS and common distributed workloads.
Let’s look at how this is all enabled through z/OS Cloud Broker. First, a cloud administrator installs the IBM z/OS Cloud Broker package into ICP. As part of the installation, the cloud administrator specifies the z/OSMF endpoint that z/OS Cloud Broker will be connected to as well as a z/OSMF Cloud Provisioning domain. For z/OS Cloud Broker to enable consumption of resources from ICP, the z/OSMF environment must include a configured IBM Cloud Provisioning and Management for z/OS. For more information about IBM Cloud Provisioning and Management for z/OS, see the Cloud Provisioning and Management content solution (ibm.co/2DF8jfo).
z/OS Cloud Broker communicates with Cloud Provisioning and Management, discovers “templates” and exposes those templates for consumption from ICP as “services,” as shown in Figure 1, below. A template in Cloud Provisioning and Management describes the software that’s to be provisioned. For each template in the z/OSMF Cloud Provisioning domain, there may also be a set of associated tenants that allow resource consumption management on z/OS may also be included. These tenants get registered as “plans” under the specified service.
The cloud administrator works with a security administrator to define the visibility of the services and plans that were created. It may be necessary for certain teams to have access to some services and plans but not others. The cloud administrator can easily configure this through the cloud platform so that a developer’s catalog view shows the members of a team only what they can consume.
Once the catalogs are updated for the various teams and developers, users in a cloud platform like ICP can easily provision and manage resources directly on z/OS. Middleware that once took days or weeks to become available due to internal change management and request processes can become available in minutes. This includes any middleware that's currently supported by Cloud Provisioning and Management, such as CICS*, Db2*, IMS*, MQ*, WebSphere* Application Server Liberty, and z/OS Connect. Leveraging Cloud Provisioning and Management as a standardization layer, custom templates can support any resource creation and management process that exists on z/OS. Using this framework, enterprise clients and z/OS users can quickly create repeatable and automatable patterns that their development teams can use.
Binding Applications and Services
So far, we’ve only addressed the beginning of a z/OS resource’s lifecycle: provisioning. However, quickly and easily provisioning resources doesn’t cover the full requirements of a cloud-native platform. This is where the true power of the OSB specification comes into the picture.
An optional but important part of the OSB specification is the capability to “bind” applications and services together. The idea here is that if you provision a resource such as a Db2 schema, you should be able to consume that Db2 schema from your application dynamically. Following a 12-factor application development model, applications should have the concept of environments that consume information about their runtime based on where they are deployed. The OSB bind mechanism accomplishes exactly that.
In your cloud platform environment, you can first provision a z/OS resource such as a Db2 schema, then bind that new resource to other applications running in your cloud platform and ingest connectivity information for this new Db2 schema. For Db2, this may result in building JDBC connection URLs or JNDI bindings directly from the dynamic variables that come back from the newly provisioned Db2 schema.
In ICP, or Kubernetes in general, the OSB bind mechanism creates Kubernetes secrets. These secrets can be consumed across the Kubernetes ecosystem. For containerized applications running in pods, the secrets can be injected into the pod configuration and they will become environment variables for your application to consume at runtime. But, when dealing with native z/OS workloads, it’s likely that not every consumer of z/OS resources will be a containerized application. In this case, application architects have the choice of how they want to consume these Kubernetes secrets for their automation processes.
As an “in-the-box” solution, an application architect might create a Kubernetes job that will ingest the information of this Kubernetes secret and run some scriptable automation to interact with the provisioned z/OS resource. For example, let’s imagine a relatively simple application called JDBC-Viewer with a front-end component that runs in a containerized deployment model and a Java* back end, running on CICS, connected to a Db2 data source (see Figure 2). This full stack, across both containers in Kubernetes, and z/OS resources, can be deployed and managed with a single click in ICP using z/OS Cloud Broker.
With z/OS Cloud Broker, an application architect can construct a Helm chart that provisions the required z/OS resources, waits for them to be online and connects the front-end application to the exposed resources. Within the Helm Chart, YAML files describe the resources that will be provisioned:
- CICS and Db2 ServiceInstance resources. These instruct Kubernetes to send provision requests to z/OS Cloud Broker for the respective middleware on z/OS.
- The ServiceBinding resource. This requests z/OS Cloud Broker to return Kubernetes secrets about the connection information of this new Db2 schema and CICS environment. With this information, and a little knowledge of the available z/OS REST APIs, a user can easily create a bootstrapper job to deploy the Java back-end application into CICS and connect it to Db2 using JNDI bindings.
- The CICS secret also contains information for connecting to the CICS environment with the Java back-end application. This secret can now be ingested into the front-end application, and the containerized front-end applications can now retrieve their data from CICS using REST APIs.
Figure 3 represents a simple example of an automatable solution using z/OS Cloud Broker and in-the-box abilities of Kubernetes. However, there’s no reason that Kubernetes jobs need to be used for this automatable process. External automation tools like Jenkins can drive the creation of the required Kubernetes resources (both z/OS and containerized) and perform the application deployment and integration as the application architects desire. This opens up the ability to automate the z/OS platform in new ways for the middleware products mentioned earlier.
Dashboards and Resource Cleanup
Beyond automation processes, z/OS Cloud Broker provides end users with a dashboard for each service instance that’s created for a z/OS resource. The dashboard provides high-level information about the provisioned z/OS resource as well as the ability to run actions against the resource, such as starting or stopping a CICS server or performing a backup of a Db2 schema and restoring that backup later. Each action is customized as part of the template in Cloud Provisioning and Management. Custom actions can be created for any reproducible pattern.
When provisioned resources are no longer needed, developers can easily deprovision them, freeing up the resources on z/OS. Developers can manage the full lifecycle directly, with no need for the z/OS system programmer to be involved. This frees the z/OS system programmer to focus on creating and maintaining the environment that drives all of the automation. As each z/OS environment has a different set of knobs for proper middleware configuration, the z/OS system programmer’s responsibility for controlling those environments is more important than ever.
The Cloud Journey
Cloud-native experiences and automation is a journey for z/OS consumers and developers. Using z/OS Cloud Broker allows enterprises to consider new development and delivery paradigms for their core applications. IBM is dedicated to helping clients succeed on this journey. For more information, or if you’re interested in joining our trial program, please reach out to us through your IBM representative. For help getting started and links to technical resources, see the z/OS Cloud Broker content solution (ibm.co/2DF8jfo ).
Ivan Dovgan is a full stack engineer for the IBM Z Innovation Lab, focusing on modernizing the mainframe from an "outside-in" approach.
William Keller is a content designer for z/OS.
Sponsored Content3 Unknown Risks in Your Resiliency Armor
Post a Comment
Note: Comments are moderated and will not appear until approvedcomments powered by Disqus