Rosalind Radcliffe

I'm Rosalind Radcliffe, IBM distinguished engineer responsible for DevOps for enterprise systems. This is a wonderful event, and I hope you take the opportunity to attend all of the sessions and listen to all of the wonderful discussions that happen. I have to say, it's my favorite event of the year. Well, I don't know, London-- Okay, these are my two favorite events of the year. Okay, there's one more, the DevOps Forum. But okay, they're all fun. They're a great opportunity to meet with, talk to, and learn from others who are really in the industry doing work. And here I get to talk not only about my fun topic of DevOps, but DevOps in the mainframe and infrastructure as code. And when we think about DevOps and transformation, infrastructure as code is just another part of the process, a very important part of the process if we're going to make z/OS just another node as part of the system, if we want to take away those differences. For those of you who have not heard me speak, I should put a little caveat on that. My goal in life is to remove all of the differences from z/OS that don't matter. So yes, it has the qualities of service. Yes, it has the reliability, the security, all of those abilities that you need. But the fact that it's different, that I have a different way of doing development or a different way of doing operations, there's no need for that. So removing all those differences. So I've been doing a lot of work, and we've solved the problem. You can use a modern pipeline. You can use open-source tools. We'll talk about numbers of that in this discussion. But the place where we haven't yet solved it is infrastructure as code. And so I want to talk about that today and help you understand where we are and what you can do today. But let's start at what infrastructure as code is. Infrastructure as code matters a lot and has mattered a lot in the distributed world where they've moved from pets to cattle. They've moved from creating these machines that once you named them, they acted an awful lot like the name you gave it. If it was sleepy, the machine was a little sleepy. If it was grumpy, yes, the machine was grumpy. And that's been going on for a long time. But we moved away from that and provided code in order to create the instances that you needed. We have large-scale environments creating thousands of machines because of infrastructure as code. In the mainframe space, we haven't had the same problem. You usually don't have thousands of z/OS instances, maybe hundreds, maybe tens, but not thousands. So it's a different discussion. But we have been doing infrastructure as code in some ways all along. We have a system image. We have the SYSRES. It's been built by our system programmers. That's the image that is used for every single instance that you have. So we've started down this process. We don't have to worry about that variability that exists in the distributed systems of the base image because it all comes from the SYSRES. But then we go a step beyond that, and we look at the middleware that we're deploying in that environment, and it's done by JCL. Once again, maybe infrastructure as code, but where's that JCL stored? It's in my private library. It's not in an SCM. And if I do it, I do it my way. And if Jen does it, she does it her way. Well, that doesn't work. That's not infrastructure as code. We need to move out of this environment where it's custom, where it's done differently, and really move to the same concepts so that we can get to this pipeline. Now as I've said, code, we can use the same SCM no matter what kind of source code we're working on. Build processes, we can use modern build processes to do everything we need to do and go around this circle, but there's this little box called provision. In the z/OS world, do we provision instances? Yeah, I see the head shaking no. No, we don't provision an instance. We just deploy into an environment. The environment's already sitting there. I have a static number of environments that are sitting there that I'm stuck using. But there's no reason for that. There's nothing about z/OS that says I can't provision an environment and deploy the application into it and run tests. There's nothing about z/OS that says I can't provide those isolated test environments. There's nothing about the operating system or the platform that's limiting you. What's limiting you is history. It's culture. It's the way we've always done it. But that does not mean that for today, that is the right thing to do. So I want to talk about this idea of infrastructure as code and what you can do today to make this work so that I can do this provision and deploy. One of the important parts about this is making it look just like everything else. So if I'm going to work in an environment and I'm going to give my developers the flexibility, and I'm going to allow them to work in a consistent manner, whether or not they're doing distributed development or z/OS development, I want my pipeline, I want the way of working, I want the way of setting up to be identical. And if I look at this example, which could fit a Jenkins example, I have a CI/CD server. It has an agent running on the machines. I can make z/OS look exactly the same today, and I can store my artifacts in an artifact repository. This artifact repository is the same artifact repository that I store all of my distributed artifacts in, not someplace separate. I don't have to keep my Z artifacts in PDSes or PDSEs anymore. We fixed that in Z. You can take them and make a Z archive just like you make a JAR or a WAR. There's nothing about the system that limits you from doing that. So you now can have that artifact repository, and now I can deploy my application no matter what system it runs on. The other point I want to make is I don't actually care. Yes, I work for IBM. I don't care what your pipeline is. I care that it's a modern tool chain. I care that it's an infrastructure that allows you to give the flexibility, but I care what is your choice for the distributed world. What's your choice for the rest of the world? Where do you put your source? Where do you put your Java? Where do you put your .NET? Where do you do, how do you do those other things? That's how you should do your COBOL, your PL/I, your assembler. There should be no differences, and there's no need for any difference today. You'll notice the Azure DevOps pipeline up there, which might even be more remarkably unusual. We did some work just to prove that it would work, because why shouldn't it? It's a pipeline. It's got a Git repository. It's got the ability to kick off tasks. So I can do an Azure DevOps pipeline. The other thing you'll notice on here is Red Hat and Ansible. Ansible is commonly used for infrastructure as code in the distributed space, and if I'm using Ansible as my infrastructure as code capability in the distributed space, why shouldn't I be able to use it for z/OS? There's no reason I shouldn't. I can create a playbook. Runbook. Playbook. Got it right. I can create a playbook, I can use a set of capability, and I can create a set of resources on z/OS. There's nothing that's specifically different about the system that means I can't do that. The issue is: What do I need to create? What is in the system? It's middleware that I'm creating resources in. If it's a CICS environment, I need to know the parts of the CICS environment. I need to know the transactions definitions I need. I need the file definitions. I need those infrastructure definitions. But you have them today. They're defined today in your system. They're in someone's JCL. You can take those out, put them in the SCM, and now I can use them with Ansible or with any other automation tool to get me to infrastructure as code, just like I have in any other system. It's simply a matter of defining those resources so I can have them work together. The other thing that is important about this is how do I get those systems? How do I get that test system? How am I going to provision that system? And I have a number of different choices. In z/OS, I can create another LPAR on the system, and if your system programmers in the room and you're laughing really hard now about the fact you're going to create a new LPAR, I sort of agree. You're probably not creating a new LPAR on the z/OS system all the time. But how about under z/VM? So if you're running z/VM, you could be creating instances under z/VM. I could use an existing LPAR and create the resources I need for it. Or I could use z/DNT, or z Development and Test environments, running on Intel Linux to create the environment. Now, this picture might not be obvious what it is, but it's an OpenShift environment running a z/DNT in a Docker container. So I can put a z/OS LPAR in your Intel Cloud environment for dev test, running it with OpenShift. Does that make a difference? So now in that pipeline with that infrastructure as code, I can provision a z/OS LPAR into that environment as simply as I can provision any other instance in my container environment. I can create that z/OS instance, and that z/OS instance can be my golden image. It can be that SYSRES, including middleware, and then I can use tools like Ansible to create the specific CICS environment or the specific DB2 or MQ for the application to allow it to test in that environment. So I can do the same pipeline, the same kind of capabilities in the z/OS environment that I'm doing in other environments. Now, this is a little bit of new information. Our support for containerized z/DNT, announced relatively recently. But with that ability, I can run it in any containerized environment that I wish to run it in. And this is an example that we have running internally that allows us to provision z/DNT instances whenever we want to. And the only reason it's got my fun green screen up there is so that you can see that it's really z/OS, because everybody who thinks about z/OS says if there's not an ISPF screen, it's not z/OS. But there's also that other command prompt sitting there. That's a bash shell into my z/OS environment that allows me to interact with z/OS in exactly the same way that I interact with any other Linux or Unix environments. I don't have to use ISPF. There's nothing about Z that said you have to use ISPF. I can use that bash shell to do all the automation that I've been able to do for any other system. So the Ansible work that I'm doing, I can run it on that system. Or I could use Groovy scripts if Groovy is the language that I choose to use. I can choose whatever language I want, and I have access to the system. So I can work in a normal way. One of the things that our new developers have been teaching some of us old developers... I've been around a long time in IBM, 32 years. I started in ISPF development, so I know a little bit about it, and there's nothing wrong with ISPF, right? Okay. Sorry. If you're 20-somethings coming into the industry and looking at ISPF, you usually look at that and say, "Okay, can I run away? I want some other way of working." So we very simply provided our new developers a modern development environment and their friendly command prompt. Now, my new developer showed up and said, "Okay, this command prompt doesn't work right. I logged in. I can't do the things I'm used to." And I said, "Okay, what shell are you in? Why don't you run bash?" Switched to bash, and all of a sudden, it looks like any of the other systems he does his development work on. He has access to do all the standard things he wants to, and all of those scripts and all of that automation and all of the things that you're used to doing as a 20-something, I can do in exactly the same way on this system. The other thing that's important about this work is you see I've got a z/OS running in an OpenShift environment. So I'm taking a z/OS, a z/DNT, an Intel Linux version of z/OS, running it in an OpenShift environment. But I can also do things similar to that on Z itself. When we think about the Z platform itself, we have Linux on Z, that I can use OpenShift for Linux on Z in the environment. And so I have that full capability. The Z box is more than just z/OS. It has a z/OS side as well as all the Linux capability. So think about that, as well as we now have zCX, the Z container extensions that also allow you to run Linux inside a z/OS environment. We're getting more and more containerized in our ways of thinking in the Z world. The other thing I wanted to show is that I'm not just talking about this, but customers are doing this. So yes, it's new. It's relatively new. But we have customers who are using these concepts in order to get to infrastructure as code, as well as to automate the system. Now, keep in mind, they still have the traditional z/OS automation tools like System Automation or all of the other automation tools on the box that are managing the system. So this automation has to work with those automation tools, but this allowed an organization to significantly reduce their LPAR validation time to get their system up and running. Now, the thing that was fun about this particular task was this was two brand-new college kids. Two brand-new college kids at a large US insurance company that were hired on to do this task. They were given Groovy, and they were given a command prompt, and they were happy. And they started to learn z/OS from there. And in this time frame, they learned enough about z/OS. They learned how to do this. They learned all about the system, not in a way by giving them ISPF and forcing them to learn it the way I learned it, but by learning it the way that they were familiar with. They could experiment. They could learn. They could use tools they were used to, and they accomplished this automation in a matter of months. If you know z/OS well enough, you'll sort of understand this comment, but BCPII is relatively core z/OS function, and the kids, as we were saying, said, "Okay, now that I've done all this Groovy stuff for all the basic stuff, how do I get into BCPII?" And we went, "Okay, hold on. You're not IPLing z/OS right now, please. Just give us a minute. Let's figure out." The point was, in six months, they had learned Z by being able to access it and use it and work with it in the ways that they were used to, and they got a long way toward infrastructure as code for their organization. Another example, and this example I find rather fun because it actually relates to that comment that I made a minute ago about you wouldn't be IPLing a new z/OS LPAR. That is exactly what this does. What Jerry did with this capability was he had a task. What are the steps I need to go through in order to create a z/OS LPAR? I have to log on. I have to create configuration files. I have to do a set of things. And that takes a while, and that takes a lot of manual work, and it takes a lot of manual tasks. So instead, he had a code repository, and he create a set of configuration, and he has a Jenkins process with a Jenkins file, and he literally creates a z/OS image through a Jenkins build process using Groovy, and in the end, IPLs that new SYSRES. So in order to do a system update, in order to update the z/OS environment, in order to do a change to their system, in order to build a new LPAR for any reason, it's entirely automated. All of its configuration, all of it's stored in the SCM, and they can boot the system, and this system is now configured such that it can be part of all the standard automation that you have in place. So it isn't leaving out all the automation we have in place. It's working with the automation we have in place. It's working with the rest of the system so that it can be part of the environment. If it's a sysplex, it could be part of a sysplex. It can be part of the environment. So he's creating this automation to be able to IPL a new system. Now, yes, this is extreme, and people are probably not going to be IPLing z/OS systems. But the point of this, and the reason he did it, I believe, was to help demonstrate that there is nothing holding us back on z/OS, that we have choices, we have multiple options, that we really can do infrastructure as code as long as we're willing to accept that something good happened in the last 30 years that we need to learn from. Somebody laughed. Got it. So one of the things that I think is very important in this transition, I started in IBM 32 years ago, working on ISPF, and the processes that I used to do development 32 years ago, and the way I interacted with the system 32 years ago, is exactly the same as the way some of you are interacting with the system today. The development processes have not changed. In 1987, I had a phone in my house that was attached to the wall. In 2000, whatever year this is, 19, I actually still have a phone that's sort of attached to the wall in my house, but I have one of these. Yes, the phone that is attached to the wall still works. That is a true sentence. But there's no chance I'm only going to live with a phone attached to the wall. I'm going to use my cell phone. So enough's enough. Thirty years, the world has changed, and it's time that we accept that that change has happened and bring it to the z/OS environment. The Z machine is the most modern machine out there. With the z15 announced, it's the most modern machine out there. And there's nothing about z/OS or the system that keeps us from doing things in modern ways. We really need to transition to this modern practices. One of my roles in this work is to work with clients in their DevOps transformations and in their movement. And one of the things I say is, I still make that joke about 30 years ago and it being exactly the same because there are still some organizations that are there. But if you haven't started to transition, I can now safely say you are behind. Because the number of companies that have started this transition, the number of successful organizations that have moved to modern DevOps pipelines, has been significantly increasing over the last number of years. So if you aren't already moving, it's time to think about it. The other thing that's important about infrastructure as code is, what do you have today on your system? Do you know? Yeah. Your z/OS system has been built up over the last 30, 40 years. You have configuration options that were set 30 years ago that might not matter anymore. When I go in and work with companies and I look at their compiler options, I say, "It's time to clean up," and they say, "No, they're all still required." And I look at the compiler options and say, "Do you still need the options of your print listing on the rolled paper with the lines? How many lines? Yeah. You really need that print listing option still in your compiler?" No, you don't. We need to look at helping understand what's currently in the system, discover what's in the system. There are ways to discover the system to understand what's there, take it out of the system, use it as infrastructure as code, and then you can move forward as you create new systems. And for all of those of you who say, "No, my system sat there and has been running for the last 30 years," I will say, I'll bet you're not running on the same hardware you were running back then. I'll bet over the last 30 years you've changed your hardware. Which means you've actually worked on your z/OS images every time a new hardware and z/OS operating system came about. You looked at the migration process and you moved to the next system. So you've actually done work on that system in all of these years. Now is the time to look at that system and pull that out and put it in the SCM for infrastructure as code. Now you can more easily create systems. Now you can give everyone the flexibility of the new environments, allow them to take advantage of isolated testing, allow you to experiment and play with new functions and new features. There is another thing that's important when we think about z/OS. We have been working very hard to bring z/OS forward to help people work with the system. And another way we've done that is through the Zowe project. And it's an open project, and there have been a couple of sessions talking about it, and it really does provide a modern UI for z/OS. You have access, and many vendors are looking at this as a new way to provide a user experience for their products for you, as well as an option for you to use in your environment. One of the examples is the use of the APIs as part of your infrastructure as code. I need to provision something. I could use a z/OSMF workflow to create a CICS region and call it from my Ansible playbooks. So there are numbers of things that are options that allow you to improve the process. I could have developers using the CLI in order to do those tasks that right now, yeah, I watch as people do a whole bunch of FTPs of data to bring it down to run an Excel macro. Yeah. People do this all the time. They need mainframe data for their Excel macros. Well, using the Zowe CLI, I can significantly improve that process, make it easier to interact with the system as an experience. Just another option to allow you a new way of interacting with a z system. Now, for the last, I don't know how many DevOps Enterprise Summits, my chart has always said, "I need your help to get the message out." I think the message is now out. Now I need to know from you, what open source tools are we missing? What tools are you using in your environment that you need running on z/OS so we can help you? And what else do we need to do to z/OS to make it better for you and your environment so that you can take advantage of the platform and do what you need to do in the system? Hopefully, this has been helpful. I'll be here all week, and I'm happy to answer questions. Thank you for your time, and enjoy the rest of the conference. Thank you.