Wazi Deploy – Rosalind Radcliffe, IBM
Rosalind Radcliffe, IBM Fellow and CTO DevSecOps, has been working in the CIO office to transform our DevSecOps culture and process across the enterprise. As part of that mission her team has become customer number one in implementing new tools and processes to increase agility and respond to the business requirements. Recently they have been using a new open source-based scripted application deployment option for customers who are migrating to modern software configuration management tools like Git™. Wazi Deploy, as part of IBM Developer for z/OS EE, deploys packages of z/OS application artifacts from an artifact repository using scripts based on Ansible or Python. Rosalind shares her experiences in being a business stakeholder and the value they are driving for the enterprise.
Transcript
This is Techstrong tv. Hey everyone. Welcome back to techstrong tv.
You know, after a long absence from our show, I'm delighted to welcome back one of my good friends. Her, uh, she really needs no introduction to our audience in DevOps. com.
I want to introduce you, though, in case you don't know her, to Rosalyn Radcliffe. Rosalyn is an IBM fellow, formerly dis Well, I, when you're an IBM fellow, are you still distinguished engineer? It's The next step up.
It's, you know, oh, ok. I get to move up. I get to be a, you moved up.
Mm-hmm. She's also newly installed as CIO of the DevSecOps, CTO O So within the Ct o office at I B m, she is CIO for DevSecOps. Is that fair?
So within the CIO organization, I'm the DevSecOps. DevSecOps. Cto.
Cto. I had that little bass backwards there. I apologize.
And, and a bunch of other stuff too, but she'll, she'll tell us about it. Rosalyn, it's so good to have you on. How have you been?
Uh, I'm happy to be here and I've been having a blast. It's a, uh, it's a new thank you. Always opportunity and, uh, a lot of fun.
Good. I'm glad to hear it. Glad to hear it.
Um, so look, we can spend time catching up, but we'll do that off camera cuz we don't wanna bore these people with you and I chit chatting. But I, I wanted to talk to you today a little bit about kind of, you know, not drinking your own beer, but your own champagne, um, by how the I B M CIO's office is standardizing on, you know, C I C D automation, which really, when you get down to it, is at the heart of what DevOps is, right? It always has been.
And, and I think always will be. Yeah. The, the pipeline is a key central part of the automation.
Uh, and in, in my new job, I really get to help our internal organization transform to be a DevSecOps, DevOps, whatever term you wanna use culture and bringing in that automation and that consistency. Because without the automation, it's hard to move faster with higher quality and, well, it's impossible is actually a better way to put it. So, standardized pipelines and making sure we have a standardized pipeline.
We have a, a dev, um, a DevX team that provides the pipeline to the organization. And so we have and are working toward everybody adopting one pipeline, one way of working. No.
Yes, we have all sorts of different environments. We have containerized world, we have power, we have, I, we have Z but we have one pipeline. And this standardization of using a single way of doing work from a pipeline automation standpoint makes it a lot easier for us so that we don't have to, you know, implement security standards or scanning or, or, or multiple places.
We do it once and, you know, we're using our own tooling to help make sure we're accomplishing the goal, but making sure we're bringing this automation to everybody. Got it. com talking with the IBM folks, and they were one of the first organizations, it was you, but it was others within ibm.
It was the rational group, remember? And, and some of the great people there, Eric and some of the others about IBM eating it at, at that point, it wasn't champagne, it was still dog food, but, but eating own dog food, Drinking our own champagne. Thank you.
Yep. But, you know, in, in actually adopting DevOps internally for IBM and what, what a, what a, a change it was a refreshing change and, and benefits. And here we are eight years later with this and it's turned from dog food to champagne as you men as we said.
But, but we've also kind of honed it into this whole pipeline C I C D automation thing. And you know, it's something I also talk to a lot of people about, right? We, this whole GI ops thing, for instance, and, and GI ops seems very closely aligned with cloud native, right?
Most people who are doing GI ops seem to be using containers, Kubernetes, that, that kind of infrastructure that stack, um, is that different than what you guys are doing internally there? Or it's similar or you're laughing? Yeah, I'm laughing because I, I I love the thought process that says get ups is more cloud native.
Uh, realistically what we're doing is we're bringing the same practices, the same principles across all platforms. So one of the things I'm focused on right now is modernizing our Z world. Mm-hmm.
What do you expect? Mm-hmm. Uh, so our pipeline, which happens to be tacton, it's OpenShift pipelines, uh, provides our pipeline for our container based world, absolutely.
But also for our Z os world. And we are building an entirely new way of doing Z based on infrastructure's, code, GI ops, et cetera. All of the principles that we apply in cloud native development in our Z os world, including the infrastructure layer.
So our new Z os world is a standards based world pipelines to build out the environment, automation to build out the middleware, all of this so that we have one way of working and to help simplify in many ways the management of our Z world. We have a, um, very large, most of my job is actually spent helping modernize the fact we have way too many LPARs and they're all very different because they've come together over time, over the years. You can imagine IBM's running Z at, you know mm-hmm.
Might have been running Z since the beginning of Z maybe. Yeah, probably they are. Uh, or since before the beginning of Z, but Yes.
Yeah, Before we Z systems. Yeah. We have systems that have been around for 50, 60 years.
So you can imagine they're all different and they're all built in their own way. And so we are doing this standardization process, going from various different systems into a standards based pipeline, based this same concepts of get ops in our Z world. And it, it makes a huge difference.
It, it is improving the way we're able to work. Absolutely. You know, I'm listening to you, I didn't laugh, but I'm thinking to myself.
Yeah. I was, maybe it was two months ago, I was out in Amsterdam for Aon Cloud Native Con and one of the interesting things I, I noticed, or I observed there at roseon was that you don't necessarily need cloud for cloud native. And so you mentioned tecton, right?
Tech Tecton is actually managed, I believe, by the CD foundation, which is Lennox Foundation, sister of Foundation two to, uh, cloud native computing foundation and, you know, is very much part of this cloud native stack, if you will. And they're, they're, you know, with wa I don't know if you're into this wazo and, and web assembly and, and all of this, and this is throwback stuff for people who are in mainframe, right? Um, but it, what's old is new, right?
Miniskirts, but, um, you know, this is cloud native too. It's, it, it may be cloud native, maybe without the cloud, if you will, or without a public cloud or what have you. But it's this stack of software tools that we're using now.
It it, it really is important to think about hybrid cloud, not just, you know, thinking of cloud, meaning public cloud, hybrid cloud is the way we have to think. Yep. And there is Z Z and Z OS has to be part of the hybrid cloud.
Yep. Our work is focused on a set of efforts around intelligent workload placement. And so our pipeline and our platform are, are providing that abstraction so our developers don't have to worry about it.
And, and honestly, the way we've implemented this, we actually just put configuration in our get repos. We don't actually put tecton whatever in our repos, we put configuration. And so if tomorrow something else comes out, uh, because one of the problems with pipeline, it is so central, everyone needs to use it and technology changes.
And so a lot of companies in this DevOps transformation started on one and then had to move to another. It's a whole bunch of work for development teams by abstracting it out and just putting configuration in the environment in their repo itself. Then when, or if we move from OpenShift pipelines from Red Hat with Tecton, or we move to something else, something in the future because something else comes out, the development teams don't have to change.
We've done it through an abstraction layer. And that is really important to help developers focus on development work and let us make sure that the infrastructure can handle, or the developer experience team can handle this pipeline effort working with the platform team. And it's doesn't matter.
I could be going to public cloud, I could be going to private cloud, including Z os. I love it. I agree with you, hun.
I can't agree more. So it's Rosalyn, I could talk to you all day, but we, we, I gotta kind of bring this home a little bit, but let's talk a little bit. So how far along is this, let's say with IB within I B M itself doing this?
So we, we have a, a lot of work going on right now. And what we're doing is moving our, we already have our pipelines for containers, et cetera, wind shift environment. We're moving in the Z os um, world.
And so we have this new Z o s pipeline exactly the same as everything else. It's based on using IBM m dependency based build with Git as the source manager. And we're using something new Wai Deploy to allow us to do de deployment itself and integrating that into the infrastructure automation that we have.
And so the idea of, of Wai deploy, similar to what we had with dependency based build is, it really is a, a script based kind of, you know, D B B was created on a model of Gradle with Wai Deploy we're much more like other automation, Python based automation for infrastructure deploy. And you could use Ansible with it, but Python based is how we are doing it. And it allows you to define in a yammel configuration, this is what you want and the tool helps you deploy it into the middleware and then call our infrastructure level automation for creation of things if I need a new subsystem for something.
But this allows us to have the, the pipeline abstracted from the development team, but also to provide it as code so it sits in our get repository from an infrastructure standpoint. So as we need to make updates or modifications, it's all done based on the pipeline. And so there's no, you know, uh, there's no update in the environment without it coming through the GET environment.
And that's, that helps us better manage, better understand, better maintain, and makes it easier for us to get standard processes going on in our Z environment. It's not everybody has to figure out the way to do it, have one way of doing it, You know, to bring a full circle, it brings me back to let's developer, let, let's let developers develop, right? We were talking about it before we came on camera.
That's what developers want to do, right? And now, look, I could work in the, in one tool, a standardized tool allows me to work in z allows me to work in hybrid cloud, allows me to do the latest, greatest things as well as support my legacy kind of implementations. What could be bad, right?
I mean, what's bad about that? It's hard to, hard to say something. You know, I, I don't want that, that doesn't sound good to me.
Um, so what a great thing. Where can people say, Hey, I wanna, I want to get a piece of this, or I wanna find out more. Where do they go?
Rosalyn? There's lots of places to go learn and understand about what's going on in the environment. D B b, IBM's, um, community DevOps community can help you go talk to people who have this experience.
B m dependency based build has been out there a long time, but Wai deploy as brand new capabilities. So you can go out to the WIS website, you can see all about the latest announcement and understand this new capability. It's actually been developed in combination with the CIO and with some clients.
And so, you know, we're really early users. We are using the Python based capability using all Python automation. We have a client working on it with Ansible to be able to utilize its automation.
So you have choices and you can go learn about the capabilities that it has. But since it's a scripted based environment, if it doesn't have everything that you need, because you have some really special, cuz we know z we know our Z clients and even in the CIO we have something extra or something different. Not standard, not normal middleware, but something we've built, we can add that into the environment and, and so we can have one way of deploying across our environment and just extend the tooling.
So it, it works really well from that standpoint. And, you know, go play with Wai as a service in I b M Cloud and, and use the environment and try it out. We, I just had a, a bunch of people commenting and a team pinging me directly about the fact they're just using Wai as a service to get all their early work done, build out changes, and then deploy 'em in their environment.
I love it. Actually, I loved having you on the show. Again, more than even all of that there Olin, we, um, you gotta promise me you gotta come back more often.
Let's continue talking about with this new role. I'm assuming you'll be able to talk to us some more. What a breath of, of, of sunshine.
So thank you for coming on. Thank you for sharing with us. Um, we'll speak to you soon.
Thank you. Always happy to talk to you. Always happy to have Rosalyn here.
All right, we're gonna take a break here on Text Strung tv. We'll be back in just a minute.