devopsy.kinsta.cloud

Tag: mainframes

  • Going Cloud-Native with IBM Z as a Hybrid Cloud Platform

    Going Cloud-Native with IBM Z as a Hybrid Cloud Platform

    When people use the phrase “they don’t make ‘em like that anymore,” 100-year-old bridges, Jon Snow’s sword and American muscle cars often come to mind. If the topic of discussion happens to be computer technology, however, mainframes are without a doubt the Valyrian steel of the enterprise and lucky for us, are still in production today. While the cloud computing concept as we know it has been around for only about a decade, mainframes have been delivering on-demand access to compute and storage resources that are safe, scalable, highly available and resilient for half a century.

    Big Iron Advantage

    In today’s enterprise scenario, the mission to gain an edge over the competition in terms of pure horsepower can be elusive, to say the least. Although 20% of the easy enterprise workloads have moved to cloud platforms, it is estimated a large amount of data and applications continue to be run on-premise as enterprises determine their hybrid cloud strategy. Far from being irrelevant, mainframe architecture now finds itself at the center of this digital battle, causing disruption and giving its users a much-coveted and undeniable edge over the competition. In addition to running over 8,000 VMs on a single system, mainframes offer some of the most scalable storage in the industry.

    In case that isn’t enough, couple that with pervasive encryption, multi-factor authentication, a co-processor dedicated to cryptography and the most trusted and secure Linux environment in the industry today. What you get in the end is a major breakthrough with regard to cloud limitations that many early adopters of cloud technology found out about the hard way. These limitations are especially true with regard to cybersecurity, and though private clouds help alleviate these risks to an extent, IBM Z removes these risks by enabling all-encompassing encryption.

    Enabling the Hybrid Cloud

    While most people were skeptical of mainframes making a comeback until about a year ago, the majority seem to have changed their tune. There are two reasons for this: One is IBM’s new take on the mainframe, called IBM Z; and the other reason is its applications with regard to the hybrid cloud. Hybrid basically refers to organizations using a broad combination of public, private, IaaS and Paas in the same application solution. Mainframes are proving an important part of hybrid infrastructure thanks to the massive compute, storage and scalability features they can deliver.

    Another advantage mainframes have in a hybrid environment is simplicity. Every engineer knows the more moving parts, the higher the risk of a breakdown, and the same holds true for the hybrid cloud. In a complex, multi-cloud environment that often spans more than one public cloud and a variety of on-prem resources, the more discrete devices involved in a network, the higher the risk of something failing. With a mainframe like the IBM Z, you have one device that delivers broad functionality at high efficiency and low cost. And it does it for a few decades, without complaining.

    IBM Z and the Cloud

    IBM’s Z models are lean, mean, transacting machines. Recent innovations in hardware and software design have made it possible to run not just native mainframe apps, but also most Linux-based operating systems and applications on these systems. IBM Z also features machine learning and AI frameworks, as well as support for Apache SparkML, TensorFlow and languages such as Scala and Python. Capable of running more than 12 billion fully encrypted transactions per day on a single machine and 850 million on IBM’s skinny version, the z14 has a 35% capacity increase for workloads compared to the z13, and it’s being touted as the most powerful transaction machine in existence today.

    Combining mainframes and cloud platforms in today’s hybrid environments may sound like old wine in a new bottle, but it effectively gives you the best of both worlds–the scalability of the cloud, along with the power, security and dependability of the mainframe. Additionally, the mainframe’s ability to house both data and applications on the same device, while dedicating processors to specific operations independently, make it ideal for ensuring speed in such complex and distributed environments. IBM Z also features a multiple processing structure that makes it ideal for dealing with the varying bandwidth needs of modern applications. It can process Java workloads up to 50% faster than x86 servers.

    Cost Efficiency

    Forty-four of the top 50 banks in the world run on IBM Z servers right now. They understand that running their applications on a mainframe provides security and scalability for a compelling return on investment. Large enterprise systems have had a perception of being expensive, but when you factor in such things as space, power and cooling efficiency, as well as the number of personnel required to administer the system, the total cost of ownership is a value-add when leveraging Z in your hybrid cloud strategy.

    — Twain Taylor

  • Mainframes: The Cloud Before the Cloud

    Mainframes: The Cloud Before the Cloud

    Here’s something to think about: Despite the fact that IBM stopped manufacturing personal computers in 2005, deciding instead to focus on higher margin business services, the company continues to produce mainframes and by all estimates will continue manufacturing them well into the future. The question is, why? The answer: because there is still significant demand for this type of hardware.

    The fact is that a mainframe is a monster when it comes to computation and processing transactions. One mainframe can process 2.5 billion transactions daily. That’s the equivalent of 100 Cyber Mondays in a single day. To give you a clearer idea of the immensity of scale, keep in mind that Cyber Monday sales in 2018 were $7.9 billion. This translates into a mainframe being able to handle a bit more than three-quarters of a trillion dollars in transactions each day, which is almost twice the yearly GDP of Austria!

    As I said, the mainframe is a workhorse. Yet, its power and potential are hidden from most people who work in the modern cloud. This is surprising because there’s a good argument to be made that, given its power and scalability, coupled with its support for a large number of concurrent users, the mainframe was the cloud before there ever was a cloud. However, the technology is practically unknown among younger developers, mostly due to cultural reasons and a lack of historical awareness. That more people are not taking advantage of the tremendous opportunities at hand is a misfortune. When it comes to mainframe computing, there’s a lot of interesting tech to be learned and a good amount of money to be made. It’s just a matter of increasing awareness to do this. A good place to start is to redefine the narrative.

    Allow me to elaborate.

    A Special Club

    When mainframes appeared on the commercial landscape, few people interacted with computers and even fewer worked with them directly as programmers or system administrators. Just as in a modern data center, the machines were isolated in climate-controlled rooms to which few had access. Access to the actual physical machine was restricted to a special few. But unlike today, when restricted access is due more to security concerns because there are a lot more people around who are potential black hats, back then access was also restricted due to the exclusivity of the profession.

    In the 1950s, 1960s and well into the 1970s, not just anybody could program or be a systems administrator. You could go to a technical school to learn to become a computer operator, which meant you could work at a terminal as a bank teller or travel agent. Or you could learn to become a data processing clerk and work in a back office at a brokerage firm. But to learn to program, you had to go to college. Then after college, you had to go to work for a company or organization that actually used computers in day-to-day operations. These were banks, insurance companies, major manufacturers such as General Motors and General Electric, airlines, very large retailers and government. Computing was a club and you had to be well-educated to get in and be well-liked by the organization to keep your membership. Yes, there were the outliers—Gates, Allen, Joy, Wozniak and Jobs—but for most people, the career path to being a programmer was college and then into big business or government.

    As a result, computing had an air of mystery and magic to it. Remember, until the mid-1980s, most people had never touched a computer. It was the stuff of moon landings and election night predictions on network TV. Then the PC came along and changed everything. Within 10 years computers became commonplace. Even elementary schools had them—at least, those that had the budget and foresight. The power that business applications such as the spreadsheet program Lotus 1-2-3 brought to small business motivated even the dry cleaner on Main Street to plunk down the thousands of dollars it cost to buy a PC. The productivity boost was worth it. Also, since the dry cleaner actually owned the machine, the dry cleaner’s kid could learn to program on the box unencumbered, when it wasn’t being used during business hours. Remember, the Microsoft DOS operating system that shipped on every IBM-compatible PC came bundled with the programming language BASIC. You didn’t need to go to college to learn to program; all you needed was a book.

    So, PC programming took off. Instead of having to go through the effort required to get into the special club the mainframe programmers belonged to, PC programmers started their own clubs and anybody could get in. All you had to do was show up. PC programming became a meritocracy. Also, it became extremely lucrative work. There were a lot of PCs being shipped and the appetite for applications to run on them was enormous. The unlikeliest of people, such as Lotus Software founder Mitch Kapor and his sidekick, Grateful Dead lyricist John Perry Barlow, became wealthy, thanks to the PC.

    The PC became cool and programming for it became cooler. But there was a fact that got obscured as the popularity of the personal computer grew: Compared to the mainframe, the PC was a toy—a productive toy, a liberating toy, but a toy nonetheless, very much in the same way that a go-kart is a toy compared to a Formula One race car.

    Feature for feature, the mainframe ate the personal computer’s lunch. The IBM System/370 Extended Architecture Mainframe released in 1983 was a 31-bit machine that could support up to 8MB of memory with a processor running at 38 MHz. By comparison, the IBM PC-XT, also released in 1983, was an 8-bit machine that shipped with 128KB of RAM and an 8088 processor that ran at a speed of 4.77 MHz.

    But, as the saying goes, “You should never underestimate the value of cool,” and the PC was very cool. It got a lot of attention while the mainframe stayed hidden away in climate-controlled rooms in the basements of banks and insurance companies. Yet, the mainframe was more powerful, and whereas the PC was meant to meet the needs of a single user, a mainframe can service thousands.

    Built to Scale Built from Inception

    Mainframe computers from the start were designed to support hundreds (if not thousands) of users. However, more importantly, mainframes were and are designed to support millions of concurrent transactions. When you think about it, while it’s possible for a high number of user requests to exhaust CPU utilization in a typical commodity machine—which is the reasoning for being able to scale up CPU count by increasing VM allocation in the cloud-based computing cluster—the real burden on the CPU is not so much the request count but the computing burden that each request incurs. For example, one request getting a .JPG of a cat will incur nowhere as much burden as a request that needs to convert an audio file in .WAV format to MP3.

    The need to alleviate request burden has been around since bank tellers working in the various branches of a big bank had to make deposits and withdrawals at the same time. Mainframe engineers addressed the problem decades ago. Technologies such as batch processing and message queues, which make computational activity asynchronous and are optimized to fully utilize CPU capacity efficiently, were and are commonplace in the mainframe landscape.

    IBM’s 360 mainframes supported batch processing in its OS/360 system starting in 1964. Batch processing allows thousands of instructions to be performed on terabytes of data at pre-scheduled times (usually “off-hours”), all without human intervention.

    Message queuing allows processes to take data in the form of a message stored in a message queue and perform computational activity according to the data in the message. Processing is performed independent of a request in an asynchronous manner. When processing is complete, a new message is created and sent on to another queue, where another process will do more processing or create a notification indicating that work is complete. IBM MQSeries was an early message-queuing technology first used in 1993 at State Street Bank well before the internet became commonplace.

    The reason that support for user and transactional concurrency was possible in mainframes is due to a technology that is commonplace in today’s cloud environment but was unheard of among PC users back in the days when most data was exchanged between standalone PCs using floppy disks. That technology is virtualization.

    Virtualization Takes Mainframe Computing to the Next Level

    Today we take virtualization—the capability to have software simulate hardware—for granted. Without it, we couldn’t have native cloud providers such as Amazon Web Services, Google Cloud and Microsoft Azure. These services rely on virtualization to provide the segmentation and computational isolation required to meet the needs of the modern computing. Yet, as essential as virtualization is in the world of commodity cloud computing, putting a layer of virtual machines on a commodity PC is a fairly recent event in the history of computing. VMWare, VirtualBox and KVM became mainstream in the mid-2000s. On the other hand, virtualization has been part of mainframe technologies since the mid-1960s. Virtual memory appeared in the mainframe in 1965. Machine virtualization was introduced on the IBM 370 mainframe in 1972 and is still an important part of the mainframe computing experience today.

    Every single person who logs onto the mainframe when working in a native mainframe operating system gets an identical address space. You can think of each address space as a standalone virtual mainframe system. These address spaces are created instantly and are protected from interfering with each other. Also, many companies create logical partitions of their hardware called LPARs (logical partitions). The logical partitions are controlled by a native firmware hypervisor called PR/SM (pronounced Prism).

    The value that LPARS provide is a further separation between environments. This means not only can you separate users, but you can also create distinct computing environments such as those created when virtualizing X86 machines. For example, you can have a shared development environment as well as environments for testing, staging and production. You can allocate resources and security access to a particular environment based on need, just like you would in a data center full of commodity machines. This means you can configure production systems to be more secure and have higher execution priority and more resources such as memory. In fact, according to the U.S. government, from a security perspective, virtual machines created on the mainframe are considered distinctly separate machines.

    LPARs running on the same hardware or different hardware under the native mainframe z/OS operating system can be linked together as a Sysplex for redundancy and to easily provide additional capacity. Dynamic Virtual IP Addressing (DVIPA) is used to dynamically route IP traffic across multiple LPARs in a Sysplex. This is analogous to being able to tie together a variety of web servers behind a load balancer or organize them within a Kubernetes cluster. Being able to tie computers together is an important feature for making systems scalable. Also, linking computers across geographic regions increases performance. It’s always faster to work with a machine that’s closer to you than one that’s further away. As mentioned earlier, being able to scale systems up and down is a key feature of cloud-based computing. Dynamic connection, which is part of mainframe architecture, is critical for scaling to work.

    The important thing to understand is that the stuff we consider to be modern in terms of the machine virtualization that we rely upon to make the cloud work has been in play for years on the mainframe. Also, virtualization on the mainframe makes it possible for programmers and system administration staff to work in a variety of operating systems and programming languages as we’ve come to expect in commodity cloud instances. Machine virtualization allows mainframes to support Linux. Whether the computing environment is virtualized Linux or native mainframe, developers can code in Java, C/C++, Python, Perl and a variety of other languages, including something as new as Swift. But, then again, the mainframe was always intended to support many programming languages.

    Even back in the ’60s and ’70s, programmers could write in COBOL, PL/I, job control language (JCL) and Customer Information Control System (CICS). Also, writing low-level code in Assembler has always been possible. Clearly, the versatility that modern developers enjoy programming in a variety of languages in a cloud environment has been part of mainframe computing for a while. Yet, the benefit has never been at the forefront of developer awareness. Maybe it’s time to change the narrative.

    Changing the Narrative About Mainframe Computing in the Cloud

    As I stated at the beginning of this article, IBM continues to make mainframes because there’s a growing demand for the technology—particularly as smartphones and IoT devices proliferate worldwide. Netflix might be spinning up containers on a commodity machine in a data center to let you view past episodes of “Orange is The New Black.” But when it comes time to pay for your Lyft ride using your iPhone, that credit card transaction will most likely be processed on a mainframe that’s providing service via some sort of API gateway.

    There is little benefit to arguing that mainframes should or can be used interchangeably with commodity servers. That’s like saying a fleet of automobiles can be used interchangeably with a city bus. You can do it, but it doesn’t make much sense. Each technology has benefits that when used together, make the overall transportation system more efficient. The trick is to understand where and how the technologies fit together in the big picture. In this case, the big picture is the cloud.

    The old narrative around mainframe technology is based on perceptions that are no longer applicable. The modern mainframe is no more centralized than the single building that houses a regional data center. In terms of programming languages, mainframes moved beyond FORTRAN and COBOL decades ago. Current mainframe virtualization technology makes it possible to run programs written in just about any programming language. And, mainframe emulators, such as ZD&T, make it possible to get the hands-on experience necessary to get familiar working in a mainframe environment.

    The Perceptions of the Past are No Longer Applicable

    The modern mainframe is a powerful resource that provides extraordinary benefits for cloud computing. The new narrative is that the mainframe is modern, adaptable and well-suited to accommodate a very high volume of transactions at lightning-fast speeds. And, it’s a good way to make good money.

    As the current workforce (which is admittedly aging) approaches retirement, a new breed of mainframe developer will be needed to continue the work of making the mainframe a mission-critical resource in the modern cloud. In addition to understanding the essentials of mainframe computing, these developers will need to be well-versed with the modern tools and techniques that drive cloud computing. It’s an investment that I’ve urged many up-and-coming developers to make.

    Putting It All Together

    Let me share a piece of personal history: A while back I needed to do some programming. So, I went to my desk, logged into my system, wrote some code and ran it. It worked like a charm! I saved my work, finishing up just in time for dinner. A while later, it was again time to program. I went back to my desk, logged into the system and coded away. Just another day of slinging the code, right? Well, not really.

    My first coding session was in 1975. “A while later” is today. Forty-four years have passed. Back then, I was working on a mainframe that was 50 miles away. Today, I logged into an online programming environment that was also miles away, maybe even halfway around the world. That’s how it is with cloud computing: The resources are any way at any time.

    Interestingly, despite the passage of a significant amount of time, my current developer experience is not that different than the one I had decades ago. It’s still just me and a terminal. Back then, the terminal was a screen full of green characters. Today, my terminal is able to accommodate a variety of media and input devices. But, at the other end of the wire, who knows what’s going on? For all I know, I might still be connecting to the same mainframe I used back in 1975. Which is my point.

    Much of what we consider new and wonderful about cloud computing today has actually been around for a while in mainframe technology. In many ways, the mainframe was the cloud before the cloud. And, it’s still a powerful resource for what we have come to know as modern cloud computing. Given its power, versatility, scalability and support for modern DevOps tooling, the mainframe is a perfect resource for today’s and tomorrow’s cloud computing infrastructure. It’s a computing resource that we’ll do well to take advantage of as we move forward in our development efforts on an increasingly connected planet.

    — Bob Reselman

  • How Mainframes Live On

    How Mainframes Live On

    TL/DR: Highly controlled change is sometimes the best answer.

    For much of my career, I’ve worked in mainframe shops. I have never worked on a mainframe team, but I have worked closely with them. I’m in Northeast Wisconsin, and at one point we had the highest per-capita number of mainframes in the world, so pretty much anyone from this area can say the same. They were the “stable core” of the system for which I was the “new shiny”—and at times, that was painful.

    If you’re an established enterprise, even after years of trying to eliminate the mainframe, you probably still have one. They don’t go away so easily because, despite frustrations with rate of change, they do host core systems in established organizations and are reliable. I have seen similar in client server systems that are core to the business.

    We are reaching a point where there are some great products out there to help modernize the mainframe and/or split up client/server applications. Some of them have been around a while (Linux) and are coming into wider adoption, some of them are building on that bit of more familiar interface and many are simply making the UI more familiar to developers like me that only ever developed in a mainframe terminal for college, if at all.

    One of the main reasons why mainframes and future iteration’s applications are “sticky” is because they, and the systems they host, are generally reliable. No matter what you think of the timeline for updates, the data coming out of the mainframe and more controlled distributed applications is considered accurate in most organizations, over most other sources.

    To be clear, there are groups like this from each successive wave of computing. The client/server app that replaced your mainframe customer information system has learned over time that a fault in their system impacts the core of the business, for example.

    The goal is to increase the rate of change, without undermining the reliability. You hear a lot about throw-away instances and “fail fast,” but dropping your billing system isn’t really an option, so these need to be tempered with the knowledge of what failure implies in core systems.

    Make the change, do the modernization, but listen to lessons learned on core systems. Take into account that your informational website being down is a serious problem for marketing, but the billing system being down is a disaster for the company. There is a degree of difference, and the approach should be less about continuous deployment and more about stable deployment. Yes, it can be a scale, and you can start the motion from one to the other slowly to make sure you’re covering your bases.

    In short, assess the risk levels of these systems before deciding how to proceed. This is pretty much common-sense advice—but better to read it and not need it, than to find out when corporate revenues are impacted.

    I worked at one shop where a certain core application was using technology that was a couple of generations old and no longer supported. The pool of available developers was shrinking, but it was an important application. This type of thing is where modernization is critical; having someone say, “We don’t touch that,” is no longer acceptable. That story ends in disaster when the system fails, and no one knows how to troubleshoot—let alone fix—it.

    As with so many things, the balancing act is up to you; determine your organization’s level of risk acceptance, then determine the impacts of this application being unavailable and proceed from there.

    Each step of mainframe development is a little different from what developers coming out of college expect, but there are new tools and mechanisms available of which these developers can take advantage.

    — Don Macvittie

  • IBM Adds Automated Testing Tool for Mainframe to DevOps Portfolio

    IBM Adds Automated Testing Tool for Mainframe to DevOps Portfolio

    IBM has added an automated testing tool to the portfolio of DevOps tools it has developed for mainframes.

    Sanjay Chandru, director of Z DevOps for IBM, said IBM Z Open Unit Test adds a continuous testing capability to the continuous integration/continuous development (CI/CD) platform based on an instance of an open source Git repository developed by Rocket Software that IBM launched last year. The automated unit testing tool automatically records and plays back test data for both batch-oriented applications written in COBOL or PL/I and CICS transaction processing applications.

    Chandru said IBM Z Open Unit Test is unique in that it eliminates the need to employ traditional debugging tools. Developers can generate test cases for COBOL CICS programs, as well as “stub out” CICS to achieving environment independence from CICS runtime during test case execution. A stub is an object that holds predetermined data, which is provided in response to calls made during tests. That approach eliminates the need to have objects that answer with real data. That means Z Open Unit Test operates without adding the overhead of a debugging tool, said Chandru.

    Any test case and the resulting program created then can be stored in any source code management (SCM) system.

    IBM is making a concerted effort to make mainframe a natural deployment target for any DevOps team, said Chandru. It increasingly has become apparent that millennials in particular aren’t biased toward one platform or another, as long as each platform is equally accessible, he noted, adding that as organizations embrace best DevOps practices to modernize their application portfolio, IBM wants to make sure the mainframe remains relevant.

    IBM launched the z14 mainframe in the fourth quarter of 2017. According to the company, 92 of the world’s 100 biggest banks use its mainframes, which handle most global credit card transactions alongside billions of ATM transactions and annual passenger flight bookings. While use of mainframes overall isn’t growing, the platform isn’t going away anytime soon.

    IBM has also enhanced the cryptographic capabilities of the z14 to make it one of the most secure platforms available and continues to invest in an instance of Linux for the mainframe. That latter capability makes the mainframe a more natural target for applications being developed and deployed using DevOps processes, said Chandru.

    Of course, the biggest challenge when it comes to DevOps and mainframes is not necessarily the technology. Most mainframe applications have been developed using waterfall processes for decades. Getting those teams to embrace DevOps processes represents a significant cultural hurdle for any IT organization.

    At the same time, however, DevOps teams who ignore mainframes are not taking advantage of an existing platform investment that has performance and security capabilities that are still unmatched after more than five decades. The real challenge is finding a way for old mainframe dogs to learn some new DevOps tricks while exposing proverbial whippersnappers to the capabilities of the most powerful mainstream platform ever built.

    — Mike Vizard

  • DevOps Chat: Mainframe Attitudes with LzLabs’ Dale Vecchio

    DevOps Chat: Mainframe Attitudes with LzLabs’ Dale Vecchio

    Dale Vecchio has spent many years in the mainframe business, including 18 or so years with Gartner covering the mainframe beat. Today, he works as chief marketing officer at LzLabs, which recently conducted a survey with Microsoft on mainframe use: info.lzlabs.com/lzlabs-microsoft-…ation-survey-2018

    The results may or may not surprise you depending on your views on mainframes. It seems that a very high majority of mainframe users would like to ditch their mainframes if they could. There are some other interesting results here as well.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Happy to be joined by our guest who’s actually in London today, and he’s Dale Vecchio. Dale is with LzLabs. Dale, welcome to DevOps Chat.

    Dale Vecchio: Thanks, Alan. Great to talk to ya.

    Shimel: Great to have you here. So, Dale, let’s first do a little sort of level-set. Give us a little bit of your personal background, maybe your journey, and then tie that into how you come to LzLabs and what they’re about.

    Vecchio: Sure, Alan. I’m currently the chief marketing officer at LzLabs, which was a startup company out of Switzerland designed to help customers move mainframe workload to modern x86 open-cloud environments. But, before that, I was 18 years a Gartner analyst, covering the mainframe. I probably took 10,000 inquiries over those years, to mainframe customers all over the world. And I used to joke I was the only Gartner analyst with a theme song, and it was called “Should I Say or Should I Go” by The Clash.

    Shimel: [Laughs]

    Vecchio: ‘Cause mainframe customers weren’t quite sure if they wanted to stay or they wanted to go, and I said, “Well, here’s the challenges and opportunities if you stay; here’s the challenges and opportunities if you go. You make the decision. I don’t have a dog in this fight.” But I was 18 years a mainframe software vendor. I grew up as a mainframe application developer and assembler, Citrix programmer, the whole nine yards, so I’ve been dealing with this platform, on one way or the other, for four decades.

    Shimel: Yeah. You know, Dale, it’s funny; you get to a certain age, not that I’m saying you’re old, but I am, and you get to a certain age and you’re surprised how many people that you’ve dealt with, that you run into, who, actually, their root’s in IT, where “I was a mainframe developer. I was writing code on mainframes back in ’70s, ’80s, even ’90s,” and that’s very different, of course, than generations past, people who’ve come into the workplace since 2000, let’s say, or whatever.

    So, Dale, you have that historical perspective. Look, there’re people who – and, like you said, you have a dog in the race. I’m in the same boat. Right? We get cutting-edge DevOps, Agile people who say, “If it’s not on the cloud and SaaS, it just can’t keep up to today’s pace,” and then I run into a lot of people whose businesses still run on mainframe. You guys actually did a survey – I think it was in conjunction or in partnership with Microsoft?

    Vecchio: Correct.

    Shimel: On kinda people’s attitudes towards their mainframe, if you will.

    Vecchio: That’s right. Because I’ve always found the challenge for the mainframe, moving forward, is not a technical one. It’s a great box; I’ve always been a fan of the box and the hardware. The problem is that people have lost faith in it being the only platform in town. I mean, you can’t say, “I can’t run mission-critical workload on the cloud or in x86.” I mean, I don’t know how – how does Amazon do it? Or eBay? Or Google? Or Facebook? Or any global startup in the last 20 years hasn’t been built on a mainframe, so there are technical options. But the disciples of the mainframe – as you said, baby-boomers, born between 1946 and 1964 – even if an organization says, “I wanna have young developers,” your decision-makers, you database administrators, your system programmers, those guys are not young.

    Shimel: Right. They cut their teeth on ’em.

    Vecchio: And I always used to say that the biggest decider of whether customer wanted to stay on a mainframe or not was the age of the CIO ’cause, if you want an older CIO, as you said, you grew up in the world; you understand the value proposition of the box. If you’re a younger person, not so much. So that skill survey that we did, we wanted to get some objective measures from 500 senior IT leaders around the globe – “What is it you think about this platform?”

    There’s two things that came out of that that was pretty shocking. First off, almost everybody has open-source, cloud, and Agile development as key components of their IT strategy, moving forward. Now does that say the mainframe can’t participate in those? No. Is it where you’re mostly likely to find those things? Probably not. So that’s the first part. The second part was 94 percent of the respondents said they would consider getting off the mainframe, number one, which is a shocking number to me.

    Shimel: Yeah.

    Vecchio: I didn’t say they will. Said they were –

    Shimel: No, no.

    Vecchio: Which, 10 years ago, you wouldn’t have got that kind of number. But I think the one that was more surprising to us was that half of the mainframe companies that we surveyed have lost faith because IBM is more focused on the cloud and Watson. And they not even sure that the keeper of the flame is as focused on that platform as, say, Compuware, who is 100-percent focused on that. I mean, they have a great DevOps story.

    Shimel: Yep. Well, look, all of the mainframe people have developed a DevOps story, right, Dale? Whether it’s IBM – as you said, the keeper of the flame – or the Compuwares, the CAs, and there’s a few others we’ve dealt with that are mainframe vendors and stuff. Here’s how I kinda – couple of things. First of all, that 50-percent number on people’s perception about IBM’s focus on the mainframe? I get it. You know, I go to IBM Think every year. It’s this huge – it’s in Moscone this year and it’s a huge floor. And you look at how much is dedicated to mainframe versus the shiny, new objects.

    Last year – well, it’s been Watson for a few years, but, this past year, it was the – not “cognitive.” What’s the new computers? It was like a copper machine – eh, whatever. I forgot the name of – it’ll come to me, I’m sure, while we’re talking. But, anyway. But, yet, when you look at the bottom line, when you look at the revenue – and I’m not a stock pundit and I’m not here giving anyone investment advice, right?

    Vecchio: Nor I. Nor I.

    Shimel: Their revenue still comes, way, way, way more than they would like to really tell, comes from mainframe.

    Vecchio: Well, their profit does. Their profit does.

    Shimel: Their profit. Yeah.

    Vecchio: Yeah. That’s for sure. I mean, this is a challenge for anyone with a mainframe. It’s not a bad box. You’re faced with the challenges of skills decline. Most of the, if not all of the, vendors in the space are very focused on maintenance revenue. And why would anybody buy Rocket or CA, why would an investor look at that, unless they were managing the maintenance revenue streams? So that doesn’t bode well. This is not about whether that box is any good; it’s the dynamics of the market are working against it.

    Shimel: I get it. Yeah, by the way, it was “quantum computing.”

    Vecchio: Ah.

    Shimel: That was brought up _____ _____ _____.

    Vecchio: Oh, yeah, quantum computing. Yeah.

    Shimel: Yeah. That was definitely the shiny bullet at last year’s Think. And you’re right. Look, you got Chris O’Malley at Compuware and he’s all mainframe and he’s not shy about it either. CA – a lot of people are saying the whole reason Broadcom bought CA was for mainframe – I don’t know if I buy that either.

    Vecchio: Well, for mainframe revenue.

    Shimel: Yeah.

    Vecchio: For mainframe –

    Shimel: Well, more for using the mainframe customer base to go sell routers and switches, which I’m not – we’ll talk about that offline. But let’s stick to the survey. So, yeah, I can understand the 50 percent. It doesn’t jive, of course, with IBM’s profits, but here’s my kind of basic nitty-gritty on this issue, Dale, is, yeah, we’d all – look, I’d like to get a different car. I’d like to do something different. The problem is that trillions – and it is literally trillions of dollars that have been sunk into mainframe. I don’t know how many organizations can just afford to walk away from that.

    Vecchio: Well, this is sorta the challenge, when you talk about this, is it becomes a very black-or-white conversation. People talk, “Oh, you’re saying the mainframe is dead?” No, we’re not saying the mainframe is dead. All we’re talking about is mainframe’s getting marginalized to the high end of workload. If you went back 20, 30 years ago, there were 30,000 or 40,000 mainframes. Now there’s maybe 3,000 or 4,000 mainframes. Well, sure, they’re much bigger than they were, so there’s been some consolidation, but, even in the number of customers, there are fewer.

    One of the things that I always found, the time I was at Gartner and even out of what these survey numbers tell me, is they want to get off. They want to. They don’t because they’re not sure they want the risk, number one, and, number two, they don’t have to ’cause they still have the people. But, as those – every single one of them in that survey, 85 percent of ’em, said, “Yeah, we have got a problem.”

    So you’re either gonna fix the problem or you’re not, and that gets us to the whole conversation about DevOps – just “Can I bring my hammer to the mountain or the mountain to my hammer?” Can I bring all of that DevOps, Agile mindset to a platform where the culture is a 180 degrees from that? You know, all of the things on a mainframe were designed for security, reliability, availability; they weren’t there for speed. There’s not all the automated testing. People don’t understand these applications and what they do. You know, we used to joke, “These aren’t legacy systems; they’re leprosy systems,” ’cause nobody wanted to touch ’em ’cause they might lose a body part.

    So how are you gonna do Agile and DevOps in that environment? So is it technically possible? Absolutely. Does Compuware have a compelling story? Absolutely. Have they convinced enough that you believe that the future of the mainframe is bright or it’s gonna continue to decline? I –

    Shimel: I don’t know. I mean, I guess time will tell us that. I’ve often thought, “Why can’t you duplicate the resiliency, the power, if you will, of the mainframe?”

    Vecchio: Ah, that’s a great question, Alan. Because part of – the mainframe was very much a scale-up world. You know, if you wanted more processing power, you added more MIPS. One single operating system, unified database, transaction monitors, et cetera. It is absolutely 100-percent unique _____ _____. Everything else is scale-out.

    Shimel: Mm-hmm.

    Vecchio: Like, “How could I take a scale-up environment and move it to scale-out?” And that’s what we’ve tried to do with our software-defined mainframe, is to give someone the ability to move an application without recompiling it, without changing the data, down to an environment that now will do scale-out. So just take full advantage of Linux, of OpenStack, of cloud-deployment models, take that exact same application and now I can run it in a scale-out world. That’s only the first step because you’re gonna wanna maintain it and then you’re gonna wanna transition to modern languages. But it’s a lot easier to take advantage of the innovation and community of open-source off the mainframe than it is on, you know?

    Shimel: Yeah.

    Vecchio: Sure, IBM has Linux on the mainframe. Sure. But you tell me where the community and innovation is going. Right? It’s going to cloud; it’s going to x86; it’s going everywhere else.

    Shimel: You know what? It’s going – well, look, you could run containers and stuff on mainframe, but, look, when I’m talking to startups and even enterprises now, Dale, who are “high-performing IT organizations,” let’s call them, right? They’re not Google and they’re not Facebook, but they’re not necessarily iron miners or something, right?

    Vecchio: Yeah, okay.

    Shimel: They’re talking about things like Kubernetes and serverless and microservices, and I’m not saying that you couldn’t run these on a mainframe. I’m just saying I don’t think – I don’t know if it’s the right tool for the job. You know, one thing I learned as I grew up: I was never a handy guy, Dale, right, but tools make the man. Right? And –

    Vecchio: Yeah.

    Shimel: You know what I’m saying? And so I –

    Vecchio: Tools are your – Alan, you’re 100-percent right. And this idea of bringing DevOps to the mainframe, which is Compuware’s story, depends on two things. First, you have to have the tooling, as you said, to make that happen, but much, much harder. And I even read some of the posts up on devopsy.kinsta.cloud about this – the culture is the challenge.

    Shimel: Yeah.

    Vecchio: So you can’t just try and take the culture and bring the tools into that world and expect it to take. It’s not gonna do it. Now – so we’re sorta the other way around. We’re saying, “Bring that workload to the world where DevOps readily – ”

    Shimel: That culture exists. Right.

    Vecchio: Right? Now are you gonna keep running those applications? No, but, to your point, they’re not so easy to change, in a big way. But, if I can get out of the complexities of the operational environment – ’cause DevOps is a combination of operations and Agile development, as you all understand – sure, I can do the Agile development; how do I deal with the operational side of that? How do I do all of the automation that’s required? How can I take a fix – can you imagine trying to roll out one-tenth of the fixes that Amazon does in a day, on a mainframe.

    Shimel: Nah.

    Vecchio: Very, very difficult to do.

    Shimel: Yeah.

    Vecchio: And I would ask you, any large customer that you speak to, if you said to them, “If you had to do it all over again right now, would you build it on the mainframe?” And I’ll bet ya seven out of ten would say, “No.” So the challenge for mainframers is it’s hard to get off, but the challenges of staying are not free either. So, to me, bringing DevOps and Agile to the mainframe is 100-percent reasonable, intelligent story. I haven’t seen it be successful. And I think the dynamics of the workforce are in play.

    Shimel: Yep. So, Dale, we don’t have a lot of time, but I wanna ask you, so I’m not as familiar with your company; this is our first conversation. I’d love to see some case studies of companies who have sorta migrated to software-as-a-mainframe kind of thing and see what their experience has been, and so forth. How _____ _____ _____ –

    Vecchio: Yeah. Well, that’s –

    Shimel: How long are you guys offering this?

    Vecchio: That’s just a perfectly reasonable thing to do and I’ll see, when we’re offline, if we can’t make that happen. There’s two parts to this whole conversation of moving mainframe workload. One is the infrastructure side, the operational side, and the second one is the applications, running the application technology itself. And our solution is designed to allow you to move the applications and get rid of the infrastructure side and take full advantage of a Linux, VM, OpenStack, OpenShift container world in order to do that. That’s the first part of the conversation. There is not many people that we speak to who aren’t intrigued by the notion of cloud.

    Shimel: Sure.

    Vecchio: Whether it’s public or private.

    Shimel: Mm-hmm.

    Vecchio: Once you say that, what you’re saying is “I want to be in an Agile, scale-out world.”

    Shimel: Yeah.

    Vecchio: Now the problem is so few of the vendors left in the mainframe world are actually innovating. And I assert Compuware’s one of ’em, but, for the most part, they seem to be more interested in managing a maintenance revenue stream. That’s not really conducive for what we’re trying to accomplish.

    Shimel: Understood. You know what, Dale? We’re gonna need to continue this conversation ’cause we’re about out of time, but let’s do that. Fascinating stuff. And you know what? People make fun of mainframes and say, “Boring,” but this really is fascinating stuff, right? And it’s real-world ’cause there’s still a lot of stuff running on those mainframes.

    Vecchio: Nobody wants to get off because it’s a bad box. ‘Cause it’s not. I mean, it’s an incredible piece of engineering. No question –

    Shimel: Yeah, it really is. It’s still a _____ _____.

    Vecchio: Also, it’s hard to get out.

    Shimel: All right. Dale Vecchio – was it CMO or VP marketing?

    Vecchio: CMO.

    Shimel: CMO at LzLabs. Thanks for being our guest on DevOps Chat today. Good luck and we’ll be speaking to you soon.

    Vecchio: My pleasure, Alan.

    Shimel: All righty.

    — Alan Shimel

  • Mainframes and DevOps: The Odd Couple of Digital Transformation

    Mainframes and DevOps: The Odd Couple of Digital Transformation

    I am still surprised when I go to industry conferences and I hear people talking about the imminent demise of the mainframe. More common and equally wrong is how mainframes don’t work in today’s agile/DevOps/cloud/container world. The fact is, with trillions of dollars invested in our mainframes and more every day, the mainframe is not going extinct anytime soon. Equally factual is mainframes and DevOps can work well together.

    They may seem incompatible at first blush, but mainframes and DevOps work. We have written more than several articles on mainframes and DevOps. Our own Don MacVittie has written two excellent ebooks on mainframes and DevOps: “DevOps-ing the Mainframe” and “Automation: Modernizing the Mainframe for DevOps.” There is also a series of DevOps Chats on this subject. This one, with Rosalind Radcliffe of IBM’s Enterprise Systems, is a good one.

    Now, we would like to hear from you. What do you think regarding mainframes and DevOps? Working with our friends at CA Technologies’ mainframe business unit, we are conducting a mini-survey (just 10 questions) on mainframe use. It is embedded below this paragraph. You taking a few minutes to answer will help us better understand what is happening with mainframes and DevOps.

    The Mini-Survey

    Create your own user feedback survey

    If the survey embed didn’t work for you, you can also answer the 10 questions right here.

    If you’ve reached here because you took the survey, thanks very much. If you didn’t, please take a moment and do so. The survey doesn’t ask for any contact info and we promise you won’t receive any spam email or calls.

    Still would rather not answer the survey? OK, at least have a look at the ebooks listed above or listen to the chats. But, if you really think mainframes are going away or you have an opinion on mainframes and DevOps in general, you can write me at editor@devops.com. I would be happy to hear about it. Perhaps you want to write an article about your views? That is fine, too—write me.

    In the meantime, next time you are at a tech conference and the issue of mainframes and DevOps comes up, don’t spread fake news. The mainframe is alive and well. More of our financial, health and other transactions as well as systems of record go through them than ever before.

    — Alan Shimel

  • Open Mainframe Project Launches Zowe to Advance DevOps

    Open Mainframe Project Launches Zowe to Advance DevOps

    The Open Mainframe Project has launched Zowe, an effort to make mainframes running z/OS both more accessible and programmable using REST application programming interfaces (APIs).

    Announced at the Open Source Summit, the Zowe project is being led by IBM, CA Technologies and Rocket Software.

    Matt Hogstrom, chief architect for z/OS Systems at IBM, said the goal of the Zowe project is to attract a new generation of IT administrators to the mainframe platforms and make it simpler to include mainframes within the larger scope of an integrated set of DevOps process spanning multiple platforms.

    In addition, IBM, CA Technologies and Rocket Software collectively are trying to create an ecosystem around the mainframe that resembles more of the types of interactions that occur between companies that participate in the Linux community, Hogstrom said. The Open Mainframe Project operates under the auspices of the Linux Foundation.

    Now that IBM mainframes are more than 50 years old, IBM and its allies are increasingly relying on open source tools to make sure mainframes stay relevant for another 50 years, he said.

    To achieve that goal, Zowe provides access to an extensible z/OS framework that provides new APIs and z/OS REST services. The Open Mainframe Project, as part of Zowe, has also created a unifying workspace based on a desktop app container accessed via a browser and a scriptable command line interface (CLI) that makes it easier to integrate z/OS into cloud and distributed environments using a set of low-code tools.

    Greg Lotko, General Manager for Mainframe at CA Technologies, said the contributions to the Zowe Project made by CA Technologies are based on CA Brightside, a set of DevOps tools developed specifically for mainframe environments.

    The biggest challenge the mainframe community now faces is a dwindling pool of talent. Most college graduates today have limited exposure to mainframes at a time when many of the IT professionals who do have mainframe skills are retiring. In the absence of skills to manage mainframes, IT organizations wind up making decisions regarding where to put workloads based on the availability of expertise available to run those platforms. IBM, CA Technologies and Rocket Software all have a vested interest in leveraging DevOps tools and processes to eliminate the silo that currently exists between mainframes and other platforms by making it easier to call services residing on a mainframe using REST APIs, while at the same time making it easier to manage mainframes within the context of a common set of DevOps processes spanning multiple platforms.

    Mainframes, of course, are still comparatively expensive platforms to acquire. IBM has sharply reduced the cost of mainframes over the years. But the primary economic value proposition of mainframes is that the total cost of operating a mainframe is less than a distributing computing environment running a comparable set of workloads. Mainframes are highly automated, so IT organizations that can afford the cost of entry tend to still favor mainframes for complex transaction processing and analytics applications. The challenge—and opportunity—for mainframe shops now is in turning those applications into a set of reusable services that can be readily invoked from anywhere in the enterprise.

    — Mike Vizard

  • Implementing DevSecOps in the Mainframe-Driven Enterprise

    Implementing DevSecOps in the Mainframe-Driven Enterprise

    DevSecOps is emerging as an important trend in corporate IT. It makes sense. With each passing day more applications serve a larger user base. Whereas in the past the typical business application was accessible only from within the confines of an enterprise’s internal network, today, the software-as-a-service (SaaS) paradigm enables millions of users work with a single application.

    In the SaaS paradigm, a single application will service a number of companies and give each user in the company access to data and functionality based on a given company’s subscription plan. Take Saleforce.com for example: There is but one Salesforce.com providing service to thousands of companies worldwide, each with one to thousands of employees. Each company and each employee within a company will have particular access rights to the application. A paradigm in which there is one application servicing millions, perhaps billions of users requires a comprehensive approach to security. The slightest breach can result in havoc. Imagine what would happen if a SaaS application contained a flaw that allowed a company to see the financial data of its competitor that also subscribed to the SaaS.

    Given that the internet is the de facto network for all worldwide, today’s security concerns go way beyond restricting network access. Keeping bad actors away is becoming more difficult all the time. The sad fact is that a seemingly good actor can turn into a bad actor instantly and wreak havoc not only on the servers with the network—as is the case of a DDos attack—but on the application layer as well. In fact, according to IBM, an enterprise’s network layer is half as vulnerable as the application layer, yet more money gets spent protecting the network.

    This is an eye-opening fact and one not on the minds of most application developers. But, it might be, if developers had the benefit of the expertise and ongoing guidance required to implement bulletproof security at the application level.

    Which leads us to the mainframe.

    In today’s world of modern, web-based cloud computing, the mainframe is a major player. Seventy percent of corporate data lives on a mainframe. Also, now that the Linux operating system is pervasive in the mainframe environment, enterprise-level application developers can—and do—write Java, Python and NodeJS code for the Big Iron just as they do for X86 commodity environments. Technologies such as IBM’s z/OS Connect EE and StrongLoop make it possible to use an industry-standard specification such as OpenAPI to expose mainframe services as REST API without a lot of low-level fiddling around.

    This is good news.

    The bad news that application developers are just not that adept at security best practices. They don’t have the experience of a CISSP professional who has spent years, if not decades, in the trenches battling the bad guys in cyberspace. But that was then and this is now. Today we have DevSecOps.

    DevSecOps is the next generation of IT transformation. The goal of DevOps is to create an IT culture that is unified, automated and self-correcting. DevOps combines development and operations into a single organization focused on creating and deploying quality software at ever-increasing rates. DevSecOps adds security into the mix. The scope of DevSecOps activity is not confined to software development for commodity-based X86 servers and mobile devices. DevSecOps is intended to apply across all facets of the enterprise, from mobile to mainframe.

    DevSecOps is about a lot of things. It’s about the adoption of tools such as IBM’s AppScan, a tool that allows an enterprise to implement and monitor a variety of tests (web, mobile, dynamic, static and interactive) in a unified dashboard. It can include leveraging Secure Service Containers to ensure external security and safety from insider threats.

    DevSecOps is about putting in place a set of policies, along with appropriate operational checks and balances, that ensure that the enterprise follows security best practices at all times. It’s about following practices that go beyond episodic security testing. This means continuously analyzing the IT infrastructure to identify vulnerabilities as well as defining ways to mitigate risks and prioritize prevention activities accordingly. It means making compliance to regulations such as GDPR, PCI-DSS, PA-DSS, ISO 27001 and ISO 27002, HIPAA, GLBA and Basel III  an enterprise-wide responsibility, not just something that’s siloed away to the Compliance Department.

    DevSecOps is about acting proactively by using automation to rigorously inspect all code to uncover potential hazards. It means using HTTPS as the default protocol for public-facing URLs. It means making sure that all third-party components are built from source code when possible—and, if building against source is not possible, ensuring third-party components and libraries are certified safe by an accepted authority.

    DevSecOps is about a lot of things, but there is one principle that overrides all others:

    When it comes to DevSecOps, the most important principle to follow is to make sure that a security expert is a starting member of any team involved with making software for the enterprise.

    It doesn’t matter if the company is 30 years old running on a mainframe or 30 days old using native cloud services, there must be security experts as part of its development work from the start.

    This may sound obvious, but it’s easier said than done.

    It’s not a new challenge. It took the enterprise a long time to get QA personnel involved at the start of development process. Before the DevOps/Agile sensibility took hold, QA personnel showed up at the end of the release cycle, well after code was hardened.

    The same is true of release personnel. Before DevOps, release management was given some code and told to just get it out as soon as possible. There was limited knowledge as to what the code was about or the potential impact it might have on the infrastructure. As a result, weekends were spent in war rooms struggling to deploy code that was sparsely documented and mysteriously tested. You can bet that once release management showed up at the first project planning meeting, things changed.

    Now, with the emergence of DevSecOps, it is security’s turn in the tumbler. Security has always been an important part of enterprise IT. The number of compliance regulations on the books attest to the fact. However, security was usually the responsibility of the Compliance Department more than part of the IT organization overall. For many companies, the only time security ever came to the forefront was during audit time. As a result, security practices were more reactive than proactive. And, for many companies, they still are—think back to reactions to the Equifax and Target breaches.

    However, the success of DevOps has not gone unnoticed. The standard features of DevOps—unifying groups toward a common purpose, implementing automation whenever possible and using sprints and retrospectives to facilitate fast releases and address shortcomings quickly—has had positive results. Forward-thinking companies understand that DevOps works, and its successor, DevSecOps, will work provided the essential principle is followed: Make sure security experts have a seat at the table from the beginning.

    For many companies this means transforming from a culture of isolated silos in which managers serve as gatekeepers and powerbrokers to one of unified open groups in which a manager’s job is to assemble self-directing groups and to make sure that all the right people are involved from the beginning of a project. It’s a fundamentally different way of doing business.

    When it comes to realizing the promise of DevSecOps, tools are important. So are processes. But, the most important thing is to make sure that security is built into the fabric of the development life cycle, from start to release.

    DevSecOps will fill the missing link in the software development chain. It has to. There is little choice otherwise. Adhering to the most important principle of DevSecOps—to have security involved as an equal player from the beginning of the process—will go a long way toward ensuring that all software, from mobile and IoT to native cloud installations and mainframe instances, will provide the degree of safety and reliability required to serve the needs of users and companies in the digital economy of the modern world responsibly.

    — Bob Reselman

  • Compuware Extends DevOps Push for Mainframes

    Compuware Extends DevOps Push for Mainframes

    Compuware has advanced its campaign to erase the DevOps divide between mainframes and distributed systems via an update to Topaz for Enterprise Data that makes it easier to generate data from mainframe applications for testing purposes without compromising the security of some of the most sensitive data in the enterprise.

    Company CEO Chris O’Malley said Topaz for Enterprise Data now includes a data masking capability that preserves essential data relationships and characteristics without letting developers see the data being copied.

    Designed to be compatible with Eclipse integrated development environments (IDEs), Topaz for Enterprise Data also automates the extract, transform and load (ETL) process by enabling developers to convert file types.

    O’Malley noted that, at a time when compliance regulations such as the European Union’s General Data Protection Rule (GDPR) are becoming more stringent, it has become more important for organizations to be able to demonstrate that personally identifiable information (PII) has not been exposed during any point in the application development cycle. That’s especially important when it comes to mainframe data, which typically is used to drive transaction processing applications.

    In general, O’Malley said the historic divide between mainframes and distributed systems is narrowing as organizations embrace DevOps processes. Instead of proponents of these platforms battling within organizations for control over specific classes of workloads, there’s more awareness of the need to leverage both platforms to drive a new generation of digital business applications, O’Malley said.

    The challenge is that most mainframe applications are built and updated using waterfall methodologies. Compuware has been developing a series of DevOps tools for mainframe environments that are intended to modernize those processes. As the IT organizations that have mainframes adopt those tools, it becomes easier to federate application development and deployment across mainframes and distributed systems, O’Malley said.

    Of course, this all assumes various teams within the IT organization can lay aside historic animosities. The shift to DevOps has always required as much process and cultural change as it does new technologies. But in the case of IT organizations that have mainframe teams, that shift may take years. The good news is a that a new generation of IT professionals doesn’t have much history with infighting within internal IT organizations. The simple fact is there are classes of workloads that run better on mainframes, O’Malley noted, but that doesn’t mean every workload running on mainframe is ideally suited for that platform—or conversely, that every workload running on a distributed system is ideally suited for that platform.

    Arguably, the rise of DevOps processes might create an opportunity to revisit many platform decisions that were made in the heat of a larger argument. In the meantime, it’s clear that applications integration spanning multiple platforms is the new order of the day. The question now is how best to go about achieving that goal in a way that erases the divide existing between all the platforms that now make up the extended enterprise.

    — Mike Vizard

  • A Unified Route to Bring Mainframes to DevOps Speed

    A Unified Route to Bring Mainframes to DevOps Speed

    Most businesses have mainframes where their key applications and data reside. In today’s digital environment, customer-facing mobile and web systems retrieve critical data from back-end mainframe systems. It is critical to adapt mainframe applications and data to today’s rapidly changing market demands if businesses want to remain competitive.

    This is the question IT and businesses are facing today. How can they integrate their well-established mainframe environments and have a unified cross-platform across the enterprise for DevOps to manage releases across mainframe and non-mainframe applications?

    An Innovative Digital Solution

    The answer lies in mainframe digital DevOps. This helps enterprises remain competitive in an app-centric economy. Through a unified cross platform, DevOps is integrating mainframe tools with open source DevOps tools.

    This approach allows organizations to retain their legacy code and does not require legacy code migration—especially when the back-end core applications are on mainframe. As veteran COBOL programmers retire out of the skill orbit, this becomes even more important. There is an imperative and an expectation for agility and higher productivity from IT—without jeopardizing performance, customer experience, security and other compliance factors.

    Transforming the Developer Environment

    Most mainframe development, test and ops work is executed in antique “green screen” SPF environments, which calls for specialist knowledge that limit productivity among programmers of Agile and DevOps transformation. Turnaround times of monolithic mainframe applications are painfully slow compared with the new-age agile technology of mobile and web applications. This can be frustrating for developers who wish to make frequent changes to mainframe code to fulfill the urgent needs of business.

    Therefore, it’s important to make the shift to modern tools and integrate mainframe with non-mainframe DevOps processes to deliver cross-platform services. This will improve staff productivity across development, testing and production operations and enable inexperienced mainframe professionals to perform application development and enhancements with ease and efficiency.

    Large mainframe clients embark on transformation by modernizing the workspace to work on both mainframe and non-mainframe applications. Open system developers are familiar with new-age IDEs such as Eclipse, which have user-friendly interfaces. Similarly, other mainframe tools are available that provide source code editing, debugging, fault diagnosis and browse data to enable developers to write, compile and run code from a modern Eclipse-based IDE. Developers can drag and drop files between LPARs and perform other tasks to improve productivity metrics. Collaboration between the two teams will motivate mainframe developers to use DevOps principles to integrate mainframe with distributed and cloud applications.

    Once quick wins are established, adoption levels of Agile and DevOps will improve among mainframe developers and business.

    Eliminating Barriers to Unit Testing

    Historically, mainframe developers have not been accustomed to unit testing. Automated unit testing is common in Java but not in the mainframe environment. Agile coaches, familiar with mainframe tools, will need to enable collaboration in interactively testing smaller pieces of code.

    Unit testing can improve throughput by increasing the frequent code drops in production environment and help to accomplish DevOps key performance indicators (KPIs) with fewer errors in the later stages of the software development lifecycle process. Some tools can facilitate this process by automatically breaking the mainframe code into discrete logical units, and creating tests for such logical units.

    Tracking and Monitoring Progress for High Quality

    Visualization is an important element of DevOps for improved visibility to track and monitor progress across the enterprise. As most mainframe applications and data structures are large, complex and not well-documented, enterprise IT is highly dependent on the personal and institutional knowledge of senior mainframe staff. Graphical visualization can help quickly “read” existing application logic, program interdependencies, data structures and data relationships. Business rule extraction tools are available in the market to reveal logic and data relationships through graphically intuitive diagrams. This helps developers work independently on unfamiliar programs to better estimate project work, meet delivery deadlines and commit timelines to business.

    Most mainframe applications are often associated with core business processes with zero tolerance for error. Any attempt with inadequate mainframe experience can lead to catastrophic non-recoverable error. Continuous integration (CI) is critical in determining application quality issues early and establishing KPIs to deliver continuous quality code in production. Enterprises have started embracing modern tools and techniques to transform from the Waterfall delivery model to Agile. Modern DevOps tools embrace CI, and certain tools can quickly detect application quality issues (such as unbalanced or unmatched working storage and data items, and out-of-range nested conditions and branches).

    Training for Effective Enablement

    Successful implementation of cross-platform DevOps calls for the right training on Agile tools, processes and methodologies. A single Scrum team can be formed to collaborate with developers across mobile, web and mainframe. The Agile mainframe team will need to focus on stories and epics that capture specific units of business value instead of technical tasks in a project plan. Open system tools such as JIRA and Confluence that can support Scrum and Kanban can be used to manage tasks and improve collaboration through centralized and well-organized web tools. This will incorporate Agile values such as transparency, knowledge-sharing and ideation to improve the developer’s performance.

    The move to Agile scrumming represents a transformative shift of mainframe work culture, and herein lies the importance of the right coaching in Agile processes. A “2- n a box” partnering model of mainframe developers and experienced Agile developers from other platforms can create the required collaboration.

    Operational Data Analysis to Close the ‘Last Mile’ Loop

    Good quality code alone is not enough. Operational data analysis is required to reduce costs by discovering and mitigating avoidable CPU consumption caused by code inefficiency.

    Mere monitoring and reporting by triage teams is not enough to support and maintain applications in the world of DevOps.  Production data analyses by enabling an auto-feedback loop is imperative to improve productivity of the dev, test and production teams. Tools are available that can quickly pinpoint bad statements and pinpoint application inefficiencies such as bad SQL statements. Tools also help identify the causes of excessive CPU consumption and slow data retrieval.

    Automation for Speedy Efficiency

    Agile-enabled core source code management (SCM) is a fundamental requirement of DevOps. Traditional SCM cannot support parallel development work on different user stories. SCM migration is therefore essential to increase the speed and frequency of mainframe code drops. Automating the change management process and defining the proper workflows can eliminate manual steps and reduce code approval delays.

    Again, tools are available that can fulfill business expectations by seamless SCM migration without disrupting the current work in progress.

    Automated release and deployment is pivotal to keeping pace with today’s fast-moving markets. Business needs to quickly see reliable new code in production.

    Toward a Unified IT Service Management

    Cross-platform continuous delivery is vital for efficient use of mainframe applications and their data for multiplatform customer-facing applications, including mobile, web and cloud components. Mainframe DevOps process should fully synchronize the code delivery process across all platforms. This will establish a centralized deployment control center to provide a unified cross-platform and accurately report progress. Tools can be the single point of control for all changes across z/OS, Windows, Unix and other platforms. REST APIs are flexible to mix and match best-in-class tools and avoid vendor lock-in.

    The ultimate destination is to create a de-siloed environment where mainframe is just another platform with high scalability, reliability, performance, security and cost-efficiency. A unified mainframe digital DevOps platform may be the answer to modifying traditional process that fulfills this business demand.

    — Ramesh Ganapathy