Tim Johnson

Hi, I'm Tim Johnson. I'm Product Marketing Director at Electric Cloud, and thank you very much for being here. I put this panel together to talk about mainframes.

A quick question here: how many people love their mainframe, and that's what they're going forward with, and they want to do more DevOps stuff with their mainframe?

Okay. How many people are actively trying to get off their mainframe?

Oh, okay. I'm a little surprised. I was expecting that to be nobody. So we're going to change our questions up here a little bit.

Introducing our panel: Anders Wallgren, CTO for Electric Cloud. Rosalind Radcliffe, she is Distinguished Engineer and Chief Architect for DevOps for IBM. We have Chris Nowak, who is consulting with Q2 Strategies. He's currently on assignment at Bank of New York. And we have Torsten Volk here, who is an industry analyst from EMA.

So first question, we're going to throw it down here to Anders.

Anders Wallgren

Oh, sure.

Tim Johnson

So if we're trying to get off your mainframe, what are some dumb things to not do?

Anders Wallgren

Well, don't get off it unless you need to. Is there a problem that you're solving by getting off of it, right?

If it's processing 50,000 transactions a second for you, and you don't have a replacement for that, then you probably shouldn't get rid of it. On the other hand, if it's being replaced and you're not utilizing it and it's just an expensive asset at this point, and you don't want to pay to upgrade it, or get the new tooling, or train the people, or your people are retiring and you can't replace them, or any of those other problems, then you may have a reason to replace it.

But I would say, number one, don't replace it just because it's old technology. If it works, keep using it.

Tim Johnson

Yeah, Rosalind wants to grab the mic for a second. I'll pass the mic over now.

Rosalind Radcliffe

It's not old. Okay. It's the most modern chip we have.

Anders Wallgren

Perceived old. I apologize.

Rosalind Radcliffe

There are reasons. So, for example, if you're still running your email system on the mainframe, you probably don't need to do that. There are probably other solutions.

But if your business-critical system is running there, there's no reason for it not to run there. It provides the transaction performance. It provides the scalability. And if you use a modern DevOps pipeline, then there's no problem with getting people, so stay put.

Unless it doesn't make sense, and I will put that caveat, like email systems or something that's no business value, that's not your critical workload, that you don't really need it for, that it's not serving the purpose, then okay. But if it's serving a purpose, use it for its purpose.

Tim Johnson

Should we ask why those three guys are moving away? Yeah, I was just going to do that. So, you raised your hand about why you're moving away. Can you give us some ideas on why?

Q&A

A: Certainly. A couple things.

I think, so if you say critical system, of all the systems that are run on the mainframe today, there's maybe only one or two that are that critical. And everything else is there because it's sort of accumulated around the center of the big things, and they tend to have local copies of data, be inefficiently architected, be monolithic.

But then if I start to peel those things away and do functional things with microservices, it's easier to peel them away somewhere else than it is to peel them away on the mainframe. That's where the talent is in microservices and the other new systems that are out there.

So I think I'm moving towards a point where maybe that one big thing is all that's left, and I just connect the plumbing to it.

Another thing is licensing and cost model, right? So our structure around how we pay for it is 20 years old, who knows, right? So total cost of ownership maybe isn't in the best spot right now, and I can't control it. So I'm moving off as much as I can, as fast as I can.

Tim Johnson

Okay. Who else raised their hand? Was it you?

Q&A

A: Yeah.

Tim Johnson

Okay. So why are you moving off?

Q&A

A: Very similar. I don't know that we're fully moving off of it, but trying to get some workloads off of it because it does not make sense anymore.

Tim Johnson

Okay. So you're moving some workloads off.

Q&A

A: And some more critical systems are being rewritten. So are we going to rewrite them on the mainframe? I don't know. Maybe. That's great if we are.

Tim Johnson

Okay, so you're rewriting that. So, I think, Chris, you want to jump in here.

Chris Nowak

I was going to ask, and I think you started to answer it: is it really you're getting off it all the way? Or you're saying, we're going to do the right things where they need to be, and where it's still mission critical, it's not off the table as an option?

Q&A

A: Yeah, that's correct.

I did some assessments. We talk about this DevOps, and CI/CD, and stuff that's going to change. I would say the rate of change of the systems that live on the mainframe right now is slow.

And for systems that change rapidly and sort of need it, or that are leveraging the CI/CD, the DevOps, the pipelines, stuff like that, they're not on the mainframe. Actually, the points where they integrate with the mainframe are kind of pain points.

But yes, there's not a statement to say, I want a zero z/OS footprint by 2021 or something like that.

Tim Johnson

Okay. So you mentioned something that I think Rosalind probably wants to jump in on here, is the pace of change is much slower on the IBM.

Q&A

A: Well, I'm not saying that's because we're constrained. I'm saying just because those systems aren't changing much.

Tim Johnson

Right. Okay.

Q&A

A: It might be a lack of talent. It might be part of the attitude of the people that support them. It might be the way that they're sort of monolithic and siloed. And when I'm doing cross-functional things and building new things across that, I'm thinking different platforms, right?

So, I don't know how much effort I want to invest in saying, "Well, think modern and think mainframe at the same time," if we're already sort of moving in that direction.

Rosalind Radcliffe

But I think there are a couple of pieces in that that I want to kind of pull out. The first thing is that the mainframe is more than z/OS.

So first off, the mainframe runs Linux on Z. It also runs the secure service container. So if you actually want to do Docker in a secure service container, that's running on the Z hardware. If you want to run blockchain, that's running on the Z hardware. So the Z, the mainframe, does a whole bunch of different things.

When you talk about z/OS, it also runs modern languages and modern processes. So you're really thinking about a Java application that you might deploy somewhere. Maybe the data's there, so maybe you do want to run that Java application on Z.

So it's really all about what are you writing, how are you writing it, and where do you need it to run, and what are the qualities of service you need for that thing?

If you need it close to the data, high reliability, transaction throughput kinds of things, putting it on Z makes a lot of sense. If you need it running in every little part of the world because you need the data in every little part of the world, then maybe you're not going to run it on Z.

So you need to think about that workload and not think about Z as it's COBOL or PL/I. It's any modern language. It just happens to be more secure, and more reliable, and more stable, and all of the goods.

Tim Johnson

More and more. I think we picked up on that theme there.

Anders Wallgren

Too heavy to steal, too.

Rosalind Radcliffe

That's right. Hey, wait a second. If you've seen the latest one, it's a 19-inch rack. It looks just like the small baby Z. Looks just like any other 19-inch rack.

Anders Wallgren

You can steal them now, too. I'm just kidding.

Tim Johnson

Security piece.

So, the other thing I wanted to pick up on is you mentioned that things move slowly, and one of our other customers said, "Yeah, we have mainframe and we do one a month. And yes, we can do that deployment for you in October next year."

But does it have to be that way? And okay, Rosalind, yes, if you have the right toolchain. I'm going to give Anders a shot at this one.

Anders Wallgren

Yeah, actually, I'm going to ask this question. So, of those of you that are using mainframes, how many are using modern languages on the mainframe, no matter what OS and so on, or is it all COBOL, PL/I in the room?

Oh, there's one back there. So they're modern.

Q&A

A: Me too.

Anders Wallgren

How many here just found out for the first time that you could actually run modern languages and tooling on the mainframe and didn't already know this?

So you've just decided it's not worth it or for some other reason then?

There are people out there that it's just another node. It's just another, I got to push some bits over here, I got to push some bits over here, I got to send a message there, send a message.

From our perspective in ElectricFlow, not to talk product, but we don't care. I don't care, as long as you give me an IP address and some credentials and a command to send somewhere and a port number. We don't care. Why should anybody else care?

And so I think it really is all about the tooling. We have a similar thing with our other product, which is ElectricAccelerator, which is a Makefile-based product. It's parallel distributed make, and people come to us all the time and say, "People still use make?" I'm like, yeah, things that have been around for 40 years are generally pretty fucking useful, right?

The things that are not useful, they tend to go away after a year or two, like bad restaurants and so on. So I always find it kind of amusing that it's really about, if I can treat it as just another thing that I deploy to from the orchestration and automation perspective, that's the hat I wear, then I don't care. And neither really should anybody else.

Now, licensing costs and training, and quite frankly, yes, there are modern languages and those kinds of things, but getting a, and I'm going to be grossly generalistic here, but getting a millennial to go sit down and write software for a mainframe is, you're going to have to tie him down a little bit and convince him that it's fun.

Tim Johnson

We'll come back to that one. I think Torsten wants to jump in here for a moment.

Torsten Volk

Yeah. What we are seeing, and tell me if that's the case for you, too, but it's about the consolidation of the staff, right? And of the tooling.

So if you look at hyperconverged infrastructure, which has, I don't know, 20, 25% market share, and then you have your server platforms. You want to probably reduce the tooling that you also then use, and the expertise that you need, and the support for the mainframe, right?

And that's what we are seeing. And when you look at the show floor, it's actually quite interesting. They have a very nice new IDE for a mainframe where you can debug in real time and you see dependency mapping variables, everything looks super cool. And you can turn them into microservices, right, where you can get a RESTful API in front of it.

But I need to really ask, I don't have that knowledge, can the same administrators then, the same developers and the same administrators who would run Node.js or any of those tools, can they run them on the mainframe as well as they can run them on distributed, or do you need a separate group of people to do that?

Rosalind Radcliffe

So most of the tools and such can use the same people. So if it's Node, it's Node. It's the same tools. So those are the same kinds of things. If it's Linux, then Linux is Linux is Linux, and it doesn't matter.

For z/OS, you still need some number of z/OS system programmers today, though most of the data can be fed through Common Data Provider to Splunk. So take your choice. You can use modern tools as well.

In the end, you'll need a few system programmers. But I can bet based on what I've seen in the world, the number of system programmers required for a mainframe that does billions of transactions is significantly lower than the number of system programmers you probably have to maintain your Windows or Docker or anything else. So you need very few.

You still need a few. We haven't gotten all of the tools down to zero, as in different, but most of the tools are the same. Most of the skills are the same that you need in this environment. So it's not that different.

There are some CICS system programmers, IMS, some of those, but mostly it's very few.

Anders Wallgren

I used to work at a company that you may have heard of that does search. I won't name them, but my first experience, not Yahoo. My first experience there was I walked in and I looked around and I thought, "Can of shoe polish, anybody?" Anybody ever walk on a raised floor and—

Q&A

Q: I have a question.

I worked in the financial markets for more than 20 years, and I saw many guys breaking their face trying to downsize from the mainframe, the core systems. But looking for DevOps and looking for the future, I have some doubts, like the costs of the license, et cetera, and if you have some experience to create some more environments like development, QA, put the shift-left practices of quality. And how do you make a blue-green deployment to reduce the downtime in the deployment? This is my big doubt about mainframe and DevOps. I don't know if it's clear, my question.

Tim Johnson

Let me repeat what I think the question is so that everybody could hear.

So you've seen a lot of people try and fail at getting off the mainframe, and that one thing, a component that would be critical for you is blue-green deployment capabilities. Is that—

Q&A

Q: Yes. Deployment capabilities and the shift-left process from QA and the user acceptance.

Tim Johnson

Okay, and shifting everything left as much as you can.

Rosalind Radcliffe

So a couple of things. One, the mainframe has been designed for, I don't know how many years, to be 100% available. So VisaNet has been up for, oh, I don't know how many years, but it's more than 12, and it's never been down.

So there's nothing about Z that says you have to come down to do an update. You can roll the system. You can keep everything up and running, so that's not an issue. It might be an application problem. It's probably more likely a deployment problem or a historical problem: we always IPL on X date, so we're going to do it. There's no reason for any of that. You can stay up, first.

Second, Z is just another environment. You can create baby Z environments just as easily as I can create other systems. In fact, you can run z/OS in Intel Linux. We have technology that allows you to do that. So you can cloud provision a z/OS system, and so you can do your unit testing.

You can do each level. You could also use z/VM, the VM that existed first, virtual machine, the thing we have. You could use z/VM and provision them on Z hardware, or you can even do them in existing LPARs.

So there are multiple ways to do that. And actually, I did a DOES talk in 2015 that is recorded, that you can go out and see all about the automated testing and shift left and the fact that you can do it. So there are all sorts of answers.

There's nothing about the way distributed development works today, shift left, none of those practices don't apply to z/OS, and they can work just as well with COBOL as with anything else.

Anders Wallgren

And I think for me, it's kind of similar to when I hear people talk about, "We do firmware, so we can't do DevOps. Our stuff gets burned into a chip, and we can't possibly do DevOps." Well, that's BS too, right? It's the same thing.

You emulate, you simulate, all of those kinds of things. There's always a way to do it, and it's a little bit of a cop-out to say, "Well, because we're X, Y, and Z. We're the duck-billed platypus. We can't possibly automate," or, "We can't orchestrate," or, "We can't do unit testing," or, "We can't do these kinds of things."

I think there's always a way. Is it technically feasible? Is it financially feasible? Is it temporally feasible? All of those things, those are different discussions, obviously, but there's no laws of physics that says it can't be done.

Chris Nowak

And I'll amplify that. I did this in banks for about 20 years. Well, the DevOps piece is for maybe 10 years, and it's always that. We're like, "Well, we can't do this. My application's special."

I go, "I know your application's special. Let's take a look at it." And at the end of the day, I'd always say, "It doesn't matter to me. It's just another IP address." And you can do all of those things that you need to do if you just recognize that.

Now, the one thing you do need is a deterministic process, because if it's all over the place, you can't automate something that's random. So if you have the process and it's deterministic, and you have a target IP and a port and those things that you need from a networking perspective, it can be done.

Tim Johnson

Okay, so all right. Good.

So I want to get back to the point I was going towards. You mentioned millennials and so forth, and I tell my kids about, "Yeah, I actually sat and typed COBOL code on a card reader." And they're like, "That's when dirt was young, Dad."

So how do you get people interested in being mainframe-y and things like that? Is that a challenge that you folks have? Trying to get people interested that, "No, this thing actually does work and it's valuable and it's cool," and things like that?

Q&A

Q: I have a question before that.

Mainframe, we know that it processes huge amounts of data in faster time, but we always think it as processing on a serial basis, not as parallel as possible.

Now, I didn't see you mention talking about containers and microservices. When we talk about that in the distributed world, we have containers in an environment where these containers are monitored. They are looked at how they are spun up automatically on a load basis. Depending upon the load, it gets scaled up and all that, and trying to make sure that there's parallel processing as possible.

Is all of that possible? If it is possible, then it's a knowledge gap that we would pass, and how would we make sure that the knowledge gap—

Tim Johnson

Okay, so the question is, can you spin up containers, microservices, all that current magic that everybody's really excited about? Can you do that on a mainframe? Is that the short question? Okay.

Rosalind Radcliffe

So there are two answers.

One, if you're really using containers, Linux on Z runs just fine and works, in fact, scales up better. Depending on the workload you want to do, it can scale up instead of scale out, and so you can do larger processing. And there's a YouTube video about processing data in a way on a scale-up system. So you can do that. It's all there. It's all available.

If we're talking about z/OS, it is built for being able to do lots of transactions at once on the system in a reliable manner. So it's been doing billions of transactions on a regular basis. So yes, it's built for that. Yes, it can do that.

The problem is, let's step back to development. People say Z can't do parallel development. Yeah, great. That's because we've been on old library managers that are built based on a structure of waterfall development that assume that.

So how about let's use modern tools? So use Git, use Git branches, have your own isolated environment, and do development exactly the same way you do everywhere else, and then parallel development's just fine.

So there's no issue there. All of the barriers that are in your way or thought about Z are old processes. They're old thoughts. It's been this way forever. You're right, except the Z has moved on, so let's move our practices on.

Tim Johnson

Okay. So I think you mentioned something about you got hidebound old guys doing it the old way, and what we've heard from questions and so forth is it sounds more like an education issue here than anything else.

It's a cultural issue. You're talking to millennials, and you say COBOL, and they go, "What is that? My granddad wrote COBOL," and things like that. So how do we overcome that?

Q&A

Q: Is there a SonarQube plugin for COBOL? Is there a SonarQube plugin for COBOL?

Rosalind Radcliffe

Yes.

Anders Wallgren

Yes. I mean, seriously, yes.

Well, I'm going to ask the question. So forget about mainframe for a minute. As you've all gone through DevOps journeys, and I'm assuming that you're more than day zero on these things, you're here, haven't you resolved these problems already?

You're like, well, if there's this technology, this, it's Java, it's .NET, it's whatever. You've done these things. You've said, "All right, let's collapse these things to common processes and common tools where it makes sense."

Why is the mainframe any different? Go ahead. It's culture and people.

Rosalind Radcliffe

Yeah. So it's culture and people. The people that have been there have been doing it for a long time.

But when you're talking about getting kids on the platform, how about when they come in and they're new kids and they're working, you don't start with a sentence that, "Z's going away, so this job's going to go away." Or how about you don't start with, "That part doesn't matter," or, "We're going to do the fun stuff over here."

How about the sentence that, and one company uses this, "The work that you're going to do on this system runs the world. You're running the major banking system. You're running the credit card system. You're processing all the transactions for..." Or, "You're running the airline."

All of those are true statements. So instead of doing the negative about what they're working on, do the positive about what they're working on. It's real value. It's running the businesses. Explain that, and then kids don't—well, kids might have a problem with ISPF, okay. But kids don't have a problem with building stuff for Z. They have a problem with old tools and practices.

Tim Johnson

Okay. Torsten, you want to jump in on that?

Torsten Volk

Yeah. From what we see in our research, it's really all about integration, which costs money, and education, that also costs money, and tooling, that, again, costs money.

It's a consolidation thing where we have a lot of data that basically shows that, and hopefully you guys can confirm that too, that from a multi-cloud management perspective, from a data center management perspective, it's all about squeezing cost out of the OPEX, getting the OPEX as low as possible.

Adding another technology, by definition, is the feedback that we often get is not in the books. And I'm so hesitant, which I usually am not, for people who know me, but it shouldn't really be a cultural problem because the four nines we were talking about, does the mainframe have four nines on-site or six? I don't know.

Rosalind Radcliffe

Five nines.

Torsten Volk

You know how many five nines. Okay. And I know you need a distributed infrastructure. You need to build a hell of a lot of a system that's also not that easy to build over multiple sites to get the same number of nines.

So that's what I'm saying. As an industry analyst, there's a couple of things that I don't fully always grasp from our realm, from a tech perspective, because it looks like a good proposition. But IBM may not be spending enough money on the marketing. I don't know.

Q&A

A: Can I just—

Tim Johnson

Okay, we got Paul here from Compuware.

Q&A

A: Yeah. No, I just wanted to share, I think, a beacon to all this.

A lot of the companies speaking this week here, and I think of American Express, ABN AMRO, Lloyds, Lincoln Financial, they all saw these as opportunities. They were mainframe companies. They've incorporated their DevOps initiatives and brought the mainframe into that. So we're seeing great things happen.

So I would suggest, for those of you that are just looking for how can you do it, you look to leaders like American Express, ABN AMRO, Lloyds, Lincoln Financial, because they're doing it, and it's been pretty cool to see in the mainframe space.

Tim Johnson

Okay, so we got four minutes left. I want to ask a question here and maybe incorporate: what's preventing you from being more successful with your mainframes right now?

Q&A

A: The comment, real quick, I wanted to make is I work for AARP. Our core business runs on mainframe.

There are lots of design patterns you can use to actually modernize, for lack of a better word, that the strategy works much better than talking about re-engineering into a modern system.

If you were building a system from scratch, the difference is vertical scaling and horizontal scaling, and we can have more discussion. I think that's the point the gentleman was making at the back. It was less about the tools, the answer was around tools, but more about how can I build horizontal scale databases that large systems can scale.

A: And just to add to that, because we're the same company. They run the mainframe. We run the web service that calls the mainframe for a lot of processing.

But it's so much easier for us to implement DevOps on our middleware because the tools that are available, because of the number of people that's doing it, or we can do additional research.

We feel like if we do it on the mainframe, besides the companies that we mentioned, we almost feel like we will be devoid of the pioneers and not having a lot of help on the forefront.

Just as when we implemented CICS on the mainframe, as an example, so we can call them from our Java codes. We felt like we were one of the first probably.

Rosalind Radcliffe

I think one of the problems is, in the mainframe space, people are quieter about what they do. And so I'll say you're not one of the first. People are just quiet, and we need more of the mainframe customers to stand up and explain externally what they're doing.

Tim Johnson

So the call for papers for DevOps Enterprise Summit 2019 is going out very shortly. So, we got one more in the back there.

Q&A

A: I think the problem is, and I love mainframes, I come from a mainframe world, but the trend is you are not embracing change or moving with the technology if you advocate going to mainframe.

Now, in those regard automatically, we are migrating any match from mainframe to distributed. Now, the problem is we have these systems that were built in the '90s, and the structure is different. They were monolith solutions, so the entire mainframe gets a bad rep. Rather than solving the problem, they said, "We're going to leave it out in the border."

Tim Johnson

Yeah, exactly.

Q&A

A: That's a problem. And I think, I don't know if that's one of the panelists is IBM or not, they need to do a better job in articulating the value.

The amount of money that's spent on support, all these distributed issues, your networkless. Everything works on mainframe. I'm talking as a detail. Only thing you can screw up most of the time is your application in WebSphere. Mainframe works.

Tim Johnson

Okay, thank you.

Q&A

A: I'd just like to add something, but I won't say that they're in my company.

Tim Johnson

Okay. All right, one more here.

Q&A

A: We work for the same company. So I'd just like to add.

This is a five-year journey. And for four years, most of the vendors talked about distributed. That was the easy place to play. All the new products came out.

Okay, my conversation always with a vendor is, what do you do on the mainframe? You get the deer in headlights. You say, "What about Db2?" He's just running away.

This is new. This opportunity for mainframe to be treated in the same way is a new conversation. And it's because mainframe is so stable, we've not had to have the conversation.

Now we've beat the crap out of distributed. Now there's an opportunity. So I think it's timing. I don't think it's anything other than people now suddenly see there's value. They can sell you products, and you can start to move in the space.

Tim Johnson

Okay, great. Thank you. Anders, you want to close it out?

Anders Wallgren

Yeah, one thing I was going to say is there is an old saying: those who don't understand Unix are doomed to reimplement it again and again, poorly. Right?

There's a lot of lessons to be learned from mainframe architecture. And I think it's a good observation that I bet you people who have problems moving their apps off of mainframes would have the same problem moving that same app out of WebSphere running on Linux, because it's a monolith and probably maybe not architected right to be able to put it into microservices and all of those kinds of things.

And so, you are throwing out the baby with the bathwater a little bit if you tar the mainframe with the monolith brush, if you will. Right? And I think you have to understand that.

And I think there's a lot of rude awakenings that are going to happen for everybody that thinks they can just lift and shift everything into cloud without being a little bit cloud native, right? That doesn't work either. It does not compute.

And then one last thing I wanted to say is I think there is a little bit of education missing here, right? I think one of the things that I lacked in my education many years ago is this notion of, look, you're going to walk into a lot of situation where there's history, there's culture, there's technology. Not all of it can be replaced. Most of it shouldn't be replaced. And you have to work in those constraints.

And that's something that people have to understand from an engineering perspective. Right? Good and bad.

And I think there's a lot of just sort of, oh, well, let's just rewrite it in the coolest new thing, whatever that is. And I think there has to be a little bit of perspective on the trade-offs of all of those things. And I think education is part of it.

And if we're not educating our computer scientists these days to understand that there's this hardware, and there's that hardware, and there's this type of thing, and that type of thing, I think we're doing them a disservice.

Chris Nowak

For sure. And also, didn't make workloads mobile different.

Anders Wallgren

Yeah, exactly. Kubernetes, service-oriented architectures, and there's a bazillion different things that we've tried where we end up blaming the technology, when really it was probably mostly application architectures that are to blame for the problems, honestly.

Rosalind Radcliffe

And to step away from technology, think about it from the business perspective. Right? What problem are you really trying to solve?

Do you need sub-second or millisecond transaction times? How cool would it be to detect fraud in real time? That's interesting.

What about social media? How do you get ahead of your competition because your mobile is connected directly to the mainframe through an API? That's kind of cool. Right?

Print up those Big Iron T-shirts and pass them out. This is another tool in the toolbox.

Tim Johnson

Any other comments? Okay, so I think a couple of takeaways. Next year, this is going to be a town hall, so you guys can ask more questions.

Two, I think we're going to put together some kind of secret society pin or something that, "Hey, I'm a mainframer."

Rosalind Radcliffe

Not secret.

Tim Johnson

Society.

Rosalind Radcliffe

Public society. Everybody needs to see we're proud.

Anders Wallgren

Everybody who has a 15-pound laptop is a mainframer.

Rosalind Radcliffe

That's true.

Tim Johnson

Well, a laptop can be a mainframe. Yes, you're right.

So I've had fun. Has this been valuable for you folks? Okay. All right. Thank you very much. It's break time. Enjoy.