The mainframe is like an elephant in many large enterprise data centers: It never forgets data, but it's a large...

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

Please check the box if you want to proceed.

Please check the box if you want to proceed.

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

obstacle to DevOps velocity that can't be ignored.

For a while, though, enterprises tried to leave mainframes -- often the back-end nerve center for data-driven businesses, such as financial institutions -- out of the DevOps equation. But DevOps for mainframe environments has become an unavoidable problem.

"At companies with core back-end mainframe systems, there are monolithic apps -- sometimes 30 to 40 years old -- operated with tribal knowledge," said Ramesh Ganapathy, assistant vice president of DevOps for Mphasis, a consulting firm in New York whose clients include large banks. "Distributed systems, where new developers work in an Agile manner, consume data from the mainframe. And, ultimately, these companies aren't able to reduce their time to market with new applications."

Velocity, flexibility and ephemeral apps have become the norm in distributed systems, while mainframe environments remain their polar opposite: stalwart platforms with unmatched reliability, but not designed for rapid change. The obvious answer would be a migration off the mainframe, but it's not quite so simple.

"It depends on the client appetite for risk, and affordability also matters," Ganapathy said. "Not all apps can be modernized -- at least, not quickly; any legacy mainframe modernization will go on for years."

Mainframes are not going away. In fact, enterprises plan to increase their spending on mainframe systems. Nearly half of enterprises with mainframes expect to see their usage increase over the next two years -- an 18% increase from the previous year, according to a Forrester Research Global Business Technographics Infrastructure Survey in late 2017. Only 14% expected mainframe usage to decrease, compared to 24% in the previous survey.

Whatever their long-term decision about mainframes, large enterprises now compete with nimble, disruptive startups in every industry, and that means they must find an immediate way for mainframes to address DevOps.

Bridging DevOps for mainframe gaps Credit bureau Experian is one enterprise company that's stuck in limbo with DevOps for mainframe environments. Its IBM z13 mainframes play a crucial role in a process called pinning, which associates credit data to individuals as part of the company's data ingestion operations. This generates an identifier that's more unique and reliable than Social Security numbers, and the mainframe handles the compute-intensive workload with high performance and solid reliability -- the company hasn't had a mainframe outage on any of its six mainframe instances in more than three years. However, Experian has also embarked on a series of Agile and DevOps initiatives, and the mainframe now impedes developers that have grown accustomed to self-service and infrastructure automation in production distributed systems. "IBM has recognized what's happening and is making changes to [its] z/OS and z Systems," said Barry Libenson, global CIO for Experian, based in Costa Mesa, Calif. IBM's UrbanCode Deploy CI/CD tool, for example, supports application deployment automation on the mainframe. "But our concern is there aren't really tools yet that allow developers to provision their own [production infrastructure], or native Chef- or Puppet-like configuration management capabilities for z/OS." Chef supports z Systems mainframes through integration with LinuxONE, but Experian's most senior mainframe expert frowns on Linux in favor of z/OS, Libenson said. Puppet also offers z/OS support, but Libenson said he would prefer to get those features from native z/OS management tools. IBM's z Systems Development and Test Environment V11 offers some self-service capabilities for application deployment in lower environments, but Experian developers have created their own homegrown tools for production services, such as z Systems logical partitions (LPARs). The homegrown tools also monitor the utilization of LPARs, containers and VMs on the mainframe, and tools either automatically shut them off once they're idle for a certain amount of time or alert mainframe administrators to shut them off manually. "That's not the way these systems are designed to behave, and it's expensive. In commodity hardware, I have lots of options, but if I run out of horsepower on the mainframe, buying additional engines from IBM is my only choice," Libenson said. "It's also increasingly difficult for us to find people that understand that hardware." Experian is fortunate to employ a mainframe expert who doesn't fit the stereotype of a parochial back-end admin resistant to change, Libenson said. But he's not an infinite resource and won't be around forever. "I tell him, 'If you try to retire before I do, I will kill you,'" Libenson said. Ultimately, Experian plans to migrate away from the mainframe and has ceased product development on mainframe applications, Libenson said. He estimated the mainframe migration process will take three to five years.