Modernizing the Mainframe with Michael Minella

Episode 112 · 28:55 · SRT · archive.org · all Tanzu Talk

Hey there, everybody. Welcome to Pivotal Conversations. This week, Dorman and I chat with our colleague, Michael Minella, who's the Director of Software Engineering here at Pivotal. He's going to tell us about mainframe modernization. He's going to make the case for it, and he's going to talk about what's the same and what's different between mainframe modernization and other modernization and transformation efforts. It's a really interesting episode. I hope you enjoy it. It's a Thursday. I woke up thinking, I really want to talk about mainframes today. And conveniently, we had this recording scheduled with Michael Minella, and he's recently given some talks about modernizing off of the mainframe. So just coincidence, pure coincidence, that here we are going to get insights direct from the source on modernizing off of mainframes. I can see your nose growing on the screen. You don't need to talk about my nose. Like, the whole point of being on a podcast is that I can have a face made for radio, and no one needs to know. So, okay. Well, like I was asking Michael right before we started recording, but basically, my big question, since we have had a lot of different discussions with folks in the, you know, systems integrator community, with end users who have been doing modernizations, there's lots of great stories out there. When it comes to the mainframe, what's different, right? There seems to be a lot of, you know, well-honed practices, like our app transformation team has some great exercises for identifying

kind of the seams of a monolith and starting to break that apart. What changes about all that when you start to look at a mainframe application? So, that's a great question. There's a few different things. First of all, politics and emotions are typically a lot higher when it comes to mainframe modernization projects. I like to look at it as it's about 70% culture, politics, you know, that side of the sphere, 30% technical. Moving the stuff off the mainframe, there is a technical challenge on the mainframe that we can't solve in some other way these days. However, the politics and emotional baggage around that is infinitely higher than a normal decomposing the monolith style modernization project. Because when you think about it, if you're going to, let's say you're taking, you know, a legacy Java EE app and you want to modernize it, right? It's been run on WebSphere or something like that, or some app server, all the traditional type stuff, right? That same team, the same set of developers, for example, that are maintaining that application, they're still going to use very similar tools in their daily development cycle as they will once it's been modernized, right? If you take a Java EE app and convert it to Spring, you're still using the same IDEs, you're still using JNU for tests, you're still using, you know, you can even still use CICD and all those, the general, what you do from day to day isn't going to change. If you're a mainframe developer, if you're a COBOL developer, your world is going to be flipped upside down. Everything from every tool you use, you have to learn a new language, testing is different, just everything about it is very different. And that is a very intimidating thing to face. You know, you're talking about,

okay, now is, not only is it from a, A, do I, can I learn this stuff? B, do I want to learn this stuff at whatever stage of my career I'm at? Is my company even going to support me relearning this stuff? Are they interested in retraining me? Are they interested in replacing me? You know, this, this is the kind of thinking that goes through when that happens. And so that's why the politics and the, and like I said, the emotions run a lot higher on mainframe modernization projects. Politics also run a lot higher because the fact that this isn't just revamping your website, your public facing website, right? This isn't, you know, changing the style sheets on that kind of thing and just deploying it to a new platform. This is typically the crown jewels of your enterprise. So this is usually where the buck stops. So there's a lot more risk involved in these projects, or at least it's perceived that way. And so if you're looking to be risk adverse, the idea that you're going to, you know, take what you've standardized on for 10, 20, 30 plus years, and all of a sudden change that, that's a very scary proposition for an enterprise. Let's take one small step back. What's the benefit of moving your applications off mainframe onto a modern platform? Why would you want to do that in the first place? Let's, let's kind of lay that out, the reasons you do it, and then we can get into a little bit more about how you do it and what's different about it. Sure. So I think of it as four different things as far as why you would do it. First is increased productivity. All the modern development frameworks and platforms allow you to iterate on these mainframe style batch applications in a much quicker way. All the things that you get from agile development, from, you know, the modern platforms, from modern frameworks, all those things apply in the batch world. They apply to those mainframe workloads. Second one is on-demand scalability.

If you have a mainframe, you're paying, you know, you've leased a piece of hardware, you might be paying by CPU cycle. But the idea that, you know, once your work, once your volume gets to a point where you can't meet SLAs, what do you do, buy a new mainframe? I mean, it's just, it's not a practical solution. Whereas with modern platforms, you can scale much more dynamically. both from a initial cost, as well as, you know, on-demand. So month-end processing, you may need more processing. Then you can shut all that down and repurpose it for something else if it's not being used. Third one is security. A lot of people don't think about security very much with, you know, on the mainframe. They think, you know, green screen, nobody's going to hack my mainframe kind of thing. But two things there. Number one, if they were to get access to your mainframe, it's probably game over. They now have, you know, like I said, your crown jewels. They've got access to every financial thing. Everything you could possibly want is probably on the mainframe. And there are people out there doing work around hacking mainframes. There's a training course called Evil Mainframe. There's a couple of guys that have been around. Phil Young. And Chad, I'm going to butcher his last name. Rick Ansarud. I apologize if you listen to this and your last name butchered. But those two guys have been going around to all the hacker conferences, DEF CON, Black Hat, et cetera, talking about how to hack mainframes. And so the idea that this is some piece of hardware that is no longer penetratable is just not the case anymore. Last thing for me out of the four is reduced costs. So if you're not using it, you're not paying for it. Resources are easier to find with regards to development resources. All those kinds of things fall into that decision.

Okay. And so when you talk about the politics and the cultural resistance, you're going to have to make a case for why you're going to do this. And those four things you just laid out sound like that's the business case. That's, yep, pretty much. Yeah. Well, I mean, what's interesting is that what's not on that list is something you often hear, which is the, like, you know, all the COBOL developers are retiring, right, in the next five to 10 years. So who's going to maintain or update these mainframe apps and this kind of, you know, you're facing a development wave of life or end of life, if you will, working life. I've put that into both points one and four. So increased productivity and reduced cost. Increased productivity and the fact that you can probably find developers quicker on non-COBOL mainframe style workloads. So you can find more people to work on this stuff. That's going to make your enterprise more productive. Well, if you've got more developers, you know, you don't have a supply and demand imbalance. Yeah, sorry. Yeah, exactly. So, okay. I'm just trying to confirm that there isn't some, like, weird hipster revival of learning COBOL going on out there that's cropped up in the last five years that I just missed my radar that's like, you know, beer, pour over coffee and COBOL. There is a project on GitHub of a guy running COBOL on AWS Lambda. Of course there is. I'm not saying you should. So you kind of laid out two different important dynamics of the people side, right? The folks who are working and their lives are going to be really disrupted and then there's the kind of the perceived risk around moving things and I do want to talk about the technical side too but I'm just, you know, to double click on each of those. So if we start with the people, what's, what's like kind of the different, like the way of approaching it for them that's like, listen, if you don't do this,

here's what you're missing out on or here's what, you know, there's that kind of fallacy notion that some people have where it's like, oh, it's too risky to move this thing and it's like, but it's actually more risky to stay where you are. Like change always seems risky but you're not actually looking at it objectively against what you're currently doing. So same thing with, you know, if we look at the people side, folks who are, hey, I'd have to go learn a whole bunch of new tools. You can certainly lay out the opportunity of like, well, if you go learn a bunch of new tools, you're going to have a bunch of new opportunities but what's also the kind of downside for them to not do that? Well, I mean, one other thing though is a lot of developers when you say it's too risky to not move, that's usually a problem for people above the developer ranks. Right. I think that's probably kind of more the second point on the politics side of it but, you know, coming to the developer who, you know, one of the greater points of friction with the mainframe modernization is that a COBOL developer is really intimidated by the amount of change that they're facing. So what do you, how do you navigate around that? How do you, what have you seen work in terms of bringing those people along? You know, that's a great way to put it which is bring them along. You know, you can look at this as you're going to bring in an army of consultants to convert this and the existing developers are kind of left out in the cold and that's the way they feel that it's going to happen but it's been my experience actually it can't happen that way for a couple reasons. Number one, consultants leave so you kind of have to maintain the stuff going forward which implies that somebody's going to have to be retrained in, it's good business to retrain these people in these modern tools. The other thing though is

a lot of these mainframe systems the history of them because they last for as long as they do there's a history in that code that only those developers know. the way mainframe systems are maintained is just fundamentally different than like a Java app. You'll see systems where you'll have a database column and you read in COBOL the data definition which lays out what that record format looks like and you'll talk to the developer that's maintaining that app and they'll be like oh this column over here column foo yeah that's for this that works the way that definition is for this case but remember there was that one deal five years ago where we had to satisfy this other customer we just recycled that column like that happens all the time and so the only way so you have to bring these guys along these developers along because they're the only ones that know this stuff they're the only ones that have that history that really is baked into the code Is there kind of a successful way that you've seen that process work like in terms of pairing them with some of the the developers who are more fluent in the modern tools and and have them kind of sitting side by side so the there's sort of knowledge flowing both ways or is it something else that works better nope pairing is actually a great way to do it I mean probably the most successful mainframe modernization project I can think of we did it as a two phased approach phase one while you know the people that were comfortable with the tools were busy in the architecture space and figuring out you know what this is going to look like in the new system we actually brought in consultants to go you know teach this team Java you know where does the semicolon go how do you do an if statement all that kind of you know basic language fundamentals

we started off with that and then when it came time to actually start migrating the actual COBOL code that's when we started pairing okay and then so now like looking at the the second piece that you mentioned of the politics and kind of again a little bit more on the the business side the the higher pay grades if you will that are just they see this as risk how how have you seen that successfully navigated so I put it this way as you accelerate the front end of your business so whether that be apis apps all that all the externally facing stuff and even internally facing stuff but as you accelerate those parts of your business they eventually feed into your batch processing those things are still going to you're going to have to be able to iterate on those you're still going to have to keep those up with those other systems and you don't want that corner of your enterprise to be the bottlenecker or the anchor that you have to drag along you want those to be iterated on just as fast as those other systems and so by moving to a modern platform moving on to modern tooling that allows you to iterate faster with those back-end systems just as you can on your front-end systems yeah that's the that's the death star analogy which I didn't really know was you know pertaining also to mainframes I just think of any back-end system is like you know just doing some cool sexy front-end thing or a mobile app or something you've shot down some TIE fighters but you know you still have this looming death star that's gonna eventually just destroy your planet or something we watch a lot of Star Wars in my house also particularly episode six lately so yeah we're right in it with the death star oh no well so you know I feel like we've covered like the 70% and you

said then there's the 30% that is the technical side so you know now we've kind of aired out all that squishy stuff let's talk about the technology side what do you see that comes up again and again and again obviously you're kind of coming at this from the you know spring batch spring cloud task perspective and so I imagine that's going to be one of the technologies you see featured again and again why you know help us understand and is there anything else that kind of on the tech side you see as a pattern yeah so you're right obviously I'm a little biased towards I come at it honestly being the lead on both those projects but yeah so walking through the tech stack in general I see as a healthy way forward it starts off with a platform a modern platform that can do the things that we talked about you can iterate fast on it you can scale dynamically with it and PCF PKS both those are very viable options one thing that you also see that you have to typically navigate through is a persistent disk on both of those that is something that a lot of times will be a bit of a hiccup if you will or something that you have to work through like I said that 30% there's nothing in there that you can't work through we've got examples of using volume services on PCF for example for the persistent disk on PaaS but it is something that is a common question other common question for the platform specifically would be what about scheduling scheduling is something that is almost religious in most enterprises they have a scheduler and it getting a change get changing that tool is like I said almost like changing religions it's that hard to do so

then pause a little bit what is the scheduler in the mainframe world for those of us you know uninitiated in these religious practices so the scheduler is going to be what orchestrates your batch jobs so you can imagine somebody's got a dashboard sitting in front of them with a bunch of boxes those boxes will turn from green to red based on whether they finished and that is really the operation side of the mainframe it's where the monitoring the orchestration all that happens and so moving off the mainframe the question then becomes how do we replace that and it can be a number of different things you know in some cases it's stick with what you got because a lot of those aren't mainframe specific like a control M that's something that isn't mainframe specific so there's no reason to move away from that specifically if that's what you're comfortable with all the tools that would be in our portfolio can work fine with it but you don't have to PKS PC they both have schedulers built in so you can do stuff like that if you need more complex dependency management between your jobs you can get things like Spring Cloud Dataflow with its composed task concept where you can define flows I need job A to run and then I need job B and C to run in parallel once both those are done run job C if orchestrate with Spring Cloud Dataflow and do time-based scheduling built in with the platform Do you see functions serverless any of those approaches replacing parts

of what these scheduling jobs are doing or do you have to take a few steps before you would be able to get to that point anyways we're not there yet we're not there yet one thing that we do see commonly and we talk about when we are talking about mainframe modernization projects is does this stuff need to be batch oriented obviously it was developed that way originally but does it make sense going forward and it's not uncommon for us to be like well this job over here yeah that should be batch but this other thing RIF has and PFS have those kind of capabilities for the streaming model pretty well baked in we're still working through what that's going to look like in a functional style okay so you know you mentioned having to navigate persistent disk having you know running into the scheduler and solving the scheduling problem anything else that's kind of like big common areas on the technical side that need to get worked through well it's what is the programming model which brings us to you know like you mentioned at the top it's spring batch sprint and spring cloud task and using those frameworks to develop resilient applications that you'd be willing to trust your crown jewels to you know most of this or I won't say most but a lot of batch applications are run middle of the night kind of thing which means if it fails somebody's getting a page at 2 in the morning and nobody likes that so using frameworks that are battle tested and have the various error handling capabilities that a spring desk provides can lead you to a more sane result than going on your own I'm curious just working with customers I mean do you

have any anecdotes you can share or any real world lessons not that these haven't been in real world but anything you can tie to actual engagements you've seen or anything interesting out there that might be of interest to folks listening a common scenario we run into is companies that have gone their own they've maybe shut down the mainframe but they've built their own batch framework for example on the DIY approach and are coming back to us and be like you know what that isn't the way we want to go long term we did have a conversation with one client where they had built just about everything else around the mainframe emulators of this stuff and they were intent on moving the COBOL off the mainframe really just replacing the hardware and none of the software and we advised against that because you know now you're getting no benefits of moving off the mainframe because you're still using all the tools but you're actually worse now because now you've got to maintain all those emulators and other things you've built around that you can see potentially someone who's looking at this from a risk perspective and say someone's won the argument that piece of hardware costs too much and so it's like okay fine we're just going to solve for that and that alone because everything else seems risky I could see that that leads you down that path because again it's not looking at it holistically it's just you know someone won the argument that you need to stop paying for the hardware right and it's like okay it's a little myopic but sometimes that's how it works in these kind of internal battles right budget line whatnot exactly I can't speak to this specific scenario but the way I can imagine it that decision coming down is you know somebody without any technical acumen about what that this means just said you need to get rid

of the main frame and like nobody else in the technical side agreed with the decision so okay we'll get rid of the main frame yeah so you know I want to circle back to my first question which was around you know what's different about the main frame and now revisit it is like what's the same what's basically like this is no different in this regard this is no different than modernizing off of say you know Java EE or just any other kind of legacy workload you know it gives you an opportunity to look at the problem again and in a lot of these applications like said 10 20 30 plus years in production so you haven't really had the opportunity to revisit you know the architecture or any of this stuff in that amount of time it's no different than you know taking your your application from Java EE with running an application server you've been maintaining that for five ten years let's say it's still that that green not necessarily green field but it's the opportunity to to update you know you get that that green that clean slate again which you don't always which is a great thing to have anytime you write an application where have you seen that kind of just really blossom in a in a lovely way right like where that taking the opportunity to revisit has actually yielded a real you know business outcome because they were like wow we we hadn't even broached the idea of being able to build something that you know now is actually helping us grow adding new revenue or helping us compete or something I can think of one example where you know they're looking for better faster cheaper was the way they came to us with it they had the same concerns you know my developers don't know

java and then we were able to get them you know they knew enough java they had other developers that knew enough java where they could be productive but they're like they don't know spring so and by getting that ball rolling you know once they got comfortable in the architecture we gave them then the next step was getting them comfortable spraying and it just kind of blossomed from there what else is the same in your experience with just other kinds of modernization efforts you know where the end result the end tool set you know you end up with a tool chain that is familiar to anybody who's been through those before you know the modern platforms the spring based tooling all that those kinds of things the end what it looks like in the end is very familiar to anybody who's been through that which is nice because you can typically take you know resources that have been working on let's say any other modernization project like this and get them embedded in these teams relatively painlessly you know it's not like the main frame the end result is fundamentally different so you have to have different developers for this thing no you can recycle any of your developers now and do the same and get them very productive in these new tools very quickly you know whereas before they really couldn't touch that whole stack you know the idea of having your web apps come over and cranking out some cobalt code that probably wasn't going to happen so now you actually get that opportunity cool you've been you've been kind of speaking a little bit about batch and mainframe modernization lately we're where can folks find more stuff from you or where are you going to be speaking this spring and where can they follow you sure so I'll be at dev nexus in March I will be at I'll be doing a couple stops

on the spring one tour and then I'm also on twitter obviously at michael manella and I'm also on another podcast called off heap it's a java off heap it's a pundit podcast so if you want to hear a bunch of guys in a bar talking about the latest on the jvm check that out all right that's that's helpful thank you yeah I got a book coming out later this year it's the definitive guide to spring batch so it'll be out later this year it's an update to my previous book all the examples will be bootified and there's even a chapter on cloud native batch development so check it out okay all right great well thanks for joining us appreciate it we'll include links to all those great resources of course in the show notes

Tanzu Talk · 🍕 Get more pizza.