00:00:02

I'm Rosalynn 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 dev ops forum, but okay. They're all fun. Uh, they're 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 dev ops, but dev ops and the mainframe and infrastructure is code. And when we think about dev ops and transformation, infrastructure is code is just another part of the process. A very important part of the process.

00:00:59

If we're going to make Z O S 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 Zoes. 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.

00:01:51

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 about 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, I've moved from creating these, these machines that once you named them, they acted a lot 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's code in the mainframe space. We haven't had the same problem. You usually don't have thousands of dos instances.

00:02:57

Maybe hundreds may be 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 SIS Rez 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. Very ability that exists in the distributed systems of the base image, because it all comes from the Rez. 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 is code, but where's that JCL stored. It's in my private library. It's not in an SEM. And if I do it, I do it my way. And if Jen does it, she does it her way.

00:04:02

Well, that doesn't work. That's not infrastructure as code. We need to move out of this environment where it's custom or 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. I can go around the circle, but there's this little box called provision in the Zoes 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 cos that says I can't provision an environment and deploy the application into it and run tests. There's nothing about cos 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.

00:05:50

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 Zoes 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 CIC D server. It has an agent running on the machines I can make. Zoes 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 and PDs is or PDF CS 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.

00:07:22

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 PD-L1, 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, it's a pipeline. It's got to get repository. It's got the ability to kick off tasks so I can do an Azure dev ops pipeline. The other thing you'll notice on here is red hat in Ansible.

00:08:35

Ansible is commonly used for infrastructure's 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 Zoes? There's no reason I shouldn't. I can create a playbook run book, 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 cos 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 Kix environment, I need to know the parts of the Kix 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.

00:10:14

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 cos I can create another LPR on the system. And if your system programmers, if your system programmers in the room and you're laughing really hard now about the fact you're going to create a new El par, I sort of agree. You're probably not creating a new El par on the zoo system all the time, but how about under ZVM? So if you're running ZVM, you could be creating instances under ZVM. I could use an existing L par and create the resources I need for it. Or I could use the D and T or Z development and testing environments running on Intel Linux to create the environment. Now, this picture might not be obvious what it is, but it's an open shift environment running a Z, D and T in a Docker container. So I can put a Z O S L par in your Intel cloud environment for dev test running it with open shift.

00:11:42

Is that make a difference? So now in that pipeline with that infrastructure as code, I can provision a Z O S L par into that as simply as I can provision any other instance in my container environment, I can create that Zox instance and that Zost instance can be my golden image. It can be that SIS Rez, including middleware, and then I can use tools like Ansible to create the specific kicks environment or the specific DB two or MQ for the application to allow it to test in that environment. So I can do the same, a pipeline, the same kind of capabilities in the Zoes environment that I'm doing in other environments. Now, this, this is a little bit of new information, our support for containerized Z D and T announced relatively recently. But with that ability, I can run it in any containerized environment that I wish to run it in.

00:13:01

And this is an example that we have running internally that allows us to provision ZD and T instances whenever we want to. And the only reason it's got my, uh, fun green screen up there is so that you can see that it's really Z O S because everybody who thinks about dos says, if there's not an ISP F screen, it's not F um, but there's also that other command prompt sitting there, that's a bash shell into my cos environment that allows me to interact with dos in exactly the same way that I interact with any other Linux or Unix environments. I don't have to use. I SPF nothing about Z that said you have to use ISP AF 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.

00:14:19

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. And I in IBM, 32 years, I started in ISP F development. So I know a little bit about it, and there's nothing wrong with ISP F right. Okay. Sorry. If you're a 20 somethings coming into the industry and looking at ISP F you 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 locked 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 switch to bash?

00:15:22

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 an exactly the same way on the system. The other thing that's important about this work is you see, I've got a Z O S running in an open shift environment. So I'm taking a Z O S a Z D and T and Intel Linux version of dos running it in an open shift environment. But I can also do things similar to that on the itself. When we think about the Z platform itself, we have Linux on Z that I can use open shift for Linux on Z in the environment. And so I have that full capability. The Z box is more than just Z, Z O S. It has a Z O S side, as well as all the Linux capability. So think about that as well as we now have Z CX, the Z container extensions that also allow you to run Linux inside a Z O S environment. We're getting more and more containerized and our ways of thinking in the Z world.

00:16:49

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 Zoes automation tools like system automation, or all of the other automation tools on the, 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 LPR 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.

00:18:13

And they started to learn cos from there, and in this timeframe, they learned enough about cos they learned how to do this. They learned all about the system, not in a way by giving them my SPF 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, the, if you know, O well enough, you'll sort of understand this comment. Uh, but BCPI is relatively cores, EOS function. And the, uh, 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 BCPI? And we went, okay, hold on. You're not IP yelling. Zoes 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.

00:19:33

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 IP selling a new Z O S L par. That that is exactly what this does. What Jerry did with this capability was he, he had a task. How, what are the steps I need to go through in order to create a Z O S L par, 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 O S image through a Z Jenkins build process using groovy. And in the end, IPLS that new Cicero's.

00:20:51

So in order to do a system update in order to update the Z O S environment in order to do a change to their system, in order to build a new El par, 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 assist flex, it could be part of assist Plex. It can be part of the environment. So he's creating this automation to be able to IPL a new system.

00:21:50

Now, yes, this is extreme and people are probably not going to be IEP, healings, dos 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 O S that we have choices. We have multiple options that we really can do infrastructures 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 ISP AF 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.

00:22:59

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, 30 years. The world has changed. And it's time that we accept that that change has happened and bring it to the Z O S environment. The Z machine is the most modern machine out there with the Z 15 announced. It's the most modern machine out there. And there's nothing about Zoox or the system that keeps us from doing things in modern ways.

00:24:04

We really need to transition to this modern practices. One of one of my roles in this work is to work with clients in their dev ops transformations and in their movement. And one of the things I say is I still make that joke about 30 years ago, when 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.

00:24:56

The other thing that's important about infrastructure is code is what do you have today on your system? Do you know? Yeah. Your Zoox 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, you know, the roll of 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.

00:26:06

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 are running back then. I'll bet. Over the last 30 years, you've changed your hardware, which means you've actually worked on your Zoox images. Every time a new hardware and dos operating system came about. You looked at the migration process and you move 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's 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.

00:27:08

There is another thing that's important. When we think about Zoox, we have been working very hard to bring Z O S forward to help people work with the system. And another way we've done that is through the Zoe 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 O S. 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 API APIs, as part of your infrastructure is code. I need to provision something. I could use a Zio SMF workflow to create a Kix region and call it from my Ansible playbooks. So there are a 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 just 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, we using the Z Zoe 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 the Z system.

00:28:51

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 dos so we can help you? And what else do we need to do to Z O S 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. And.