devopsy.kinsta.cloud

Author: Mike Vizard

Harness Adds Analytics to CDaaS Platform

Harness has added an analytics module to its namesake continuous delivery-as-a-service (CDaaS) platform that makes it easier to better align constrained software development resources with business goals.

Omed Habib, director of product marketing at Harness, said Continuous Insights enables organizations to identify bottlenecks and improve overall software delivery by automatically gathering metrics such as deployment frequency, lead time, mean-time-to-restore (MTTR) and change failure rate.

The Harness Continuous Insights dashboard

Habib said the biggest challenge organizations face when it comes to continuous delivery is the delicacy of most IT environments. All the interdependencies between complex systems force IT organizations to rely on manual processes and custom scripts, he said, noting the process of rolling back an application whenever there is an issue can take days and weeks.

The Harness CDaaS platform provides a more seamless approach to application delivery that automatically detects new builds in GitHub, Bamboo, Jenkins, Artifactory or Nexus repositories or any Git repository. Once the DevOps team is alerted, they can employ graphical tools to not only automate the process of building pipelines using YAML files but also leverage machine learning algorithms to evaluate the quality of a deployment and then automatically roll it back whenever necessary by accessing data from tools such as AppDynamics, New Relic, Splunk, Elastic Search and Sumologic, added Habib.

Harness comes in three flavors. There is a Professional Edition supported by Harness and a free forever Community Edition. There’s also an Essentials Edition aimed at medium-sized companies that do not require a full set of enterprise and security features. The Continuous Insights analytics module is free for all new and existing customers of the Harness Professional Edition.

Habib said that despite all the advances being made in terms of DevOps and continuous integration, organizations are still struggling with continuous delivery. Because many of them don’t seem to be able to push code into production as quickly as the code can be built, the pace of innovation within IT environments is being stifled. As business leaders wonder why that pace of innovations has slowed, many of them are now demanding access to application delivery metrics.

It’s not clear to what degree providing access to those metrics will entice organizations to adopt a CDaaS platform. However, as developers and business leaders alike become more frustrated with the pace of application delivery, a groundswell for change is starting to build. Many IT leaders are now looking to automate as much of the application delivery process to prevent that frustration from morphing into a full-scale mutiny.

In the meantime, there’s an old adage that says things measured are things done. Not everyone may appreciate all the newfound attention being paid to key performance indicators for application delivery. However, the truth is most organizations are not going to ever really solve the application delivery conundrum until somebody starts producing relevant metrics that enable them to comprehend the true scope of the challenge.

— Mike Vizard

October 29, 2019
CNCF Advances CloudEvents Specification

In a move that portends well for future cloud interoperability initiatives, the Cloud Native Computing Foundation (CNCF) today announced that the open source CloudEvents specification for describing event data had achieved a version 1.0 milestone.

Doug Davis, senior technical staff member of IBM and co-chair of CNCF’s Serverless WG and the CloudEvents project, said CloudEvents will make it possible to not only define common attributes of an event to facilitate interoperability, but also make it easier to share those attributes between, for example, a repository such as GitHub and an application or tool that needs to consume those events.

With that foundation in place, it also should become easier to build tools spanning serverless and event-driven architectures, he added.

Work on the CloudEvents specification began in May 2018 as a sandbox project. With the release of CloudEvents 1.0, the CNCF Technical Oversight Committee (TOC) is now designating CloudEvents as an incubation project. Active contributors to the CloudEvents project include Amazon Web Services (AWS), Google, Microsoft, IBM, SAP, Red Hat and VMware. In fact, CloudEvents has already been implanted within the Eventing framework of Knative, an open source middleware project led by Google to integrate Kubernetes with various serverless computing frameworks. Other platforms that support CloudEvents include Microsoft Azure Event Grid, Red Hat EventFlow, Eclipse Vert.x and Debezium, SAP Kyma and the Event Gateway from Serverless.com.

Davis said given the level of support for CloudEvents project, there is reason to be optimistic for future cloud interoperability initiatives. Cloud interoperability has been hampered by a dizzying array of application programming interfaces that often are proprietary. CloudEvents represents one of the few interoperability projects that has drawn support from all the major cloud service providers. Part of the success CloudEvents has enjoyed in that regard can be attributed to the limited scope of the initiative, he noted.

It may be a while before organizations don’t have to worry about being locked into a cloud. However, as a general rule of thumb the more they focus on de facto specifications and application programming interfaces (APIs) exposed by platforms such as Kubernetes, the easier it will be to move applications from one platform to another. In many cases, DevOps teams today routinely struggle with moving applications that might have been developed on a public cloud onto an on-premises production environment. Longer term, it’s also expected IT leaders will want to be able to negotiate lower rates from cloud services providers by threatening to move workloads between cloud service providers.

In the meantime, as event-driven architectures such as serverless computing frameworks continue to become more popular, IT leaders can take some comfort in the fact that interoperability across these architectures is advancing. Of course, it’s too early to say when the CloudEvents specification will become a fully graduated CNCF project, but it is already apparent many cloud service providers are not waiting on that official recognition before implementing it. The challenge and opportunity for DevOps teams now are to figure out how best to employ this capability to create new applications that previously would have been too difficult even to attempt.

— Mike Vizard

October 28, 2019
Talend Aligns With Microsoft on DevOps

Talend has made its integration platform natively available on the Microsoft Azure cloud to provide DevOps teams employing Azure DevOps with an easier approach to creating pipelines and integrating data.

Vincent Lam, head of cloud product marketing for Talend, said the company is now making available 900 connectors and components to DevOps teams that use the continuous integration/continuous deployment (CI/CD) platform Microsoft offers as a service.

By providing deep hooks into the Azure platform, Lam says Talend is looking to make it easier for teams to build applications by relying on an integration platform-as-a-service (iPaaS) environment to access data stored in Microsoft cloud services such as Azure SQL Data Warehouse, Azure Databricks, Azure Data Lake Store and Azure HDInsight.

From a DevOps perspective, the Azure DevOps Orchestration engine has now been integrated with Talend’s zero-install continuous integration capability, which it created as part of an effort to integrate its integration service with CI/CD platforms such as Jenkins. That effort made it possible to leverage CI orchestration tools to automatically build unit tests and package Talend jobs in an artifact repository. That capability has now been extended to Azure DevOps.

Not every organization that uses Azure will employ Azure DevOps because they may have already standardized on another CI/CD platform, which they prefer to deploy and manage. However, because Azure lowers the barrier to entry for employing DevOps to build applications, Talend is now seeing a lot of demand for an iPaaS environment on Azure, Lam said.

Regardless of platform, as organizations start to build cloud-native applications based on microservices, many of them underestimate the integration challenges they will face. Each microservice has its own application programming interface that needs to be built and supported, which in turn is driving more convergence of DevOps platforms and iPaaS environments to help manage the APIs on which those microservices depend. As a result, IT organizations today need to apply more forethought to their overall API strategy, said Lam.

Talend is not the only provider of an integration platform to appreciate the role that DevOps processes and the rise of microservices are having on driving increased consumption of integration services. But it’s not clear whether access to integration services will become more democratized across IT organizations. Rather than continuing to rely on “centers of excellence” to centrally manage integration projects, many IT organizations have come to realize DevOps teams need to be able to access integration capabilities on demand. To facilitate that process, vendors such as Talend are making a concerted effort to couple integration platforms tightly with various DevOps platforms.

It remains to be seen to what degree integration platforms will remain standalone platforms versus becoming a capability to be invoked within the context of a CI/CD pipeline. Given the volume of monolithic applications that still depend on centrally managed integration platforms, it may be a while before the integration platform becomes subsumed in DevOps platforms. In the meantime, however, the line between DevOps and integration platforms will surely get more blurry.

— Mike Vizard

October 23, 2019
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

October 22, 2019
Survey: IT Striking Balance Between Innovation, Reliability

When it comes to managing IT, most DevOps teams are locked in an eternal struggle to balance innovation with reliability. There’s always a keen interest in being able to take advantage of the latest and greatest IT platform. However, new IT platforms don’t achieve the level of maturity required to build and deploy mission-critical applications overnight. Enterprise IT organizations often build an application on one platform and deploy it on another platform that is perceived to be more reliable.

But a global survey of 505 IT and other executives published by the Cloud Foundry Foundation (CFF) suggests that, at a time when adoption of microservices based on containers and serverless computing frameworks is rising, the need to strike a balance between innovation and reliability has never been more acute.

Conducted by ClearPath Strategies on behalf of the CFF, the survey finds serverless usage and container usage are now at 14% and 37% respectively. At the same time, adoption of platform-as-a-service (PaaS) environments such as Cloud Foundry has increased to 47% from 41% in the last six months.

The study also suggests the rate at which organizations are adopting serverless computing and containers is starting to plateau. However, organizations that have adopted serverless computing frameworks and containers are making greater use of these capabilities as they continue to mature, according to the survey results.

CFF CTO Chip Childers said it’s not uncommon for organizations now to deploy a PaaS and Kubernetes platforms alongside each other. In some cases, applications built using containers on a Cloud Foundry PaaS will be deployed on a Kubernetes run-time at the network edge. In other cases, applications built using development frameworks running on Kubernetes will be deployed on a Cloud Foundry PaaS that is perceived to be more reliable.

Of course, the percentage of organizations that are employing a PaaS environment is not nearly as high as those using a less opinionated framework for building applications. However, whatever the path chosen, Childers said multiple types of abstractions that simplify IT complexity will live alongside one another for many years to come. At the same time, the underlying technologies that enable those abstractions increasingly will converge. For example, the Cloud Foundry PaaS was built before Kubernetes existed. Now the CFF is moving toward replacing much of the Cloud Foundry substrate with Kubernetes.

According to the survey results, 65% of respondents place the most value on a platform that delivers a consistent experience. However, 59% also said a platform that integrates innovations is of the greatest value to their ability to develop software applications. In addition, almost two-thirds (63%) said a technology’s ability to integrate with their environment is the “touchstone” that makes technology better.

As is often the case, what constitutes a touchstone is in the eye of the beholder. However, DevOps teams are not likely to sacrifice reliability no matter how cool that next big thing in IT may or may not be.

— Mike Vizard

October 22, 2019
Virtual Instruments Changes Name to Virtana to Drive AIOps

With the formal launch of a software-as-a-service (SaaS) to monitor cloud platforms and optimize cloud, Virtual Instruments today renamed itself Virtana.

The company’s CloudWisdom platform is based on technology Virtana gained via the acquisition of Metricly earlier this year. In addition to being integrated with existing on-premises offerings from Virtana, CloudWisdom has been expanded to include a self-service option. Downloadable trial versions are also available.

Virtana CEO Philippe Vincent said the name change reflects a transformation from being simply a provider of storage I/O performance testing tools to becoming a provider of an IT operations management platform infused with artificial intelligence (AIOps). As part of that effort, the CloudWisdom offering represents the first time Virtana has extended the reach of its offerings beyond on-premises IT environments, he said.

CloudWisdom will differentiate itself, Vincent said, because it combines cloud monitoring with built-in tools for optimizing cloud costs. Rival offerings require IT organizations to acquire two separate services, he noted. The CloudWisdom platform monitoring capabilities span databases, messaging platforms and containers, as well as cloud infrastructure services from Amazon Web Services (AWS) and Microsoft.

In general, Vincent said IT organizations are moving away from a reactive approach to managing IT to a more proactive approach that will require increased reliance on automation. As IT environments become more complex, too many IT organizations are trying to compensate by overprovisioning IT infrastructure resources to make sure application performance doesn’t deteriorate or applications crash. That approach not only drives IT costs higher, he said, but it also makes those costs unpredictable.

To address that issue, Virtana is combining CloudWisdom with an AIOps platform designed to be equally applicable in legacy IT service management (ITSM) and emerging DevOps environments. Organizations that have adopted DevOps will be at the forefront of the transition to AIOps because of the inherent fluidity and velocity of those environments, Vincent noted. Machine learning algorithms coupled with real-time monitoring, big data analytics, workflow engines and automation frameworks will enable IT teams to streamline ITSM and DevOps processes to become more efficient. The opportunity for Virtana is to disrupt a highly fractured monitoring category by leveraging AIOps to unify monitoring at an unprecedented level of scale and scope, he added.

Virtana is not the only IT management platform provider that has identified the same opportunity; much larger incumbent providers of these platforms and a raft of startups are moving in the same AIOps direction. Vincent said Virtana will differentiate itself by pursuing a more application-centric approach to delivering on the promise of AIOps.

It’s too early to say to what degree IT operations can be automated using AI. There’s general agreement that AI will play a significant role in automating IT, and the more standardized the IT environment is, the easier it is to accomplish. The challenge is, most IT environments today are still anything but standardized.

— Mike Vizard

October 21, 2019
Survey Suggests DevOps Drives Digital Business Transformation
A survey published this week by New Relic, a provider of IT monitoring services, suggests there is a high correlation between organizations that have embarked on digital business transformation initiatives and adoption of best DevOps practices.

Revealed at the Futurestack conference hosted by New Relic, the survey 750 global senior IT decision-makers of enterprises with 500 to 5,000-plus employees in Australia, France, Germany, UK and the U.S. conducted by the market research firm Vanson Bourne finds roughly 50% of organizations in the U.S. have completed or are close to completing their digital transformation journeys.

The same survey finds nearly two-thirds of U.S. respondents in the region claim they’ve adopted DevOps practices.
Buddy Brewer, group vice president and general manager for client side analytics at New Relic, said the challenge most organizations face in terms of DevOps is they lack access to real-time analytics. DevOps teams may have access a raft of metrics, but all the data they have only tells them how many times something occurs on average. Roughly half of end users may be having a satisfactory application experience, but the half that are not are the company’s most important customers, noted Brewer.

Overall, the survey finds that that there’s nothing easy about modernizing IT environments to drive digital transformation initiatives. Nearly three-quarters (72%) expect the technology team to deliver more innovations and updates. However, more than 50% said they find their complex new software and infrastructure difficult to manage and monitor for performance issues.

Nearly half the respondents (48%) also admitted end users or customers are likely to tell them about a problem before they know about it and 46% said they are told about these issues before they know how to fix them.

At the same time, 79% said the rest of the business has higher expectations in how digital systems perform and 63% admitted that because of pressure to respond to business needs, they work longer hours to observe and manage software performance. Almost half (46%) said C-suite executives want daily updates about how software systems are performing and 40% said CEOs also want more answers when outages or performance problems happen.

More than half (56%) of all respondents acknowledged that it is impossible to properly assess all the machine data being collected. Just as troubling, a third said they are challenged on business benefit metrics for their digital transformation projects.

The survey identifies the top five digital transformation challenges:
1. Separate parts of the organization are moving at different speeds to embrace digital transformation.
2. Shortage of skilled employees.
3. Restricted budgets.
4. Understanding and measuring business benefits.
5. Continued resistance to shutting down legacy systems.
As always in the case of IT professionals, however, hope springs eternal. A full 89% said they believe artificial intelligence and machine learning algorithms will become important element for managing digital systems. That may indeed come about one day. However, until that day arrives, DevOps teams should count on the fact that every digital business transformation project that gets launched equates to a lot more hard work for them.

— Mike Vizard
October 18, 2019
Anaxi Adds Reporting Capabilities to ALM Tool

Anaxi today announced it has added reporting capabilities to its namesake application lifecycle management (ALM) tool that make it possible to update stakeholders about the status of software development projects residing in repositories such as GitHub and Bitbucket Cloud as well as project management applications such as Jira.

Company CEO Marc Verstaen said reporting capabilities will make it easier to employ Anaxi to, for example, keep business leaders apprised of updates to software development initiatives by enabling IT leaders to generate a report similar to how business leaders today employ a business intelligence (BI) application to share sales forecasts.

The Anaxi tool is designed to provide IT leaders with a single tool for tracking progress being made across multiple DevOps platforms. Verstaen said as more organizations begin to realize they are really software companies, interest in software delivery management tools is on the rise. The reporting challenge IT leaders face is the information they need to create a holistic report lies in multiple repositories because of the inherently fragmented nature of the DevOps tool chain, he said.

To make it easier to adopt Anaxi, the ALM tool Data employs the same credentials organizations have created to access GitHub, Bitbucket and Jira. The Anaxi app connects directly to a user’s GitHub or Bitbucket repositories and Jira projects to ensure data privacy and security. Any action performed on the Anaxi applications is written back on GitHub, Bitbucket and Jira to maintain consistency across projects involving multiple team members.

At its core, Anaxi is pulling metadata from DevOps tools to apply analytics to track individual developer productivity and team performance. IT leaders can, for example, analyze how much code has been added and removed, refactoring and code churn on a weekly basis. Anaxi can be used either in place of a project management application or as a complement to an existing project management tool to make analytics more accessible.

The primary goal is to make it easier for IT leaders to identify DevOps bottlenecks and prioritize projects in a way that advances business goals. Too many organizations are writing more code than ever only to discover projects are being held up because a single component on which every other module depends is behind schedule. Many of the developers writing that code could have been working on other projects if IT leaders had been made aware of changes that needed to be made to the schedule based on the anticipated delay to another project. Anaxi essentially applies predictive analytics to software development projects to determine based on past histories the likelihood of a deadline being met, Verstaen said.

Armed with that intelligence, IT leaders can either proactively reallocate how resources or allocated or inform business stakeholders to changes in delivery schedules. In either case, Versaten says the goal is to enable IT leaders to avert any software development crisis that might arise.

The Anaxi app is free to use by teams of up to 10 members. Teams of more than 10 users will be required to adopt a premium plan priced at $19 per month per user.

— Mike Vizard

October 17, 2019
DevOps Deeper Dive: DevOps Accelerates Open Source Innovation Pace

In the span of a few short years, open source software has evolved from being a means to create the free equivalent of an existing commercial platform to now becoming the primary means of driving innovation across the IT industry.

That rate of innovation has increased dramatically in the last few years. However, much of that innovation would not have been possible if large swaths of the open source community hadn’t been able to employ best DevOps practices to collaborate, said CloudBees CEO Sacha Labourey.

Early on, the adoption of open source software was driven by a desire to commoditize operating systems and databases by making available a free equivalent.

“It was all about replacement software,” said Labourey.

Open source adoption got a major boost in the enterprise during the last economic downturn. Many organizations implemented an “open source first” strategy to lower their IT acquisition costs. As part of that mandate, developers began making greater use of cloud infrastructure to build applications based on an open source stack of software using best DevOps practices.

In some cases, that preference for open source software turned into religious fervor. In other cases, it simply became a means to bypass IT purchasing processes that developers considered obstacles to writing code. Of course, it was only a matter of time before the open source software used to build applications made its way into production environments managed by IT operations teams.

Just as significantly, open source software was leveraged to build public clouds that today are transforming the way IT is consumed.

None of this shift has been lost on IT vendors. As the demand for proprietary code slackened, many found it profitable to offer support services for open source software. The more there is to consume, the more the support services contracts grew. Now every vendor from IBM to small IT services providers such as Fairwinds has launched open source projects that help drive demand for IT services expertise.

“There’s pain around integrating a lot of disparate open source projects,” said Robert Brennan, director of open source software for Fairwinds. “Organizations may be getting software for free, but there’s usually not a lot of help around.”

Now almost every IT vendor in the world is making software engineers available to work on open source projects. All that talent focused on open source projects has led to the development of new platforms such as Jenkins, GitHub, Kubernetes and, more recently, a raft of smaller projects. With the rise of containers and cloud-native applications, open source software projects are entering another era that will see many of those same software engineers leveraging DevOps practices more broadly to drive even more innovative projects at increasingly faster rates.

“All the innovation is now being driven by open source,” said Joe Fernandes, vice president, products for cloud platforms at Red Hat. “You no longer have to wait for a single vendor to move something forward.”

The challenge many organizations now face is keeping pace with the rate of innovation. Most major open source projects, thanks to DevOps practices, are updated once a week. To shield themselves from having to work with raw bits of code, many IT organizations rely on curated distributions of open source code from vendors such as Canonical, SUSE and Red Hat.

Today, the economics of software development have changed. Providers of proprietary software are at a distinct disadvantage when competing against open source projects that can marshal more developer resources. A vendor selling proprietary software needs to keep a smaller team of developers highly focused on adding compelling, innovative features faster than an open source project can replicate them. As many vendors continue to show, that goal isn’t impossible to achieve; however, it is a pace of innovation that is exceedingly difficult to maintain.

It remains to be seen just how much of the software deployed in IT environments will be based on open source code going forward. But with each passing day, the balance on the scale continues to lean further away from proprietary code.

— Mike Vizard

October 16, 2019
OpenLegacy Partners With Compuware to Advance DevOps on Mainframes

OpenLegacy has allied with Compuware to make it easier to build and debug microservices-based applications employing REST application programming interfaces (APIs) to access data residing on mainframes.

Zeev Avidan, chief product officer for OpenLegacy, said the company’s namesake platform analyzes mainframe environments to create microservices-based APIs written in Java without requiring any changes to the legacy environment. That approach not only minimizes disruption to the mainframe environment, but it also eliminates the need to rely on enterprise service bus (ESB) platforms and legacy web services interfaces to access mainframe data, he said.

The alliance with Compuware now makes it easier access the OpenLegacy platform from within Topaz Workbench, a set of tools from Compuware that are used to apply DevOps practices to applications that either run on a mainframe or need to access data residing on a mainframe.

Avidan said it is becoming increasingly common for organizations to want to build and deploy applications that need to access mainframe data as part of various digital business transformation initiatives. The challenge they face is that most legacy monolithic applications running on a mainframe don’t have an API to invoke. OpenLegacy provides a framework for generating those APIs, which in turn makes it easier to incorporate mainframes within the context of a larger DevOps process. The alliance with Compuware furthers an ongoing effort by the two companies to foster the adoption of best DevOps processes in mainframe environments, he said.

Legacy waterfall-based application development processes are still relevant in mainframe environments, he added, but it’s also clear organizations want to apply DevOps processes to applications spanning hybrid environments that include mainframes. The majority of data in many enterprise IT environments is created on a mainframe. Rather than being forced to copy that data, API platforms such as OpenLegacy make that data more accessible where it resides. Once the APIs are in place, it becomes practical for DevOps teams to create software development kits (SDKs) to access various applications running on mainframes, Avidan said.

Organizations that have invested in mainframes generally are interested in agile development methodologies that enable them to derive more value from those investments. The challenge they face is finding a way to make that data available in a way that doesn’t disrupt the mission-critical applications running on the mainframe, he said. Over time, IT organizations running mainframes will adapt their processes to incorporate best DevOps practices, but the level of disruption they can embrace in pursuit of that goal has to be minimized, Avidan noted, adding it would be unreasonable to expect that level of cultural change to occur overnight.

Despite ongoing predictions about the eventual demise of the mainframe, the number of workloads running on the venerable platform continues to increase, thanks in part to the ability to run Linux on a mainframe. What many organizations that opt to run Linux on a mainframe don’t always initially appreciate is the degree to which that decision also opens the door to transforming their internal IT culture, regardless of whether they are ready.

— Mike Vizard

October 9, 2019