Tag: ibm

  • Integrating IBM Z and LinuxONE into the Red Hat OpenShift developer ecosystem

    By Willie Tejada, GM & Chief Developer Advocate, IBM Cognitive Applications

    https://developer.ibm.com/blogs/willie-tejada-redhat-openshift-ibmz/

    My role at IBM is to make sure that we’re equipping developers with the tools and resources you need, along with the selection and guard rails you prefer, to help you focus your efforts entirely on innovation. Security is key to unlocking the true value of the cloud, and we want that to be one less thing you have to worry about when you’re building high-performance solutions. To that end, this week we announced a major milestone furthering Kubernetes support for Linux on IBM Z and IBM LinuxONE: The Red Hat OpenShift Container Platform for Linux on IBM Z and LinuxONE is now generally available.
    Kubernetes has been available on Linux on IBM Z and LinuxONE for some time and is detailed in this LinuxONE whitepaper. This has already enabled customers to start integrating Kubernetes-based microservices running on Linux on IBM Z and LinuxONE into their infrastructures, as well as the vast ecosystem of projects surrounding Kubernetes itself.
    With this launch, developers can now access a platform with Kubernetes-based tooling, plus fast, built-in security and hardware-driven cryptography, high uptime and resiliency, fast access to your data, and everything else you’ve come to expect from Linux on IBM Z and LinuxONE. This opens the door to easier integration with existing solutions that are already using OpenShift in hybrid and multi-cloud models — whether your infrastructure resides on public or private clouds, or a combination. It’s our latest enhancement to help you truly build once, deploy anywhere.
    Additionally, the IBM z/OS Cloud Broker allows OpenShift applications to easily interact with existing data and applications on z/OS. You will be able to use the IBM Cloud Infrastructure Center, an Infrastructure-as-a-Service (IaaS) that provides simplified infrastructure management of z/VM-based Linux virtual machines on Linux on IBM Z and LinuxONE. OpenShift is a platform-as-a-service (PaaS) and container-as-a-service (CaaS) layer that requires an underlying IaaS layer, which the IBM Cloud Infrastructure Center provides for IBM Z and LinuxONE.
    OpenShift availability on the Z architecture allows for easier development of applications that work across your infrastructure. Microservices-based workloads that you develop can be managed as you see fit. Plus, with the IBM Cloud Pak for Applications, you’ll have access to a collection of tooling to help drive modernization efforts by leveraging DevOps-related tooling like IBM UrbanCode and enterprise-level support for Java, Node.js, Spring, and other runtime environments. With this release, for the first time, Red Hat Enterprise Linux CoreOS (RHCOS) is available for the Linux on IBM Z and LinuxONE platforms.
    We’re helping you build smart, and build secure.
    This release is primarily for evaluation, dev, and test, so we’re eager for you all to check it out. Get involved now to start testing your workloads in anticipation of production readiness, planned for later this year. Initially, you will need z/VM to implement OpenShift on the platform as virtual machines managed by IBM z/VM, with other options coming later. We’re also working on support for HiperSockets, SMC-D, Installer Provided Infrastructure (IPI), and persistent storage other than NFS, and you can expect support for all of these things down the line.
    I invite you to join our webinar on March 5 to learn how the agility of OpenShift, the security and scalability of IBM Z, and the containerized software of IBM Cloud Paks are enabling innovation.

  • Into the hybrid cloud future: Red Hat OpenShift is now available for IBM Z and LinuxONE

    By Ross Mauri, General Manager, IBM Z

    https://www.ibm.com/blogs/systems/red-hat-openshift-now-available-ibm-z-linuxone/

    Today we are pleased to announce that Red Hat OpenShift Container Platform is generally available for IBM Z® and IBM LinuxONE™. Red Hat is a leader in hybrid cloud and enterprise Kubernetes, with more than 1,000 customers already using Red Hat OpenShift Container Platform. With the availability of OpenShift for IBM Z and LinuxONE, the agile cloud-native world of containers and Kubernetes is now reinforced by the security features, scalability and reliability of IBM’s enterprise servers.

    “Containers are the next generation of software-defined compute that enterprises will leverage to accelerate their digital transformation initiatives,” says Gary Chen, Research Director at IDC. “IDC estimates that 71% of organizations are in the process of implementing containers and orchestration or are already using them regularly, and IDC forecasts that the worldwide container infrastructure software opportunity is growing at a 63.9% 5- year CAGR and is predicted to reach over $1.5B by 2022.”

    The availability of OpenShift for Z and LinuxONE is a major milestone for both hybrid multicloud and for enterprise computing. OpenShift supports cloud-native applications being built once and deployed anywhere – and now extends this to on-premises enterprise servers such as IBM Z and LinuxONE. This offering is the result of the collaboration between the IBM and Red Hat development teams and discussions with early adopter clients.

    Build once

    Organizations today are looking to bring business innovation to market faster and more efficiently. Containers enable applications to be packaged together with their software dependencies, and Kubernetes adds powerful tools to manage large numbers of containers and orchestrate the full application lifecycle.

    OpenShift then brings together the core open source technologies of Linux, containers and Kubernetes, adds additional open source capabilities such developer tools and a registry, and hardens, tests and optimizes the software for enterprise production use.

    Working with IBM Hybrid Cloud, we have also developed a robust roadmap for bringing the ecosystem of enterprise software to the OpenShift platform. IBM Cloud Paks containerize key IBM and open source software components to help enable faster enterprise application development and delivery.

    Today we are also announcing that IBM Cloud Pak for Applicationsis available for IBM Z and LinuxONE – supporting modernization of existing apps and building new cloud-native apps. In addition, as announced last August, it is our intention to deliver additional Cloud Paks for IBM Z and LinuxONE.

    Learn more about developing applications for OpenShift in this blog post by Chief Developer Advocate Willie Tejada.

    Deploy anywhere

    By combining the agility and portability of Red Hat OpenShift and IBM Cloud Paks with the security features, scalability and reliability of IBM Z and LinuxONE, businesses will have the tools to build new cloud-native applications while also modernizing current applications. Deploying Red Hat OpenShift and IBM Cloud Paks on IBM Z and LinuxONE reinforces key strengths and offers additional benefits:

    ·        Vertical scalability enables existing large monolithic applications to be containerized, and horizontal scalability enables support for large numbers of containers in a single IBM Z or LinuxONE system
    ·        Designed to protect data from external attacks and insider threats, with pervasive encryption and tamper-responsive protection of encryption keys1
    ·        Designed for 99.999% and more availability to meet service levels and customer expectations
    ·        Integration and co-location of cloud-native applications on the same system as the data enables faster response times than depending on network access speeds

    IBM z/OS Cloud Brokerhelps enable OpenShift applications to interact with data and applications on IBM Z. IBM z/OS Cloud Broker is the first software product to provide access to z/OS services by the broader development community.

    Customers using OpenShift on IBM Z and LinuxONE can also license IBM Cloud Infrastructure Centerto manage the underpinning cluster infrastructure. The Cloud Infrastructure Center is an infrastructure-as-a-service offering which provides simplified infrastructure management in support of z/VM based Linux virtual machines on IBM Z and LinuxONE.

    Stay tuned for more info

    To support this important release, IBM has organized a range of resources:

    ·        Two announcement webcasts, including speakers from IDC, Red Hat and IBM, on March 5 for IBM Z customers, and on March 17 for the wider Linux community
    ·        An IBM-sponsored IDC white paper: Transforming a Corporate Datacenter into a Modern Environment: Kubernetes as a Foundation for Hybrid Cloud
    ·        An IBM Systems Magazine article: Red Hat OpenShift, IBM Cloud Paks and more facilitate digital transformation

    Stay tuned for many more discussions about the enterprise hybrid multicloud with Red Hat OpenShiftand IBM Cloud Paksfor IBM Z and IBM LinuxONEat a series of events during the first half of 2020, including SHARE, Red Hat Summit, and IBM Think.

    We think this is an exciting time for both enterprise computing and hybrid multicloud as they come together with Red Hat OpenShift on IBM Z and LinuxONE.

  • IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    Big news from Big Blue yesterday: IBM CEO Ginni Rometty is stepping down after eight years at the helm. In her stead, IBM is doubling down on the cloud by appointing Arvind Krishna as CEO and member of the board. The real move to watch, though, is the appointment of Jim Whitehurst, Red Hat CEO, as president of IBM and a board member. It’s the first time that someone has held the title of president singularly, and it may portend where the real power will be at Big Blue (and Red).

    Krishna was previously head of the cloud and cognitive software division at IBM. He is an IBM veteran, having been with the company since 1990. His appointment sends a strong signal about how important the cloud is to IBM’s future. In some ways, it is similar to Satya Nadella’s appointment at Microsoft. But perhaps it’s not as strong a signal about the importance of the cloud than the $33 billion IBM spent acquiring Red Hat.

    It is that $33 billion investment and the importance of Red Hat to the new IBM that leads me to believe Krishna may, in fact, be a transitional CEO. The eventual appointment of Whitehurst as CEO and the rise of Red Hat leadership within IBM may in some ways be a reverse-merger type of thing, with Red Hat eventually running the show.

    IBM is a huge beast. A company of Red Hat’s size will find it difficult to change the culture and overcome the inertia at IBM. But frankly, IBM has been transitioning for almost all of Ginni’s time there. While the Enterprise Systems group (Z systems mainframe) is still the cash cow, bringing in a large percentage of revenue, IBM has increasingly tried to be a major cloud player.

    The SoftLayer acquisition didn’t quite give the company what it needed, as it was not a public cloud play. It left IBM unable to compete with Google, Microsoft Azure and AWS in true cloud services. After a few fits and starts, IBM decided that Red Hat, with its open source pedigree and cloud strength in both public and private cloud settings, could be the engine that could as it pertains to cloud.

    The street has not been kind to IBM over the last few years as a result of the botched cloud play, either. At a time when its tech competitors and the market in general have soared, IBM has actually fallen, as has its revenue.

    Mitchell Ashley, founder and managing analyst at Accelerated Strategies Group, agrees with this assessment. “We are seeing a sea change in big tech CEO strategy. Like Microsoft’s elevation of cloud exec Satya Nadella to CEO, IBM is rebuilding its executive ranks from the open source cloud software world with the appointment of Red Hat’s Jim Whitehurst as president and board member,” he said. “How soon the Krishna regime including old-line IBM executives gives way to Whitehurst and other Red Hat executives remains to be seen.”

    IBM CEO Change Elevates Open Source from Digital Anarchist on Vimeo.

    Ashley was not the only analyst to weigh in.

    “IBM bet the farm on cloud with the $34 billion Red Hat acquisition,” said Steve Duplessie, founder and senior analyst at Enterprise Strategy Group (ESG). “It was only a matter of time for the succession. Now the two top dogs running IBM are cloud purists. The old IBM died a while ago and they had to change—I like the move! Their stock lost 26% while the S&P rose over 150%. This lets them remake themselves before it’s too late.”

    Changes at the top don’t always portend success. There is a lot of hard work ahead at IBM as the company continues this journey. Competing with AWS, Google, Microsoft and other players in the cloud space is going to be challenging, given the head starts these players have already. But you really can’t count out IBM, ever.

    One other thing I wanted to mention: With IBM’s appointment of Krishna at IBM, there now are CEOs of Indian descent at Alphabet (Google), Microsoft and IBM. This is very positive for all persons of not only Indian heritage but for all people of color and nationalities. Kudos to these companies and these men for their success. Now, how about some women of color in these roles?

    — Alan Shimel

  • IBM Open Sources SysFlow Monitoring Platform

    IBM Open Sources SysFlow Monitoring Platform

    IBM has announced that its SysFlow monitoring platform is now available as an open source project.

    Fred Araujo, a research scientist in the Cognitive Cybersecurity Intelligence Group at IBM Research, said IBM developed lightweight SysFlow agent software and monitoring tools as a way to provide more context around the telemetry data being collected while simultaneously reducing the amount of data that needs to be stored.

    SysFlow encodes a representation of system activities into a compact format that records how applications interact with their environment, Araujo said, noting that level of context provides deeper visibility in everything from container workloads to cybersecurity forensics. However, unlike existing monitoring platforms, SysFlow doesn’t require IT organizations to collect a massive amount of data to achieve that goal—it is intended to provide for a superset of the NetFlow framework used to analyze network traffic patterns to capture system events, he said.

    Araujo noted IBM doesn’t envision SysFlow eliminating the need for legacy log analytics platforms, as they provide a way to analyze log data. However, SysFlow does enable IT organizations to apply analytics via a graph-like visualization to surface patterns that goes beyond a comparative simple rules-based approach, said Araujo. For example, SysFlow’s approach will make it easier to uncover the relationship between various events that make up a cybersecurity attack and subsequently to identify what countermeasures to employ to create the appropriate kill chain response. It also should substantially reduce the amount of fatigue cybersecurity teams experience from chasing down false-positive alerts, he said.

    SysFlow is designed from the ground up to integrate with both open source frameworks such as Apache Spark and commercial analytics platforms via an open serialization format and associated libraries. IT organizations also can leverage a set of reusable components and APIs to make it easier to deploy telemetry probes. IT organizations also can take advantage of an extensible policy engine that can ingest customizable security policies described in a declarative input language, which then can be checked against records captured by SysFlow.

    Araujo said IBM developed SysFlow to address the challenges associated with managing application workloads in public clouds, but the framework can be applied to any on-premises IT environment to create a single pane of glass through which multiple platforms can be monitored.

    Regardless of the platform on which a workload is deployed, Araujo said as more responsibility for managing and securing applications shifts left toward developers in the age of DevOps, those teams need access to more sophisticated tools that are readily available and simple to deploy. There are several open source initiatives underway to provide that visibility, and one day many of them might coalesce into a single initiative.

    In the meantime, as the dependencies between applications and IT infrastructure continue to increase, it’s clear IT monitoring as a core part of any set of best DevOps practices is now an absolute requirement to achieve and maintain observability.

    — Mike Vizard

  • IBM Advances DevOps on the Mainframe

    IBM Advances DevOps on the Mainframe

    IBM has expanded its efforts to bring DevOps best practices to the mainframe by adding automated unit testing capabilities for CICS COBOL programs using Db2 to IBM Developer for z/OS (IDz) V14.2.1. The company is also making an instance of z/OS available within a Docker container that can be deployed on an x86 platform.

    Sanjay Chandru, director for IBM Z DevOps, said both capabilities will play a critical role in enabling IT organizations that have invested in mainframe to be much more agile. The Docker x86 capability will enable developers to build and test applications without requiring access to a mainframe, while IBM’s automated unit testing tools provide a much lighter-weight alternative to previous generations of tools, he said.

    In addition to automating assertions and pass/fail checks, the automated unit testing capability for IDz makes it possible to invoke the tests from within either the tool itself or as part of a continuous integration/continuous delivery (CI/CD) pipeline, Chandru said. DevOps teams also can now store tests in a modern source code management application alongside the code being developed, he added.

    The IBM unit testing tool can now intercept EXEC CICS and EXEC SQL application calls under CICS to allow data capture during a live run. This recorded data can then be used to create additional tests, including negative tests, in a virtual environment without having CICS because tests are now run as a batch job, Chandru said.

    Finally, IBM is also making it possible to export test results in PDF or XML in addition to JUnit and SonarQube formats.

    Chandru said interest in applying best DevOps practices in mainframe environments has increased dramatically as organizations embrace digital business transformation initiatives. Almost invariably, projects access applications that run on mainframe environments but still process most of the data within enterprise IT environments, he noted. Many organizations are now developing microservices-based applications that rely on mainframes at their back end, he added.

    However, given the rate at which those applications are being developed, legacy approaches to building and deploying mainframe applications are not able to keep pace with the rate of innovation now expected, said Chandru. As a result, IBM is encouraging organizations that have mainframes to shift responsibility for building and deploying applications much further to the left, he said.

    Long term, IBM wants to make developing applications for the mainframe “unremarkable” in the sense that tools for building and deploying applications for any platform should work equally well on mainframes, Chandru said, noting that approach will significantly expand the pool of developers that can build applications for the mainframe.

    It may be a while before DevOps best practices are employed pervasively across mainframe environments, many of which are steeped in legacy waterfall approaches to application development. However, there are pockets of IT teams within mainframe environments that are starting to appreciate the need to be able to respond to changing requirements more rapidly. The only issue that remains now is to determine just how deeply best DevOps practices on the mainframe will be embraced.

    — Mike Vizard

  • IBM Zones in on DevOps for AI

    IBM Zones in on DevOps for AI

    IBM this week revealed it has added a drift detection capability to the Watson OpenScale platform to govern artificial intelligence (AI) models that will become a foundational piece of IBM’s approach to defining best DevOps practices for building AI-infused applications.

    Rohan Vaidyanathan, program director for IBM Watson OpenScale, said one of the biggest AI issues organizations face today is determining when to update or replace an AI model. Announced at the IBM Data and AI Forum event, the drift detection software added to Watson OpenScale provides a continuous monitoring capability that detects how far an AI model has moved from its original parameters, Vaidyanathan said.

    Drift in AI models usually occurs over time, especially as use cases change in ways that are unexpected. Once that drift is detected, organizations eventually want to either retrain that AI model or replace it with a new one. The process challenge organizations face when building AI applications is first assembling the right data to train the model and then integrating that model within an application as part of a continuous integration pipeline.

    With each interaction with an AI model, the result returned to the application might be different as the machine learning algorithms embedded in the AI model continually learn about the process the application abstracts.

    As it turns out, Vaidyanathan said, only one in 20 of the AI models being built make it into production applications, largely because organizations have not bridged the divide between DevOps teams and data scientists effectively. The drift detection capability IBM has developed is a “missing link” that will enable those two teams to begin collaborating more closely, he said.

    IBM has already defined a set of best practices for building AI models as part of its Watson Anywhere initiative, which seeks to drive adoption of the various elements of the Watson platform on multiple clouds. Rather than forcing organizations to load data into an IBM Cloud to use Watson, IBM is working to bring the various engines and application programming interfaces (APIs) to wherever data resides.

    Naturally, IBM would prefer organizations employ the opinionated DevOps and DataOps processes it defines as best practices for building AI models using its tools. However, Vaidyanathan acknowledged there is likely to be plenty of instances in which organizations will prefer to define their own DevOps processes. The hope is those organizations will still access Watson services and metrics using the APIs that IBM has exposed.

    The challenge IBM is encountering in terms of driving AI adoption are manifold. In addition to trying to get data scientists to appreciate DevOps, IBM recognizes AI models are only as good as the data employed to train them. Unfortunately, many organizations have been lax when it comes to data management. As a result, many of them are now revisiting broken DataOps processes. IBM Watson OpenScale and IBM Cloud Paks for Data, a set of portable data virtualization and management tools deployed as microservices, are part of an effort to bring both explainability and order to the building of AI models.

    Obviously, it will take some time for organizations to extend best DevOps practices to incorporate AI models. But at this juncture, it’s more a matter of when rather than if that goal will be achieved.

    — Mike Vizard

  • DevOps Chat: Red Hat Developer Experience in the IBM Era

    DevOps Chat: Red Hat Developer Experience in the IBM Era

    Red Hat Linux is a staple of most enterprise IT organizations’ software diets. Developers and IT leaders all over the world took notice when IBM acquired Red Hat. Will IBM Red Hat change? Will Red Hat continue to operate as it does today or will it be subsumed and disappear into some IBM business unit? Will IBM Red Hat still contribute to projects and tools like Kubernetes, JBoss, Fuse, OpenJDK, Eclipse IDE and many others? All are important questions.

    Brad Micklea, lead of the Developer Program and Tools at IBM, joins DevOps Chat to talk about the future of Red Hat as part of IBM. Brad sends a strong message that Red Hat will remain focused on the developer community and tools for Linux, Kubernetes, Java, DevOps and others.

    Join us as we talk with Brad about the future of Red Hat, DevOps and open source developer tools.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Brad Micklea, lead of the Developer Program and Tools Business Unit at Red Hat.

    Uh, Brad, we’re gonna talk about the Red Hat Developer Program experience in kind of this new era, post-era, of acquisition by IBM. Brad, welcome to the DevOps Chat.

    Brad Micklea: Thanks very much for having me. I’ve been a fan of devopsy.kinsta.cloud for quite a while, and so it’s exciting to be able to talk with you today.

    Ashley: Well, thank you. We’re a fan of you and a fan of Red Hat. So let’s start out by having you just introduce yourself, if there are some folks who don’t know who you are. Introduce yourself, a little bit of what you do at Red Hat.

    Micklea: Absolutely. So I run the Developer Tools Program and Evangelism group here at Red Hat. Uh, I’m actually fairly new to Red Hat. I’ve been here about two years. I came into Red Hat via the acquisition of Codenvy, which is a little startup out of California that I was part of, although I’m based in Toronto, Canuck power. Um, so–

    [Crosstalk]

    Ashley: You had to get that in. Good for you [laughs].

    Micklea: I did. I did. I always have to get that in [laughs].

    Ashley: Oh, goodness.

    Micklea: Yeah. So that’s, um you know, so our mandate really is to make–kind of help the whole organization in, you know, reaching out to developers. We have the developer program where developers can come and get great content on topics like Kubernetes and Java and Linux, as well as things like secure programming, DevOps of course, and a number of other things. Uh, we pair it–we kind of marry that with a set of developer-oriented tools that support our projects and our products.

    And evangelism is done as well, of course, in the upstream communities and events and other places, to help developers become aware of what they may not know, which is that Red Hat is not just the Linux company, although, of course, that’s a huge part of what we do. We do so many more things than that in the open source.

    Ashley: Well it seems certainly Red Hat is the model for, you know, a program like that with the developer community, with the user community. And you all have done a fantastic job of expanding that into other areas. Talk a little bit about–it’s more than just the operating system. Tell us about what some of those things are.

    Micklea: Yes. Well, of course, right now, a lot of the buzz is around Kubernetes. And a lot of people don’t realize that Red Hat is actually the second largest contributor and committer to the Kubernetes project.

    Ashley: I did not know that.

    [Crosstalk]

    Micklea: Yeah. Yeah, it’s one of those things where, you know, we’ve been probably the second largest contributor for pretty much the entire history of Kubernetes, but a lot of times it just goes unnoticed. We run SIGs, a number of different things out in the open source for that project and related projects like Tekton, like _____, et cetera. So that’s a huge focus for us right now, and something that is–I’m certainly very passionate about, personally having come, like I said, to Red Hat via a very container-oriented company.

    But beyond that, we have, of course, our middleware portfolio is huge and has been around for, you know, well over a decade with, you know, OpenJDK is, of course, a Red Hat project. We’ve got all of our middleware solutions, whether it be, you know, JBoss or some of our integration platforms like Fuse, our automation platforms.

    So there’s really a ton of different things and it really is something that is exciting about being here for me, because there is a lot of stuff for developers. Although people think of us as a very kind of ops-centric company, we have always had developers at heart and certainly, you know, it’s a company of engineers, really, which is probably why, in some cases we–people don’t know all these things we do because we’re engineers, not marketers [laughs], you know, so.

    Ashley: Write a lot of software you do.

    Micklea: That’s right, exactly.

    Ashley: So I mean, you know, it’s not just Linux. I know you’ve contributed to Java, like IDEs, if I remember right. I think you contributed to Eclipse or something.

    Micklea: Absolutely, absolutely. We were one of the kind of early contributors and continue to contribute to the Eclipse Desktop IDE as well as other Eclipse projects. We’re actually one of the key, I guess, contributors to the Eclipse Cloud Development top-level project and to various projects under that umbrella.

    But also, and this is kind of mind-blowing perhaps for some people who haven’t been tracking where Red Hat has been going over the last several years. We publish a large number of plug-ins for the VS code IDE and–

    Ashley: Microsoft.

    Micklea: Microsoft’s, yeah, Azure DevOps. And, you know, certainly there was a time, maybe what, a decade ago, when the idea of Red Hat and Microsoft hanging out together would have been just inconceivable, but–

    Ashley: There’s been a lot of ret, that’s about it.

    [Laughter]

    Micklea: Yes, that’s right, exactly. But, I mean, those plug-ins have done fantastically well for us. The Java support that you have in VS code is, you know, comes from Red Hat and has, I want to say, a little over 60 million downloads at this point.

    Ashley: Wow.

    Micklea: So it’s incredible stuff, yeah.

    Ashley: Well, it’s amazing how the developer community, you could kind of picture back to the Java days, when you were just Java and that was it and that was the solution to everything. And while Kubernetes has certainly set the world on fire, containers really has, but it’s interesting. What I see is how much the developer communities kind of cross and intersect with each other and work with each other, both at the vendor level, at the company level and just at people developing software. So yeah, you may have a favorite in Microsoft or Google or, you know, in Amazon for a hosting environment or whatever, OpenShift, something like that, but people do a lot more work together it seems like to me. Is that your experience?

    Micklea: Absolutely. And I mean I’m like you, of a certain age, where, like, I remember the people used to just identify themselves as, “I’m a Java developer.”

    [Crosstalk]

    Ashley: “I remember when,” yeah.

    Micklea: Yeah, exactly, right.

    Ashley: “Back in the Java days.”

    [Laughter]

    Micklea: But I mean today, that’s not really the case. Pretty much everybody codes in a couple different languages, at least, sometimes more than that, and has personal projects and the work projects. And so I think it’s just become the norm for developers to kind of pull from many different areas of the community, you know, getting inspiration from different areas and bringing things together in a way that just works for whatever their particular project needed.

    Ashley: You know, it may be a causality, it may be the source of it, but things like DevOps, things like Agile, it’s really changed the way we even think about creating software or the way we form teams, you know, shift left. There’s organizations where they’re trying to sell into a customer base that those people are different now. The security people are part of a dev team and they’re learning development. And in a way, it’s both creating a lot of new business models and operating models on how we create software. It’s also creating question marks maybe and some confusion for some vendors and manufacturers of, “I don’t know if I understand DevOps yet, but I sure got to figure it out because that’s where the world is going.”

    Micklea: Oh, I couldn’t agree more. And I’ll just say, like, thank goodness it is ’cause, um, I certainly–[crosstalk]–don’t miss the way software used to be developed.

    Ashley: Oh, come on, those silos, oh, those were the fun days, yes.

    [Laughter] 

    Micklea: Yeah, but I think it’s interesting, too. Again, as, you know, from our perspective, a lot of what you see in good DevOps practices is similar to what you see in a healthy open source community. You have, you know, people coming to–the whole point or an open source community is that it is open and everybody really is on the same team, and there isn’t so much the straight lines of, “Hey, this group in the community only deals with security, and this group only deals with that.” People do blend. They bring whatever skills they have, whatever experience they’ve got–

    Ashley: ____ to work on, right.

    Micklea: Exactly, that’s right, and I think you see great DevOps teams or–pardon me–great teams that follow DevOps principles, I think you see something very similar, where it isn’t so much like, “Hey, I’m Brad. I’m the ops guys in this DevOps, you know, world. You know, Mitch is the dev guy in the, you know, in this world.” It’s not like that. It’s just, you know, I come and I say, “Hey, I’ve hit this security issue, so let’s not do it this way. Let’s do it this way and we’ll avoid it.” And I think that that’s really what makes it exciting.

    Ashley: Well, you know, you’ve connected those two dots of open source and DevOps in a new way for me, and maybe we really do need to credit open source for creating that and a work team environment that’s evolved now into this DevOps structure. So it makes sense to me. I mean look where open source is coming just in the last ten years, more or less before that. So I’m really curious to–it’s just a rare occasion we get to speak with someone who is really kind of overseeing and leading on such a big community of contributors and users of all the Red Hat technology.

    What does that take? What’s a day in the life of Brad like?

    Micklea: Hmm, uh, it’s interesting. I think one of the things I love about my job, honestly is that I’m a little bit–I get bored easily, um, [laughs], and so this is a job that is never boring. Um, I’ve come from more of an engineering side and product side. So for me, it’s pretty natural to be hopping around, investigating new projects, um, you know, jumping in to get hub repos and looking at pull requests and contributor stats and seeing kind of how is the community and the engagement within different projects changing over time.

    That’s all, you know, just kind of part of kind of who I am and how I work. The part that’s interesting and fun for me is, you know, now hitting more of the program side and the marketing side and, you know, working with folks who are, thankfully, much, much more experienced than I am on my team in this area, and learning from them about, you know, how we can reach out to developers, how we can get our message heard by them, and then helping other folks, both within Red Hat and outside, to understand kind of the best way to speak to developers.

    And I’m, I think, really proud, I guess, of the way that the approach that engineers naturally have to their job, which is one of kind of no nonsense, no hyperbole, just, you know–just the facts please. Let me judge for myself whether this is the greatest thing since sliced bread or whether it’s irrelevant to me.

    And I think that I’m starting to see and I like this, that more and more aspects of marketing, even beyond developer marketing, are waking up to this, this idea of, “We’re the number one,” isn’t the best way to market. It’s really more about saying, “We do this. We do that, and we do the other thing. And if you need those three things, then we might be the best thing for you. And if you don’t need any of those three things, then you probably don’t care.”

    Ashley: I could go on–I could go on a tangent of how many sites, vendor sites I’ve been to and said, “I read your site. I have no idea what you do, but [laughs] nice site.”

    Micklea: That a huge thing, you know, and it’s one of those things that I’ve always been very passionate about when it comes to positioning and content is–and, again, it comes from that engineering background, is I don’t want adverbs. I don’t want adjectives. I just want a description of what it is.

    Ashley: Save the hyperbole.

    Micklea: Yes, save hyperbole. Tell me what it is in plain English, and then I’ll tell you if it’s useful for me.

    Ashley: Mm-hmm. It’s much more of a transparent and kind of honest relationship with the customer, the user, where we’re not trying to flower it up. Yes, we’re trying to–yes, put our light on it, but in a way that they’re gonna consume it, ’cause you’re right. They’re not gonna take the hyperbole and the, you know, we’re the world’s best of everything. We know you’re not, right.

    Micklea: Well, exactly, and I think–

    Ashley: So I’ll be the judge of your technology.

    Micklea: That’s right, and I think if you show people that respect, you know, they reward you. And ultimately as a business even, ’cause, you know, Red Hat is not a, you know, an NGO. We’re a business. We make money.

    Ashley: Mm-hmm.

    Micklea: I’d always rather go to somebody, tell them exactly what they do, and know that either right away they’re gonna say, “Not for me,” and walk away and I lose them. I’m okay with that. I was never gonna win them.

    Ashley: Yeah.

    Micklea: You know, and I’m–so now I can focus on the people who didn’t walk away right away, and now I know that I’ve got a better chance of kind of converting them to my products.

    Ashley: Well, you know, one of the topics I wanted to cover with you is not too long ago the IBM Red Hat merger/acquisition had been completed. And I’m sure you’re not an expert on all things in the merger [laughs] and all things that happened, but what kinds of–if you can share with us, and if not, that’s okay–what kind of things have you heard from the community? What questions are they asking you, now that you’re part of IBM and how have responded? I know you wrote a blog post about some of these things.

    Micklea: Yeah, no, absolutely. And I– let me just start actually by saying that this acquisition personally kind of blew my mind. When I–when I first got the e-mail, it actually was one of those e-mails I had to read two or three times to make sure I was actually reading it properly–

    Ashley: [Laughs] is this, uh, April 1? What happened?

    Micklea: Really, I mean because $34 billion for a company that has nearly no IP. Like, that–when I read that, having been through numerous acquisitions in the past and, you know, having been close enough from an executive level to them that I, you know, was involved in negotiations for how much is this company worth based on how much money does it make, based on how much IP does it have, all those normal questions, I thought, “That’s incredible.” What an incredible kind of proof point of the value and increasing dominance of open source.

    Ashley: And the community. That’s the value.

    Micklea: And the power of the community, exactly. You took the words right out of my mouth. And the power of the community, $34 billion in terms of value of that community.

    Ashley: It’s amazing.

    Micklea: Um, you know, so I think what’s understandably the, you know, initial reaction from many people, you know, both in the community and inside Red Hat and elsewhere, was a bit of skepticism on how this would turn out.

    Ashley: Of course, because you expect–it’s only natural, right.

    Micklea: It’s only natural.

    Ashley: You’ve seen these things happen before. They go well. They did not go well.

    Micklea: Yeah.

    Ashley: You know, what’s gonna happen to us?

    Micklea: That’s right. And, you know, I think it’s easy for people to forget. One of the benefits of having worked in dev tools is I’ve been close to this. IBM has, you know, contributed to open source for a long time now.

    Ashley: Mm-hmm.

    Micklea: That doesn’t make them like Red Hat. I mean Red Hat is quite different and quite unique in the way that we don’t really have any proprietary products. But, you know, at least they are open source aware and have been contributing to open source, and especially, like I said, around dev tools. That’s really been the whole way that they’ve done their dev tools.

    You know, so I am optimistic and kind of in my blog I talked about the fact that the plan is for the developer program of IBM and the developer program of Red Hat to remain separate, and there’s a commitment from both sides to do that.

    And it was funny because going into my very first conversation with my IBM colleagues to try and discuss this, I was honestly quite nervous. I thought you want me to go in there. I don’t know these people, and the first thing I’m gonna say is not very embracing. It’s gonna be, “We’re gonna keep these things separate, guys. I’m sorry. You’re not touching my program.”

    Ashley: Got to go in there swinging, fighting for what’s important, right.

    Micklea: Exactly, and I said–that’s exactly what it was. I said, “You know, this is important to me, so I’ve got to start there.” What amazed me and it was I think a very, very nice thing to see is that from the very beginning it wasn’t even a question. They were like, “Well, oh yeah, of course it’s gonna remain separate.”

    Ashley: Interesting.

    Micklea: Like you need to be separate. You have all that kind of credibility that you’ve developed over 20 years with this community and within open source, and we don’t want to change that. That’s why you’re worth $34 billion.

    Ashley: So now you got my head spinning. Why do you think–how did they come–the folks putting the deal together, how did they come to that conclusion so clearly, where you didn’t have to convince them?

    Micklea: Well, I think that to their credit, there are a lot of smart people in IBM.

    Ashley: Sure.

    Micklea: And, you know, they looked at Kubernetes. They looked at Linux and said–and our Java, and really said, “Hey, you know, these are three core components not just in people’s, you know, datacenters today, but in the way that IT and development will together in the future.” And so, if we go and try and take them, you know, buy it and then grab this stuff and make it proprietary and, you know, do all those things, which, frankly, a lot of people would have expected them to do, there’s nothing stopping everybody from walking away.

    Ashley: Mm-hmm.

    Micklea: There are alternatives and people vote with their feet. So I think that they had the clarity of mind to say, “If we do that, we’re going to be buying a company and then destroying the value of our investment. If, on the other hand, we allow that company to run as it has, and instead give ourselves, IBM, the ability to focus our resources and thinking on parts of this portfolio like OpenShift, like Red Hat Enterprise Linux, so that we can kind of add additional weight and momentum behind them,” and I think that’s really where they see the ongoing value.

    Ashley: It’s awesome that they did that and I think one of the characteristics of something that has a community built around it like this is people make an emotional connection to the brand and to the community, right. They believe in Red Hat. They believe in what this group is developing and the approach that they’re–we’re taking with open source and, you know, being free contributors to it and having that flexibility. And so they don’t want to lose that. So it’s super-smart to keep–I’m not saying there’s anything wrong with the IBM developer program, but it has its characteristics, too, and blending them you–instead of getting the best of both, you might get the worst of them both.

    Micklea: I think that that was exactly the thought, is that if you blend them you’re gonna get actually the worst of both and not the best. And their program has, like you said, a bunch of strengths that ours doesn’t have. Like, we are not able to cover the breadth of topics that they are. We just don’t have the size or expertise to do that.

    Ashley: Mm-hmm.

    Micklea: And so we don’t try, you know. That’s something that’s great for them and they have a killer program, and if you, you know, if you haven’t, Todd Moore wrote a–from IBM–wrote a great blog about the acquisition and kind of his excitement.

    And then from the community perspective, Chris Wright on the Red Hat team also had a wonderful blog on kind of what it means for the community. But you’re 100% correct. The feeling of the community towards Red Hat, and that was one nice thing about the acquisition. Although a lot of people were very vocal about, you know–’cause I was on Hacker News when it happened and trying to respond to some of the–to some of the threads that popped up. You know, people were very vocal about I–you know, this feels like it’s gonna be the end of Red Hat.

    What was–you know, and obviously, I don’t feel that, but I understand where they’re coming from. What was nice though is that it shows the degree to which they cared. You know, there was genuine feelings of sadness in those posts, even though they’re–you know, they’re not–you can’t hear the voice. You could kind of just feel through the post somebody saying, “Oh, this is the end of–if this is the end of Red Hat, that would be a terrible, terrible thing.” And, you know, I don’t think it will be, like I said, but–

    Ashley: Well, you know, it was done well on the front end, this decision about the developer communities. And, you know, of course, just like we were talking about marketing to developers, that transparency, that honesty, the proof’s in the pudding, too, right.

    Micklea: Exactly.

    Ashley: It’s–in the end, that’s what will convince folks of, yep, it is. And maybe it’s a little better, maybe it’s a lot better, maybe it’s the same, but it’s at least got what we love about it. So that’s what you hope happens.

    Micklea: Well exactly, and that was kind of my repeated message. It’s been my repeated message, you know, since then, which is actions speak louder than words. So I can tell you everything is gonna be, you know, the same, as it was and–or sorry, I shouldn’t say that. I believe–I wouldn’t say that because nothing ever remains the same in technology. Even if we hadn’t been acquired by IBM [laughs], things would change.

    But, you know, it’s the core of Red Hat will remain the same. It will still be there. But, you know, people should watch everything we do and, you know, if they see something that they feel isn’t true to that, it should be called out.

    Ashley: Well we’d love to have you on for another episode, maybe a little ways down the road, if there’s some news or just to check in on out in the community and how this unfolded.

    Brad, I want to thank you, Brad Micklea, who is a lead in charge of the, Developer Program at Red Hat. Thank you so much for joining us on the podcast.

    Micklea: Thanks for having me, Mitch. It was a pleasure.

    Ashley: The pleasure’s definitely been mine. I also want to thank you, you, our listeners, for joining us. This is Mitch Ashley with devopsy.kinsta.cloud. You have listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • To Build a Healthy DevOps Culture, Look to Your Ecosystem

    To Build a Healthy DevOps Culture, Look to Your Ecosystem

    How do you do DevOps?  Here’s a hint: Don’t fixate on finding the right tools or implementing the right processes. Instead, think about the broader ecosystem in which you operate, the culture that prevails in that ecosystem and which parts of the culture you can borrow to help enable your DevOps transformation.

    This is true no matter which type of ecosystem you work in–even one that depends in part on mainframes. In other words, to quote from Rouan Wilsenach, writing on Martin Fowler’s blog, “Even with the best tools, DevOps is just another buzzword if you don’t have the right culture.”

    Keep reading for tips on what this means in practice, and how to build a successful DevOps culture by engaging your ecosystem.

    Tools and Processes in DevOps

    To be sure, tools and processes are a key part of DevOps. We’ve yet to see an organization that achieves continuous delivery successfully without the help of a continuous integration server or a continuous feedback process.

    But the reality is tools and processes are not what ultimately separates DevOps success from DevOps failure. Tools and processes help you to implement DevOps; but on their own, they don’t deliver the cultural priorities that allow DevOps organizations to thrive.

    This is an important point to digest. The market is teeming with tools pitched as critical enablers of DevOps, and there is no shortage of articles about why processes such as shift-left testing or de-siloing your team are important for DevOps.

    It would be a mistake, however, to assume that doing DevOps is as simple as implementing one of these tools and processes. If it were, we wouldn’t be spending so much time talking about DevOps in the first place, because it would be a trivial thing for anyone to achieve.

    DevOps Culture

    What matters above all in DevOps is culture. By culture, we mean the values and viewpoints that shape how your team approaches software delivery.

    If your team members don’t believe in constant collaboration and transparency as cultural values, no amount of continuous integration servers or real-time communication tools are going to enable you to achieve the type of team-wide collaboration necessary to support continuous delivery. Similarly, if your developers, software testers or admins don’t recognize the importance of doing continuous delivery in the first place, having the tools and processes in place to perform continuous delivery is not enough to ensure it actually happens.

    This is why instilling key cultural values is critical for DevOps. This isn’t an exhaustive, universally applicable list of essential DevOps cultural values, but most folks would include the following items in this category:

    • Collective accountability. Everyone on your team should assume responsibility for ensuring that software is delivered on time and meets expectations. Software delivery is everyone’s responsibility in DevOps.
    • A blameless environment in which the team as a whole, rather than individuals, owns the system.
    • In a DevOps culture, all team members should have constant visibility into what other members of the team are doing.
    • DevOps places a priority on minimizing manual effort. It promotes automation over allowing some team members to perform tasks manually in order to protect their turf or increase their individual value.
    • Collaboration and shared roles. In DevOps, no single engineer should exclusively own a particular task. Some people might bear primary responsibility for certain tasks, but at the end of the day, everyone should be permitted, qualified and willing to assist with any task.
    • Support from management for all of the above. Executives need to embrace the concept of collective ownership for IT processes, while also giving IT teams the flexibility to scale and change tools and processes as needed.

    Your Ecosystem and Your Culture

    How do you actually construct a DevOps culture founded on principles like those described above? Part of the answer lies in evaluating your current internal company culture, of course, and taking steps to change it.

    But another important part of the answer lies in your business’s ecosystem. After all, culture is not something that develops only on the basis of internal factors. Culture is influenced to a tremendous extent by what is going on around you.

    So, in order to build a healthy DevOps culture, think about what other companies you engage with are doing. In many cases, you can jump-start your DevOps cultural transformation by borrowing ideas from partners who have already been there.

    To be clear, I’m not suggesting you look only for partners who have won accolades as DevOps-first organizations, or startups that have had the benefit of coming of age when DevOps was already a big deal. Think also about established companies that have deep experience working with an array of different technologies, integrating those technologies and bringing them up-to-speed with modern software delivery practices.

    Those are the organizations that have sophisticated, organic cultures. They’re also the ones that know what it takes to update existing cultures to support DevOps. And they may be able to help you identify the specific tools and processes that will enable DevOps for your business.

    Building a Healthy DevOps Ecosystem

    As an example of what the process of constructing an effective DevOps culture might look like in practice, consider how you might approach this challenge if your ecosystem (like many today) includes a mix of modern, cloud-based infrastructure on the one hand, and mainframes on the other.

    This might seem like a difficult circle to square. Conventional wisdom tells us that mainframes may be difficult to integrate with modern DevOps processes.

    But that is not the case. IBM offers a range of solutions to help integrate mainframes into the rest of your ecosystem. For example, Z Open Development makes it possible to standardize your SCM and build processes for mainframes using modern, Git-based tooling. Likewise, Z Open Unit Test makes it possible to bring modern unit testing to mainframe applications. And you can even test and build mainframe apps on commodity x86 servers using Z Development and Test Environment.

    Of course, integrating mainframe infrastructure into the rest of your ecosystem using tooling like this also requires a culture and attitude adjustment. Developers and ITOps admins must move past the cliché that mainframes have no role to play in modern DevOps shops, or that they are too difficult to integrate into modern ecosystems. That’s not at all true and building a successful DevOps culture that embraces the mainframe means discarding this inaccurate viewpoint.

    Conclusion

    In short, succeeding at DevOps means adopting the right cultural principles to turn a DevOps toolset into an actual DevOps workflow. The good news is you don’t have to invent those principles from scratch. Look for an experienced ecosystem partner or partners who can help you in your DevOps cultural journey.

    — Chris Tozzi

  • Why and How to Collect KPIs for Z DevOps

    Why and How to Collect KPIs for Z DevOps

    It can sometimes feel frustrating to try to figure out how to do DevOps. That’s because DevOps is not about tools—there are lots of different tools that can help you succeed at DevOps. Nor is it about any really specific set of practices; although DevOps prioritizes things like automation and communication, it does not prescribe specific processes for enabling them.

    Instead, DevOps is really just about cultural values, which is a rather vague guideline for people who want to do DevOps. In this sense, DevOps can make practitioners feel a little lost, because they’re unsure how to measure whether they are succeeding on their journey toward DevOps.

    The fact that DevOps ultimately boils down to culture does not mean there are not specific points of information you can track and analyze to help assess progress on your DevOps journey. The specific metrics you’ll analyze will vary depending on your circumstances and the systems you use, of course. But to provide an example of how you can evaluate DevOps progress in the real world, let’s take a look at which types of key performance indicators (KPIs) you might focus on when doing Z DevOps.

    What Is Z DevOps?

    Z DevOps refers to a DevOps practice within the IBM Z ecosystem. Although Z is not typically the first technological niche to come to most people’s minds when they think of DevOps, the fact is more than half of enterprise transactions continue to run on IBM mainframes. The vast majority of structured business data also resides on these systems.

    Thus, bringing mainframe software delivery up-to-speed with DevOps culture is an important priority for many organizations. That’s what Z DevOps is all about.

    KPIs for Z DevOps

    Whether you’re just starting on your Z DevOps journey, or have been doing DevOps-based software delivery on the mainframe for a long time already, there are a variety of KPIs you can track to help assess how effectively your DevOps strategy is working, and find ways to make it even better. Remember, DevOps is all about continuous improvement and never settling for the current state of affairs.

    Deployment Speed: DevOps prioritizes faster software delivery. For that reason, being able to track how quickly you push out new software releases or updates is critical for measuring your DevOps success. In DevOps circles, this KPI is sometimes called Mean Time to Delivery, or MTTD.

    Keep in mind that truly continuous releases (meaning releases that are literally constant) are an unachievable goal. But by tracking your current deployments per week or month, you can measure how your deployment speed changes over time.

    Deployment Success Rate: Software deployments can fail for a variety of reasons, and achieving 100% success is not practical for most organizations. But you still want to strive to maximize your deployment rate. Anything around 90% is impressive in many cases. So, track how many deployments succeed and fail.

    Deployment Scale: Deployments vary greatly in size. One deployment might contain a few minor performance tweaks. Another might involve major interface or feature overhauls. In order to contextualize other deployment-related KPIs, it’s important to measure deployment scale by collecting information about the scale of your typical deployment.

    Scale in this context can be difficult to measure precisely, but basic metrics to track include information like how much new code is a part of each deployment, or which percentage of a deployment entails new features as opposed to bug fixes for existing features.

    Test Failure Rates: In most DevOps delivery pipelines, you will rely heavily on tests (especially automated tests) to verify that software is ready for delivery before it is deployed. When tests fail more often than expected, it can be a sign that developers are working too quickly or need more feedback about code quality. Tracking test failure rates can help you assess these issues and take action in order to minimize failures and keep deployments running on schedule.

    Team Performance: In addition to tracking overall speed and performance, it’s important to be able to track these KPIs on a per-team basis. Again, DevOps is all about culture, and some teams might need more help than others in embracing DevOps culture. By tracking deployment performance on a per-team basis, you are in a better position to identify teams that need more help, as well as those doing well and can serve as an example for others.

    Inter-Team Communication: Since DevOps is all about transparency and efficient communication across the entire IT organization, communication activity between different teams is another useful KPI to track. The data you collect on this front could include things such as emails or Slack messages exchanged between teams, or even meetings or phone calls. This data is not a perfect reflection of how effectively different teams engage with each other, but it provides some useful insight.

    Collecting DevOps KPIs for Z

    If you are doing Z DevOps, one challenge you’ll face is  many generic DevOps tools weren’t initially designed to work in the Z ecosystem. They were designed for other types of infrastructure and environments.

    That doesn’t mean the tools you need to do Z DevOps don’t exist, however. You just need to look beyond generic DevOps guides to find them.

    When it comes to collecting KPIs for Z DevOps, the go-to tool is UrbanCode Velocity. In addition to helping to automate and standardize the software delivery process for the Z ecosystem by providing release automation templates and tooling, UrbanCode Velocity lets you collect and track the various metrics that are important for taking stock of your Z DevOps operation.

    Because UrbanCode Velocity supports KPIs based on data gathered from Z DevOps pipelines, it can help to standardize your entire DevOps workflow, not just your Z DevOps effort.

    — Chris Tozzi

  • Shift-Left Testing, Continuous Integration and the Mainframe

    Shift-Left Testing, Continuous Integration and the Mainframe

    “Mainframe” is one of the oldest terms in tech. “Shift-left” is much newer.

    You may not think, then, that mainframes and shift-left testing have much in common. But you’d be wrong. Shifting testing to the left can deliver tremendous benefits, even in the context of mainframe applications.

    Let us explain.

    What Is Shift-Left Testing?

    Shift-left testing refers to the practice of performing more tests earlier in the software development lifecycle.

    Traditionally, most testing occurred just before software was deployed into production environments. Testing code at this stage is useful for ensuring it will behave as expected in production, but it comes with drawbacks.

    The biggest drawback of traditional testing is problems are difficult to fix if they are not discovered until just before software is ready to be deployed. At that point, addressing a problem within the code requires determining where specifically the problem exists within the code, removing that code from the application and replacing it with updated code—all without breaking other parts of the application that depend on the original code.

    Shift-left testing helps to address this problem by encouraging software delivery teams to perform tests earlier—typically, starting right after individual units of code are written. Being able to test earlier and more often is especially important in software delivery pipelines based on continuous integration/continuous delivery (CI/CD), where the goal is to roll out application changes on a nearly continuous basis.

    Since bugs that aren’t detected until just before release can take a long time to fix, a lack of shift-left testing puts organizations at risk of not being able to achieve the main goal of CI/CD due to constant delays caused by software quality problems. In addition, shift-left testing reduces the amount of overall end-to-end testing you have to perform.

    You Still Test on the Right

    It’s important to note tests performed earlier in the pipeline don’t replace the testing done just before deployment. They complement them and reduce the chance of having problems go undetected until right before deployment. In this sense, the term shift-left can be a bit misleading; it’s not really about shifting all testing to the left of the delivery cycle, as much as it is starting tests earlier, while continuing to test on the right of the pipeline as well.

    Shift-Left Testing and Continuous Integration on the Mainframe

    Shifting testing to the left makes it easier to fix code problems within virtually any type of application delivery pipeline based on CI/CD. But it can deliver especially critical benefits for software delivery teams striving to bring mainframe applications up to speed with CI/CD.

    There are a few primary reasons why. One is mainframe applications are usually written using older programming languages that were not designed to help developers avoid mistakes. This isn’t to say mainframe languages are especially prone to errors; they’re not. But compared to a language such as Python, which is designed to enforce good coding habits, a language like COBOL doesn’t exactly require programmers to be highly disciplined when they’re typing out their code. Thus, it’s especially important to be able to catch bugs earlier within code written in a mainframe language.

    Another factor is mainframe applications are often part of legacy codebases. When you’re dealing with code and dependencies that are decades old in some cases, you’re at a greater risk of ending up with software quality problems, despite your best efforts. Here again, detecting those problems earlier rather than later means they can be fixed without interrupting the entire CI/CD process.

    Finally—and most important—is the fact that in some cases, there is a large disconnect in terms of skill set and familiarity with mainframe code between software quality engineers and mainframe programmers.

    Your typical QA engineer today didn’t grow up with z/OS and may have limited experience troubleshooting software problems. Given the QA team is typically responsible for running pre-deployment tests, this can pose a problem in the event that QA detects issues with a mainframe application that it has no idea how to troubleshoot, let alone fix. By shifting testing to the left, it’s easier to give developers faster feedback so that they can fix bugs more quickly.

    How to Shift Mainframe Application Testing to the Left

    If you thought mainframes had nothing to gain from the shift-left testing movement, you might also think there aren’t many tools out there to help you do shift-left testing for mainframes.

    Fortunately, that’s not true at all. For unit testing, IBM offers Z Unit, a unit-testing tool for z/OS programs. Z Unit is included in Z Open Unit Test and IBM Developer for z Systems. Using these tools, Z developers can automatically generate unit tests for batch and CICS programs as part of their daily work. These tests can be stored in any standard SCM and can be executed independent of their environment.

    You can even test mainframe apps on non-mainframe hardware using Z Development and Test Environment. The platform creates virtual Z environments on x86 systems so developers can write, build and test their mainframe applications on any standard commodity server or development box.

    Conclusion

    Whether your mainframe applications are decades old or have been written from scratch in just the past few years, there’s nothing stopping you from taking advantage of shift-left testing to help validate them. Doing so will make it easier to achieve CI/CD effectively for your mainframe application, which keeps your software delivery team and your end-users alike happier by reducing bugs and delays.

    Check out the Z Open Unit Test demo.

    — Chris Tozzi