Automate and Optimize with Mainframe Infrastructure APIs
{Ecosystem} Mainframe modernization is being driven by a number of factors, not least of which is the requirement to move fast while retaining the absolute focus on security for which the platform is rightly lauded. Typically the pathway to modernization will include both application and tools modernization, as well as introducing automation into existing processes, all of which will boost the value you can deliver to customers. One of the outcomes of a successful modernization strategy is a mainframe environment that can act like any other platform in your technology stack.
A key enabler of mainframe modernization are APIs and, in particular, infrastructure APIs. How do we define infrastructure APIs? Who are the actors creating and consuming these APIs? And what role does The Open Mainframe Project’s Zowe play as an enabler and accelerator? Let’s find out!
Of course, APIs for the mainframe have been around for some time. In any well established mainframe site, there exists a rich history of investment in development processes, security protocols and workload fine-tuning. Over the years, as new software development methodologies have appeared, and been adopted, we have seen a plethora of new tooling, artifact hosting platforms, vulnerability scanning services, monitoring systems, ticketing systems and much more. Many of these were not initially intended directly for use on the mainframe but with the magic of APIs they can in most cases be integrated.
That’s because REST APIs are a relatively universal way of tying things together and can be used and reused in many new and interesting ways.
Defining Mainframe Infrastructure APIs
Infrastructure APIs are used to optimize and automate the internal tools your organization uses to run your business. They are used by administrators to manage core systems in a more automated fashion. For example, the owner of a batch job might want to consume a REST API to directly react to incidents and make config changes. In this case, the API enables the replacement of a manual process involving an Operator and ticketing system that existed beforehand.
Infrastructure APIs can be defined in opposition to business APIs which offer a service to your organization’s end-users. For example, a bank allowing their debit/credit card customers to make payments via the Apple or Google Pay application will likely involve the use of a mainframe business API.
Now let’s look at two mainframe API stakeholders.
API Producers and API Consumers
API Producers build, expose and operate APIs. In mainframe sites, Producers are often found within Infrastructure and Operations teams. Engineers within these teams want to automate and optimize interaction with their core systems and will create their own internal infrastructure APIs as a means to achieve those goals. At the same time, mainframe software vendors such as Broadcom and IBM are increasingly building infrastructure APIs for their new and existing solutions, reducing and sometimes eliminating the need for these internal infrastructure APIs to be built.
API Consumers are engineers, typically found in Infrastructure and Operations teams, who exploit infrastructure APIs. These APIs could be created by a Producer within the company or organization and found in an internal catalog, or they could be built and provided by a vendor as part of a commercial offering. API Consumers have the same end goal as Producers in that they are looking to optimize internal tooling used to run their organizations. For example, API Consumers might be developing a dashboard application that requires infrastructure APIs to access mainframe resources.
Zowe supports Both Producers and Consumers of Infrastructure APIs
Zowe has a role in supporting both Producers and Consumers.
By adhering to a conformance program established by the Zowe community, Producers are empowered to build their infrastructure APIs in a consistent and standardized manner. The conformance criteria are essentially a set of building codes describing how the infrastructure API should behave and how the Consumer should interact with it. Producers who meet the criteria are eligible to apply for a digital badge indicating that their API is Zowe-conformant. Much of the conformance centers around compatibility with a single access point to mainframe APIs, the Zowe API Mediation Layer. Ultimately, Zowe conformant APIs are secure and easy to maintain as a direct consequence of adhering to a set of standards.
Choosing to exploit a Zowe-conformant API gives Consumers the confidence that these can be quickly deployed as part of their Zowe environment and partake in the additional management related benefits offered by the Zowe API Mediation Layer. Broadcom is committed to building out a catalog of Zowe conformant APIs for its solutions. Indeed, many Broadcom solutions already have infrastructure APIs available, thereby enabling organizations to modernize and automate faster.
Finding Zowe conformant APIs
As a potential mainframe API consumer, you need to understand what infrastructure APIs are available with your specific objective in mind. As an example, earlier I referenced a dashboard application, which might have you searching for a SYSVIEW or IDMS REST service.
Your first step might be to visit zowe.org where you can see a complete list of zowe-conformant APIs for both Zowe V1 and V2.
After finding your target REST services you can dive into the available technical documentation to learn more about what the API can do.
Of course, once you have the Zowe API Mediation Layer installed, with Zowe conformant APIs onboarded, you have a real time view of what infrastructure APIs are available and active at your site for immediate use. Let’s take a closer look at what that actually means.
APIs are the bedrock of Zowe
As you can see above, the Zowe ecosystem offers a growing number of Infrastructure APIs that provide programmatic access to mainframe resources. And we know that the Zowe Conformance Program gives users the confidence that when they use a product, app, or distribution that leverages Zowe they can expect a high level of common functionality, interoperability, and user experience.
APIs that allow CLIs and other client applications access to infrastructure services on the mainframe are at the heart of Zowe. The API Mediation Layer’s role is to manage infrastructure APIs originating from z/OS. In the same way that Kubernetes or AWS is tightly coupled with a mediation layer to manage the APIs they offer for operational purposes, so the Zowe API Mediation Layer is intended to provide gated, performant access to z/OS services used by teams for DevOps and IT automation.
I discuss the general benefits of the API Mediation Layer in a recent post here.
Relevant to this particular post is the role of the API Catalog. This is a component of the Mediation Layer that provides an interface to view all onboarded Zowe-conformant APIs, including Swagger documentation and code snippets, in a user-friendly manner.
The API Catalog gives you a single view of the available infrastructure APIs at your site. As the image above shows, you can use the Catalog to see the services available for use in your environment. This isn’t a view of all infrastructure APIs available from mainframe vendors, but rather a view of which APIs you actually have installed and running.
Clicking on one of the tiles on the home page takes you to API documentation for that particular service. Here you can see API documentation, descriptive information about the service, the current state of the service, service endpoints, and detailed descriptions of these endpoints. The doc is Swagger-based. The Catalog also supports “Try it out” functionality. That is, users can call service APIs directly from the Catalog and verify the response body.
As of Zowe 2.3 code snippets are now also part of the catalog. So, as an API Consumer you can quickly try out the actual real world API code and, if it matches your needs, grab it in your preferred language and use it in your own code base.
Onboard your own Infrastructure APIs to the Catalog
The Zowe API Mediation Layer is not just geared towards exploiting the available Zowe-conformant APIs built by Broadcom and other mainframe vendors. It can also be used to mediate your internally-developed infrastructure APIs.
These internally-developed infrastructure APIs can easily be onboarded to the API Mediation Layer using a special wizard in the API Catalog without the need to make any code changes. They then can be seen and documented alongside vendor produced Zowe conformant APIs in the API Catalog. If you’re looking for a home for all those APIs you’ve developed, if you want to foster greater awareness, collaboration and innovation around those existing APIs, then consider the Zowe API Mediation Layer as a ready made solution.
APIs Power Zowe Clients
Finally, APIs have another important role within Zowe. They power popular clients such as the Zowe CLI or Zowe Explorer to give them access to resources on the mainframe.
The Zowe CLI is a command line interface that calls mainframe infrastructure REST APIs. The CLI provides a core set of commands for working with data sets, USS, JES, as well as issuing TSO and console commands. It also has an ecosystem of plug-ins allowing you to automate actions on systems such as IBM Db2, IBM CICS, and more. All powered by APIs.
The Zowe Explorer is a VS Code extension that lets you interact with data sets, USS files, and jobs that are stored on z/OS. All enabled by APIs.
Infrastructure APIs in the real world
For inspiration, I want to finish by pointing you to two examples of how mainframe APIs could be used in production environments today.
- John Benbow shows us how Application teams, SREs and DBAs use the Sysview for DB2 REST API to guard against performance degradation.
- Domenico D'Alterio describes how application programmers, operators, schedulers and quality engineers can use the IBM Z JCL Expert CLI plugin and REST API to avoid errors in your JCL and ensure you meet site standards.
All Zowe releases are available at zowe.org/download. The Zowe API Mediation Layer can be found in the ‘Server Side Component Installer’ and can be installed as SMP/E, convenience build, Portable Software Instance (PSWI) or a container image for running unix components under K8s orchestration.
You’ll find the Broadcom distribution of Zowe at support.broadcom.com in the ‘My Downloads’ area if you are a Brightside customer, or if you’re licensed for a Broadcom product or solution that requires the Zowe API Mediation Layer such as Endevor. Alternatively, you can also access a Broadcom distribution of Zowe here.
If you enjoyed this blog check out more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #zowe-apiml, #zowe-cli, #zowe-dev, #zowe-user, or #zowe-onboarding.
If this is your first time using the Open Mainframe Slack Channel register here.
Zowe is owned and managed by the Open Mainframe Project, which is a Linux Foundation project.
Thanks to Dan Kelosky and Michael DuBois for their invaluable input to this blog.
