IBM Z and LinuxONE - IBM Z

IBM Z

The enterprise platform for mission-critical applications brings next-level data privacy, security, and resiliency to your hybrid multicloud.

 View Only

Ansible for IBM Z User Spotlight Series: Stewart Francis

By Andreina Dyer posted Wed December 11, 2024 08:03 PM

  
The Ansible for IBM Z User Spotlight Series banner with featured user Stewart Francis

Getting to know Stew Francis

Stew Francis joined IBM after graduating from Cambridge University in 2003. Working from IBM’s Hursley Park location, he currently leads the CICS TS Modernization team in a technical capacity. Stew and his team focus on improving multiple aspects of the developer experience. He regularly attends conferences to share exciting news and valuable insights on using Ansible, z/OS, and the CICS TS collection.

How did you get started with Ansible?

I joined IBM right out of university and spent most of my time working with CICS. I started as a junior developer working on CICS Explorer, which is our graphical system administration console. I eventually became the lead developer and subsequently head of the Developer Experience Modernization team. Since then, I’ve been involved with modernizing CICS’s Java development toolchain and most recently with Ansible integration for CICS TS. 

“Ansible has streamlined provisioning tasks significantly, offering broad functionality.”

Why Ansible?

CICS has a powerful REST API that drives the data and interactions you can use to manage your CICS regions. We created an Ansible collection to see if we could make it easy to call that API with Ansible, which would be a nice fit for lots of Ansible-based workflows. The ability to manage the state of your CICS region through Ansible workflows was a big part of the motivation.

What benefits has Ansible brought to your team and how usable has it been?

Our team is responsible for several CICS environments, and we’ve been using our Ansible collections to manage those. Ansible has streamlined provisioning tasks significantly, offering broad functionality. Despite the team being new to z/OS, Ansible’s relatability and compatibility with Python have been highly beneficial because it has allowed new team members to contribute effectively to collection enhancement, especially with tools like Microsoft Visual Studio and the Red hat Ansible extension, which facilitates quick onboarding and ease of use.

In your view, how does Ansible measure up to other modernization technologies?

Ansible is popular and has a lot of momentum because of its success on other platforms. The technology is powerful, and the Ansible Automation Platform brings additional capabilities. The available collections — whether they’re hosted on Galaxy or the Automation Hub — bring great out-of-the-box support. That all works in Ansible’s favor.

Was there a moment when you really grasped Ansible’s potential and proved itself to you?

We have a CICS region with quite old pieces of automation made from REXX and JCL that we use each time we create an instance or change a configuration. We built a replacement automation with Ansible. Both automations achieve the same task, but the quality of the result and the overall experience are much better with Ansible.
Similarly, when we started using the Ansible Automation Platform to manage our development systems, we moved from a world where each user must check their system for changes and run upgrades manually to one where we can update each user’s system automatically. That’s not difficult with Ansible, 
and it’s great to provide a service rather than tell people that they have a 
chore to do.

How well does Ansible fit into existing information flows?

Many of our client conversations are around how Ansible fits within their existing automation landscape. That use case highlights Ansible’s strengths — you can use it for raw automation, but you can also use it as a kind of automation integration fabric. Ansible is extensible and relatively unopinionated, so you can use it to drive existing system automation or ZOSMF processes, call a piece of JCL, execute a bit of REXX, run a Python automation script, or bring all things together into a single automation. You can then surface the result in the Ansible Automation Platform to make it available to everyone.

“Ansible is extensible and relatively unopinionated, so you can use it to drive existing system automation…or bring all thing together into a single automation”

Why use Ansible over other z/OS automation tools?

There has never been a case where Ansible has not been a good fit to solve automation problems. If I have a process with a lot of manual components, I always feel like I can use Ansible to handle the low-level building blocks, particularly with the features available in the z/OS Core collection. The built-in templating support, conditional processing, and playbooks make it quite adaptable to fit those niches. To get a feel for Ansible, it’s often just a case of working hands-on with its capabilities, getting familiar with the z/OS core collection, and trying to automate a few things.
The Ansible approach to automation is different from that of other tools on the Z platform, but when I talk to clients, I find that many already have Ansible Automation Platform deployed somewhere in their organization, so it can be quite a short journey to develop automation and make it accessible to their colleagues as a service. This makes it easy for them to realize value from that automation.

Stewart Francis presenting at SHARE Kansas 2024

Tell us about the Ansible 101 presentation you recently gave at SHARE in Kansas City and its major takeaways.

We often present Ansible from a CICS perspective, but we also show what you can do with Ansible in general. We’ve added lots of new things to the CICS TS collection, so this time around we couldn’t cover both topics in one presentation. We ended up doing two — one focused on CICS TS, and an ‘Ansible 101’ session to help people get started. The introductory session was very well-attended — we even ran out of chairs.
This session highlighted how Ansible’s architecture differs from traditional automation systems, especially z/OS environments, making it essential to understand the conceptual model of its architecture. The control node — an ephemeral orchestrator that can be any system capable of running Ansible — initiates automation on the managed node (z/OS) via SSH and terminates after completion. This transient, non-persistent nature of the control node is a paradigm shift, offering flexibility and scalability but requiring a mental adjustment for those used to traditional, persistent automation systems.

“Ansible is a great technology to help us start adopting configuration as code patterns, which could include emulated z/OS environments as well.”

The IBM z/OS CICS collection is a prominent part of the Red Hat Ansible Certified Content for IBM Z offering. What are some of its popular use cases?

If you’re doing repetitive tasks in CICS Explorer, our modules — in conjunction with the Ansible platform — essentially form a nice scripting environment that you can use to automate those tasks. Whether it’s grabbing data from your system to compose a report, defining new transactions, or changing your system topology to add a new routing or application region, you can write an Ansible playbook that is quite powerful.

Do you see further investment in this collection?

Typically, CICS provisioning involves running JCL jobs and following a traditional configuration process. We now have a collection of Ansible modules that help you provision CICS regions from scratch. If you have ZOAU up and running, you can use a new sample playbook with very little modification to provision a CICS region, and you only need to observe prerequisites similar to those for the z/OS Core collection. Ansible is a great technology to help us start adopting configuration as code patterns, which could include emulated z/OS environments as well.

Does the z/OS CICS Ansible collection integrate with other IBM and Red Hat products?

IBM Cloud Broker helps you manage z/OS resources via the OpenShift API. This means that you can define a way of creating a CICS region, make a form for users to request a new CICS region, and then use the Openshift API to automatically enact that request. Because Ansible playbooks are used both to implement that automation and to provision a CICS region, it’s very easy to translate the whole solution into an operator collection. 
Similarly, if you have an Ansible playbook built to perform system provisioning, it’s easy to run that playbook in the Red Hat Ansible Automation Platform. I’ve heard of clients who want to develop an Ansible playbook so that they can respond automatically to a ticketing system. For example, when a ticket is submitted, an Ansible collection on the Ansible Automation Platform can be triggered to automatically build the requested system, without human intervention.

How do you see clients using Ansible CICS TS workflows in the future?

Actions like validating your environment — making sure it’s up and ready to accept work or looking for messages in the job log — can take a lot of manual steps. The CICS TS modules and Ansible tools are available to make automating those actions more accessible. If you’re interested in our Ansible collections, feel free to raise feature requests against us — we’re really looking to improve! However, you shouldn’t feel limited by what’s there today because you can always use Ansible to call an existing MVS program yourself without having to wait for us to do that.

What excites you about the future?

I’m currently working on CICS TS modernization and we are kicking off some exciting initiatives. Overall, we’re looking at ways to make working with the CICS platform consistent with modern developers’ expectations in terms of tooling and workflows so that they can develop projects and deliver business value as fast as possible.

This article is part of the Ansible for IBM Z User Spotlight. Read our other installments:

👉 Ansible for IBM Z: User Spotlight Series — Bill Pereira
👉Ansible for IBM Z: User Spotlight Series — Ipek Dedekoy
👉Ansible for IBM Z: User Spotlight Series — Mike Fontanetta
👉Ansible for IBM Z: User Spotlight Series — Jacob Emery

Stay up to date with the Ansible User Spotlight Series and Ansible for IBM Z community

Join the IBM Z & LinuxOne community topic group for Ansible for IBM Z. If you want to join our Ansible for IBM Z Community Guild monthly calls, where the IBM Z team and Ansible customers share roadmaps on content, use-cases, and collaborate on Ansible adoption, fill out this interest form.

Here are some additional resources if you are interested in getting started automating with Ansible for z/OS:

The Ansible for IBM Z User Spotlight Series Team

The Ansible for IBM Z User Spotlight Series Team

1 comment
21 views

Permalink

https://community.ibm.com/community/user/blogs/andreina-dyer/2024/12/11/ansible-for-ibm-z-user-spotlight-series-stewart-fr

Comments

Sahir Maharaj
Wed December 18, 2024 12:22 PM

Stewart’s journey with Ansible and CICS TS is nothing short of impressive. His focus on improving the developer experience through modernization shows how much thought goes into making legacy systems not only functional but future-ready.