z/OSMF in a DevOps context

The term DevOps (development and operations) describes a common approach to agile software development that application developers and operations teams can use to build, test, deploy, and monitor applications with speed, quality, and control.

Implementing z/OSMF in support of a DevOps initiative offers a number of benefits, including:
  • Faster code delivery
  • Feature-rich REST services that can be run locally or remotely
  • Isolation of workloads
  • More granular security, such as allowing access by DevOps user IDs, but not end users.

In general, a single z/OSMF server can easily handle requests from the system programming staff and from application developers or release engineers with their corresponding automation programs, such as Jenkins or other pipelines. However, if your business is implementing a DevOps strategy, z/OSMF offers a number of advantages in such an environment. It is possible to configure a second, dedicated server for handling workloads for specific applications or automation pipelines.

z/OSMF REST services extend beyond systems management

z/OSMF offers a variety of Representational State Transfer (REST) services that can be used for purposes beyond systems management by the various teams in your organization. By their nature, REST services are secure, can be run remotely, and are easy to include in programs. For example, consider the z/OS jobs REST interface services. With this API, any authorized user at your installation, if they are permitted to, can submit JCL jobs, retrieve job status, cancel or purge output, and retrieve job output. This API can also be used to handle code pages, provide regular expression searching, and so on. As with other z/OSMF REST services, the z/OS jobs REST interface services are not limited to use by system programmers.

REST services provide an ideal interface for creating DevOps style tooling for some z/OS operations. With automation programs, such as Jenkins, the pipelines can be run locally on z/OS and submitted through the z/OS jobs REST interface services directly or through the Zowe command-line interface (CLI). Or, the pipelines can be run remotely on another z/OS or non-z/OS platform. Ansible modules that can invoke z/OS jobs REST interface services are available in Ansible Galaxy.

As you consider how to deploy z/OSMF in your enterprise, consider the anticipated users. It can be convenient to divide them into three primary roles, as shown in the following table.
Role Common use cases z/OSMF advantage
System programmer Software management, editing of system control files, system administration, such as RMF, SDSF, and workload management (WLM).
  • Systems management task UIs
  • z/OSMF REST APIs for common programming tasks.
Application developer Creating applications to drive your business. z/OSMF REST APIs for common programming tasks:
  • z/OS jobs REST interface services
  • z/OS file and data set REST services
  • TSO/E address space services.
DevOps programmer Automating processes, creating pipelines, and provisioning system resources for in-house development projects.
  • z/OSMF REST APIs for common programming tasks (see above)
  • z/OS Cloud Provisioning and Management services
  • Ansible includes modules that can invoke z/OS jobs REST interface services.

It is possible to serve all three areas (applications, systems programming, and DevOps) with one z/OSMF server instance per sysplex, if the performance and availability of the server remains at acceptable levels for each area of usage. However, for applications, the requirement for availability tends to be higher than for systems programming or DevOps. Because z/OSMF does not run as a clustered server for system management purposes, it is recommended that systems programming and DevOps workloads be isolated from the applications workload. This means having one z/OSMF server for system programmers and DevOps and another one for applications.

Further, if you limit a z/OSMF server to handling just a subset of the z/OSMF REST APIs, you can more easily run the server in a high availability configuration, as described in Configuring z/OSMF to provide redundancy for subset of z/OSMF function.

Defining a second z/OSMF server

It is recommended that you define z/OSMF servers so that they can run on any system in the sysplex:
  • Define a home system and alternates.
  • When you define a second server, give it a unique name, such as IZUSRV2, to allow you to easily distinguish one server from the other.
  • The new server must be addressed separately; it is recommended that you use a virtual IP address (VIPA) with an independent hostname.
  • The system programmers can use the hostname and port of the main z/OSMF management server. The DevOps and Applications teams can use the hostname and port of the second z/OSMF server.
  • Define a unique SAF profile prefix for the new server so that you can define security for it separately, as described in Security.
  • You cannot use the z/OSMF autostart capability with the second server. Instead, plan to start the server by operator command or through an automation script.

Figure 1 shows how workloads can be distributed between three z/OSMF servers. In the figure, requests from special workloads are handled by dedicated z/OSMF servers. Specifically, requests for z/OS containers (zCX address spaces) are handled by server IZUSVR2 and server IZUSVR3. All other z/OSMF requests are handled by server IZUSVR1.

Figure 1. You can run multiple servers of z/OSMF, with each server processing requests from different groups in your organization.
You can run multiple servers of z/OSMF, with one or more servers being dedicated to handling special workloads and critical applications.

As mentioned earlier, it is possible to handle diverse workloads with one z/OSMF server instance per sysplex. However, you might consider setting up additional servers as described here if you are concerned about workload constraints, RAS (reliability, availability, and serviceability) and isolation of workloads.

Scalability

Though performance measurement remains a system-specific activity, IBM has verified the z/OS jobs REST interface services in sample workloads, with many hundreds of requests per second, per CPU. For most z/OS installations, this activity would far exceed normal workloads.

Some activities in the z/OSMF server can require more time to complete than others. In those cases, you might occasionally find that the server is busy and rejects a request. If so, you must try the request again. This risk is the nature of REST-based programming.

Availability

It is possible to run a z/OSMF server in a high availability configuration. For more information, see Configuring z/OSMF to provide redundancy for subset of z/OSMF function.

As an additional consideration, evaluate your settings for workload manager (WLM) to ensure that z/OSMF for DevOps resource consumption is limited for cases of accidental or unintentional high usage. Guard against situations such as:
  • Bad script in a Continuous Integration, Continuous Delivery (CICD) pipeline that drives repeated requests.
  • Errors in an integrated development environment (IDE).

Security

From a security standpoint, using multiple z/OSMF servers means defining a unique SAF profile prefix for each new server so that you can control which users can access it. The SAF profile prefix is specified in the IZUPRMxx parmlib member. This setup also requires that you create separate security definitions for each z/OSMF server in your external security manager. To see sample RACF commands for creating the security definitions, refer to the IZUNUSEC or IZUSEC members in SYS1.SAMPLIB. For ease of security management, it is recommended that you define a separate user group for each new server, and permit the group to the new server's security definition.

Isolation

You might choose to run more than one z/OSMF server in a sysplex, for cases in which it is desirable to manage workloads in a more isolated manner. However, a potential downside to having multiple z/OSMF servers is that the z/OSMF persistence data is also isolated. This means having a separate copy of user preferences, saved column widths, and other UI control settings. Also, the z/OSMF Systems table, which is used for defining local to remote system relationships, is not shared and must be maintained on each z/OSMF instance. Therefore, you should try to use the same z/OSMF server instance for all activities that are related to the isolated workload.