Episode 29: The Hybrid Cloud Forecast Series – Outlook: DevSecOps

Speaker 1: You are listening to the Hybrid Cloud podcast, where the forecast here is always compelling as we discuss real- life challenges, successes, and stories from the journey to hybrid cloud with your host, Andre Tost.

Andre Tost: All right, welcome, everyone, in this episode of the Hybrid Cloud podcast. Today, I am happy to welcome an old friend of mine, Rosalyn Ratcliffe. Rosalyn is an IBM fellow, and she leads the topic of DevSecOps as part of the IBM CIO office, and obviously we'll talk about that some more. So thanks a lot for coming today, Rosalyn.

Rosalind Ratcliffe: I'm happy to be here. It's always fun to talk to you.

Andre Tost: As always, we'll start out by doing introduction, so if you could maybe give us an overview into your professional history, as in, what are the kinds of things you've done within IBM or maybe outside of IBM, and what is your job today?

Rosalind Ratcliffe: I am a long- time IBMer, I guess, or a short- time, depending on how you put it. I've only been here 35 years. In my 35 years in IBM, I've held various opportunities. It's been an opportunity, a challenge to do as much different jobs as I could within one company. So I started with ISPF development, working on our mainframe, doing assembler programming. I started there in the very beginning, but I've spent time in Tivoli services when I was deploying systems management software. I spent time with user interface design, helping design a standard for users back before we had the standards we had today. It was in the early days of OS/ 2 and the early days of Windows, so we wanted some consistency. UNIX systems were all sorts of different kinds of user interfaces, so we came up with the common user access and then ended up working with the IEEE to standardize UI. Things like control C, control V, control X that we all know today is thanks to that standards work. So I got to have some real fun early in my career. I worked in building systems' management tools and the SOA management strategy, which might be why I spent as much time with you in the field working with clients around SOA management and the transformation to services back then. I moved into application development tooling, with our Rational group and built application development tooling and that's when I started working on transforming z/ OS to be the modern environment. It really should be making sure that people could realize that z/ OS really is a modern platform, that you can do DevOps with z/OS, that you really can do the same kind of development for that environment that all the modern languages work on that platform, and really trying to change the perception of z/OS in the world. That's how I got to IBM Fellow, making z/ OS DevOpsable in my current role, because I had managed to really move the needle from the standpoint of the perception of Z. I came in to really build a showcase for hybrid cloud in the CIO. So we really want to demonstrate for the world what hybrid cloud really means, how it really can work, and how we can, as IBM, be a really good showcase for that.

Andre Tost: Okay, that's a fantastic lead- in. There was a couple of things there I want to poke on a bit more, maybe later, but it was a great lead into my next question, which is, " So what is the hybrid cloud to you? What's your elevator pitch about the hybrid cloud?"

Rosalind Ratcliffe: When I think about hybrid cloud, it really is, we're going to be running on- prem and in cloud data centers, we're going to be running on multiple hardware system types, and we really want to take advantage of fit- for- purpose running workloads. So in our hybrid cloud, we have z/ OS, we have z/ VM, we have OpenShift running across XZP so that we can provide the set of capabilities that our applications need. We have our on- prem data centers, and we're connected into IBM cloud, and we run SaaS in other cloud environments. So it really is this large environment allowing us to run our applications where it makes the most sense for business value.

Andre Tost: Okay. I like that definition. By the way, I think pretty soon we're going to add to that when you said XP and Z. We're going to add quantum to that equation as well, when there's just been some announcements in that space and obviously some rapid evolutions there. So I think this whole notion of quantum computing is based on this idea of a hybrid cloud by having a fit- for- purpose environments to run your workloads on. Before we poke a bit more at the job that you have today, let's take a step back here. It sounds a bit like you've been in and out of mainframe land across your career. That seems uncommon. I don't think there's many people that have worked within the mainframe space and outside of it at the same time. So how did that happen?

Rosalind Ratcliffe: I think combination of being lucky or wanting new changes or opportunities, or IBM is a large enough company that you could do just about anything, and so I think it's a combination of those things. When I started in Z with ISPF, I was actually working on standardization of the user interface for the Z environment too, so standardizing for Z and I and then the distributed world as well. So it brought me into some of the distributed world when we did systems management work. Z is there. It has to be there, but we've also got all these other things that need to be part of. I think, really, the thing that makes all of the work that I've done common is, I've always worked with large enterprises. So the largest banks, insurance companies, retailers, et cetera, the largest companies, airlines, take your choice. Those companies are large enterprises. They run all sorts of systems, and so you need to understand all of the systems in order to work with them. So I also understand and appreciate the value of Z and therefore didn't want to get too far away from it.

Andre Tost: Okay. How does that look when you talk to these enterprises, and specifically, maybe not so much the management part of it, but the application development part of it? And that'll get us into DevOps, of course, too. Do you find that these enterprises have application developers that also go across these platforms, or do they usually have siloed organizations? There's the mainframe guys, and there's the so- called distributed guys.

Rosalind Ratcliffe: Unfortunately, we are still mostly mainframe guys versus distributed guys. I really hate it. I don't see why we do it, but most organizations still have that split because they think they're so different because mainframe works that way and distributed does these things in these fancy new ways. That's because of historic reasons. Historically, mainframe development work a specific way because it was a shared system and all sorts of reasons. It doesn't have to be that way. The development process can be exactly the same whether or not I'm doing COBOL, PL/I, or Java. So it is important to bring those teams together, but many enterprises still have them remarkably separated, and it's a perception of the skills issue that causes this problem. Even in the CIO, we have mainframe teams and distributed teams in many cases, but we have some that have come together and said, " Okay, I've got a distributed front end, a mainframe back end. How about I work together better?" And so there are places that do it better in the sense of coming together, but many large enterprises still have that brick wall separation.

Andre Tost: But isn't it true that most of the application development for z/OS, for example, would be in the languages you mentioned, COBOL or PL/I? And I would assume there's just not that many people who can program in those languages. I don't know COBOL. I couldn't even write a hello world in COBOL. Maybe I should, but I guess I'm not a rare example.

Rosalind Ratcliffe: You're not a rare example, but as I like to tell software developers, they can't write COBOL. I've actually said that to a few, and they come back the next day and say it's just English. The point really is, if you're a software developer, you can write it any language, and COBOL is probably the easiest language in the planet to understand because it really is, especially if you're English- speaking. It is just English. Move something to something. Add something. It is literally English. So it really is completely understandable, and it was written as a business language, but the other half of this sentence is when I said Java, I said it, and you didn't even think about it. You translated Java distributed. I actually meant Java Z because Java's been on Z for as long as I can remember, almost. It's been there for a very long time, and it's very efficient running on Z. So there's no reason you can't use Java on Z. Yes, a lot of the traditional applications are written in COBOL or PL/I, and that's, for lots of reasons, COBOL. Because it was a business language, people didn't have to be software developers to write applications, and they could write business rules more effectively in COBOL. So we ended up with lots of COBOL, but it also does math slightly differently. It actually understands math very well when it comes to decimal- point math. So it's really handy that your bank account balance is actually always correct to the cent, something we all care about.

Andre Tost: So let me get back to something you said, Java can run on Z, and I'm going to show a bit of my ignorance here in this field. I always thought when it comes to more, quote, " modern applications" that are written, for example, in Java, that use modern application servers or messaging middleware of any sort, if I run that on the mainframe, that would get me into zLinux as opposed to z/ OS. So how do you position that?

Rosalind Ratcliffe: Now z/ OS has been able to run Java. In fact, it's had the UNIX system services side of the z/ OS world for a very long time. That's where the TCP/ IP stack runs. We've had UNIX system services in the environment. I can SSH in, I can use a standard terminal that you would be familiar with on any other system. It allows you to work with the system in a way that you would be much more familiar with for any other Linux or UNIX system. There are some differences. UNIX system services is actually a POSIX- compliant environment, and most UNIXs are not. So there are some differences in that environment, but because it's there and it's an integral part of z/ OS, you can run Java, you can run WebSphere Liberty, and we ran Apache apps on the system. You've got MQ. Most of the things that you would be familiar with, or many of the things that you'd be familiar with, also run on z/ OS. Now, it doesn't mean you have to run it there. You could run it on Linux on Z if you want it in a container. You could run it in a container in zCX running inside z/ OS, which is another way to run Linux on Z inside a z/ OS environment. But you can just run it native as part of z/ OS, and then it works with the same workload manager. Your applications are tightly integrated or could be tightly integrated if you needed to, and it can make it easier to have the application perform better without network traffic. Now, you can run it on Linux on Z and you still reduce that network connectivity. But why have to spin up a Linux environment if you don't want to? You can put it in z/ OS. It's a choice.

Andre Tost: Okay. Now, getting to the DevOps part of the equation here, so to me, obviously, as always, it's people process technology when I want to do DevOps, and there's a certain discipline that I apply to how I not just develop but also maintain and manage my application portfolio. I guess based on everything you just said, you can make the case. It doesn't matter where the application ultimately ends up. You apply the same discipline and characteristics, and so forth. But is it true that the toolchain, so when it comes to the DevOps technology, that I think of that as toolchains that help me carry my software across its lifecycle, so to speak. Are the toolchains the same between these environments?

Rosalind Ratcliffe: Yeah, that is one of the things that took some work to make that true, but that has been true for the last number of years. We had Git ported to z/ OS, which was one of the fundamental pieces. Many people use Git as their source code manager, so that's fine. It works. Most of the pipelines can work with z/ OS. We have clients who are using, I'll do a strange one, Azure DevOps. So they're using an Azure DevOps pipeline, and they're building their traditional COBOL and PL/ I with the Azure DevOps pipeline. They need a modern IDE that understands COBOL or PL/I, but it connects into Git. They have modern build tools that build it on the platform. From a developer's perspective, I don't care. I'm just writing code, and the pipeline delivers it for me.

Andre Tost: So one thing I'm curious to hear your perspective on is that we seem to have gone, and this is now stepping away from this old mainframe versus non- mainframe in DevOps. We used to call it DevOps. Now we call it DevSecOps. So that's been a major evolution in this space, I suppose, to make security a first- class citizen within that world. How did that come about?

Rosalind Ratcliffe: I think part of the problem is that when people heard DevOps, they really thought it was DevOps, it was dev and ops, and they weren't realizing that DevOps is really just a short thing to say, " I really need to bring everything together." And as I joke, it's probably BizDevSecQAInfoOps, because you need everybody. You need to break down all of the silos. But the real reason I think Sec gets added as often as it does now is because of the security problem we all have, which is, too many people are trying to break into too many different things and software is everywhere. A lot of open- source software is being used, which is a good thing. But then there are vulnerabilities that get discovered and have to be remediated. So we all have to think that security is important, and putting it in people's spaces with DevSecOps helps remind them that we have to think about security from the very beginning. We really should be doing security by design across the board and think about it in every aspect of what we do. But the other reason it's being added is because when people think about DevOps, they think about pipelines, they think about tooling, and if you can add the security tooling to your pipeline, then you get better compliance. You have it in someone's face right away. You build your pipeline, you build your code, you get the security information at the very beginning, so you get that feedback right away. So that helps hopefully with a focus on making sure that we're building secure software.

Andre Tost: To me, DevSecOps is all about automation and separation of concern. It comes back to what you just said, I'm writing code without necessarily having to worry about what architecture it will land on. Security is similar, that I can add tools to my toolchain that will take some of that burden away from me and just automate it in the process so that there's less burden on the developer to address these concerns.

Rosalind Ratcliffe: That is a really important point. If we think about the last DevOps Enterprise Summit that happened in a lot of the industry discussions right now, there's a lot of conversation about this developer platform experience, the developer platform team, developer platform, however they want to call it. But it's all around this idea of putting these tools together in the toolchain and providing it to an organization to help simplify the security challenges, help simplify the process so every single development team doesn't have to do the work it's done for them and the large enterprise, and they can take advantage of it and they can focus on building business value instead of focus on the tooling itself.

Andre Tost: After having worked with many of the largest enterprises, what do you think is the degree of maturity that we've reached as an industry in this respect? Are we still at the beginning, or are we pretty well along the way?

Rosalind Ratcliffe: I think it depends on the organization, and I think some of the companies who acknowledge that they are software companies are generally farther along than the companies who say their business is not software. There are auto manufacturers who say their business is software. So I'm not saying it's IT companies versus non- IT companies. Those that acknowledge that their business core is software are farther along in acknowledging they have to make this change. Then there are plenty of people who don't see software as their core business. They still see it as this other stuff, and they don't seem to be quite as far along in recognizing this change and the maturity of Sec as part of it. It's still an afterthought, and afterthoughts are not a great idea when it comes to security.

Andre Tost: Now let me take this back to your current job. So I guess you've moved from being the IT provider to being the IT consumer or being the provider where your own company is your only customer, which I find interesting because it must feel strange that now you're not working with customers anymore, you're working with your own company, and that must be frustrating at times, I assume, because IBM is a very large enterprise. So tell us a bit more about how this goes. Did you basically change sides? Does it feel now what it would feel if you had moved over to one of those large enterprises?

Rosalind Ratcliffe: So, as we call it, we're client zero, and we really want to be client zero. So I do want to be, in a sense, a client, and we do act like a client, open PMRs, fix the problem. We really are a client of technology, but we're also the provider of technology to all of IBM, and I knew how large the CIO was. I logically knew they ran a lot of systems. But when you actually move in, you start thinking about the fact that, " Okay, we run payroll, we run supply chain, we run the sales plan." The significance of what the CIO runs. It's a very large organization. The IBM CIO organization is larger than many IT companies. It's a really large organization because we run so much. IBM is unusual. We're not like some of the IT companies that are software- only. We're software and hardware, multiple kinds of hardware and services. We've got a lot of businesses that have to be run. So it is a significant change. It is interesting to be a client and say, " No, I don't have to build that software. I have to use software, and it has to bring value to the business. So I don't want to do things that don't bring value to the business." We're building a developer experience team because there's no good reason for us to have every development team building their own pipeline. We're building one. So the CIO can take advantage of that. There are lots of things that, yes, it's fun to be on the client side, and it's especially fun when you get to be client zero. So it's really close to say, " No, I need you to do something slightly different, please."

Andre Tost: Does that also mean that we have, and maybe I should know this, but I don't, do we have a large internal development organization that is creating software for internal use only?

Rosalind Ratcliffe: We have approximately 6, 000 developers within the CIO for building, maintaining, and running the applications that support all of IBM.

Andre Tost: I assume, by the way, that that includes mainframes, right?

Rosalind Ratcliffe: Yeah. We have only 615 approximately mainframe applications that do small things like data warehousing, of large client information, of payroll, a lot of very important things. We want to use Z for what it's intended for. It is our secure, reliable system that will always be on. That's what we want to use it for. We're focusing on providing the capabilities that it's very good at a large data server, large transaction processing, those kinds of things we run on Z because it makes sense.

Andre Tost: I would assume that obviously DevSecOps helps with that, that we're also, at least in part, going through this journey to cloud that the whole industry is going through by offloading applications where it makes sense into public clouds, for example. Is that true?

Rosalind Ratcliffe: So reality is, Z was the first cloud. It's the best cloud. Okay, you can see my Z bias is coming through remarkably well, but Z was the first cloud, and it is remarkably cloud- like in every way other than usually self- service. What we're trying to do in the CIO office is really change that mindset and that way of working to say, you really can get Z functions. You can provide them. You can have them. It isn't this challenge of go getting a ticket to go get somebody to do something for you. We really want to make that simpler and easier so that Z is the target for large data that I need highly secure, highly available. We're not trying to move off Z. We're moving things back onto Z, in some cases, because it makes more sense because it's large- scale data. I need to do large- scale processing because we now have the Telum processor with AI built in. I can be more efficient and more effective and I've got the Z hardware. Yes, I have to buy Z hardware just like everybody else. I've got a set of systems. I don't have the latest and greatest because our clients get them first. This is the one place where being client zero is maybe not an advantage right now. The Z16s are going to all the clients. I'm hoping, or our plan is that we will get Z next early. So we'll be able to do things on the early machine, but there's no business value in rewriting an application that works well and is running on a z/ OS environment. If the business process is totally changing, then yes, it makes sense. I need to look at where that thing should run. We also do use a number of SaaS providers. We do run a very large SAP environment, actually inside IBM. Our SAP actually, today, runs on Z as well. So we're trying to do the right thing for the application. There are some things that make a lot of sense that are in public cloud because I need to spend up, I need to do a set of things. It just makes sense. I'm using the service that's available in the cloud. Absolutely. So we're not not using cloud. We're using the whole hybrid cloud, z/ OS IBM public cloud services, where they are to make sure we're optimizing our applications and not wasting time building things that exist.

Andre Tost: How much do you still get to talk to external customers about all this? Because, as you said, we're client zero, we're probably our own best customer reference as an example. So you spend a lot of time with telling other companies how we do these things within IBM?

Rosalind Ratcliffe: We are doing more of that now. I still spend some amount of time with external clients to tell the story. I'm happy to tell the story because I can talk about how we are doing it. It's not the only way. In some cases, we've chosen Tekton as our pipeline because, for many reasons, it's what we're ending up to use. Everybody's not going to use Tekton, but we can tell the stories of how we got there, what we did, why are we choosing this. We can tell the stories of what we're running on the system. In particular, we really are transforming z/ OS to be Infrastructure as Code- based. So we can really simplify management processes. We can bring on younger people who can do automation and Python, rather than necessarily having to make people learn JCL and ISPF. There's no reason to do that. You can automate with Python. So we really do spend some time talking externally about it, presenting about it to get more people to see that we really can show how all of this capability can work together. As we get farther along, I've only been in the CIO about a year now. As we get farther along, we'll have even more stories and more showcases. We're running a set of cloud packs today in our environment and getting value out of them. We'll continue to talk about the value we get from the products and capabilities that we run internally.

Andre Tost: Unfortunately, we're slowly running out of time here, but I don't want to let you go before asking if you could give us an example of something really cool that you're involved in right now, something that gets you excited to get to work in the morning.

Rosalind Ratcliffe: So, as I mentioned a minute ago, Infrastructure as Code for z/ OS. One of the things that I wanted to do working with clients was really get them to understand that we could consider a z/ OS pipeline, and really, like we have application pipelines, like you have pipelines that build applications and put them in containers, I can do z/ OS the same way. I can have a fully automated z/ OS build and a z/ OS environment, and we are building that today. We're going to make it work, and we're going to run a very highly efficient, very large z/ OS environment and have a zero- trust environment with no system programmers mucking in the system. It's all going to be done through automation. This is a huge change, and when we accomplish it, we'll be talking about it to others so they can get the same value out of the system. So it's absolutely exciting. I've been able to bring in new people into the org to help build this, and it's what keeps me going every day to think I'm going to be able to actually build this and show the world that it's possible and then make the capabilities available for everybody else.

Andre Tost: Very cool. In fact, we were talking about this the other day. That I always ask this question at the end of each podcast episode, where we're thinking that's when we learn about things that then make me immediately want to dive a little deeper in. But then, unfortunately, we're out of time. So maybe I should start with that question in the future. But it also leaves us to maybe we'll get back together in the future episode and zoom in on that a little bit and hear more about that. So with that, we're going to wrap it up for today. Thanks so much for coming, Rosalyn. That was some great insight you shared there.

Rosalind Ratcliffe: Happy to be here. It's always fun to talk about what we're doing.

Andre Tost: That's it for today's episode. Thank you all for listening, and I hope to see you all soon. Bye-bye.