devopsy.kinsta.cloud

Author: Mike Vizard

DevOps Deeper Dive: SUSE Sets DevOps Course

There was a time when SUSE was considered to be the second-biggest force driving the adoption of Linux in the enterprise, after Red Hat. Then came an odyssey to rival any epic written by Homer. A few short years after moving its corporate headquarters from Germany to Oakland, California, the company was sold to Novell, which was then later acquired by Attachmate. Three years later, Attachmate was acquired by Micro Focus. Three years after that, SUSE (as an arm of Micro Focus) acquired distributions of OpenStack and the Cloud Foundry platform-as-a-service (PaaS) from Hewlett-Packard Enterprise (HPE).

That brings us to 2018, when SUSE was spun out of Micro Focus to become an independent company once again, headquartered in Germany once again. A year later Melissa Di Donato, formerly chief operating officer (COO) of SAP, was named CEO of SUSE. A few months after that, SUSE announced it would withdraw its distribution of OpenStack from the market to focus its efforts on emerging cloud-native opportunities stemming from the rise of Kubernetes.

For SUSE, those opportunities arise from a distribution of Kubernetes deployed on its Linux operating system, which also serves as the foundation for its container-as-a-service (CaaS) environment, along with a version of Cloud Foundry deployed on top of Kubernetes.

Brent Schroeder, global CTO for SUSE, said his company’s strategy is being driven by an acute need for increased flexibility. IT environments are inherently becoming hybrid as more workloads move to the public cloud, and many organizations will want to leverage a common substrate based on Kubernetes for building and deploying applications. In some instances, Kubernetes will be deployed on top of virtual machines, while in other use cases Kubernetes will be deployed on bare-metal servers. IT organizations will then decide to deploy a CaaS or PaaS depending on their requirements, said Schroeder, noting that regardless of the path chosen, IT modernization initiatives will create a significant opportunity for SUSE.

“Virtual machines, bare-metal and the cloud will be a huge catalyst,” said Schroeder.

DevOps, of course, is playing a major role in driving those transitions, which Schroeder said has become a major focus for SUSE as organizations think through how to not just build and deploy applications faster, but also secure and govern those processes. That latest version of SUSE CaaS Platform 4, for example, added support for Cilium open source project for securing network connectivity between containerized application services.

Of course, SUSE is not the only IT vendor making this journey. Red Hat was the first to deploy a PaaS environment on top of Kubernetes and since then has been on a mission to obliterate the distinction between a CaaS and a PaaS environment. As an arm of IBM, Red Hat has also significantly expanded its market research as IBM builds out a hybrid cloud computing strategy based on the Red Hat OpenShift platform.

Of course, Red Hat’s acquisition by IBM might create new opportunities for SUSE. After all, more than a few of the IT organizations that opted to embrace Red Hat OpenShift had plenty of opportunities to consider alternatives from IBM. Now that the acquisition has been finalized, some of them may be reconsidering their options.

It’s too early to say when SUSE might arrive at its ultimate destination. When venture capitalists buy a company such as SUSE the goal is to either take the company public or recoup the investment by selling it to another entity. Whatever the outcome, it’s clear SUSE intends to leave its mark in the brave new world of containerized applications.

— Mike Vizard

November 11, 2019
CNCF Advances Jaeger Distributed Tracing Project

The open source Jaeger distributed tracing platform has officially graduated into the top tier of projects being stewarded by the Cloud Native Computing Foundation (CNCF).

Designed to be employed within any DevOps environment, Jaeger is a tool for monitoring transactions across complex distributed computing environments. It consists of a backend for trace collection and analysis and multiple client libraries implementing the OpenTracing application programming interface (API) in various languages.

Developed by Uber, Jaeger now integrates with tools such as OpenTracing, OpenTelemetry, Envoy and Prometheus to make it easier to discover the root cause of issues impacting transactions in complex IT environments. For example, DevOps teams can apply data mining techniques and machine learning algorithms to analyze data from a specific cluster.

Yuri Shkuro, a software engineer for Uber who works on the Jaeger project, said organizations may rely on tools such as Prometheus to monitor environments, but once an issue is identified, it typically takes a tool such as Jaeger to identify the root causes of an issue. The primary reason for that approach is the amount of data that distributed tracing tools would store if they were to run continuously, he said.

Organizations that are already using Jaeger in production environments include GrafanaLabs, Northwestern Mutual, SeatGeek, Symantec, Ticketmaster, Uber, Weaveworks and Zenly.

Jaeger is also starting to be bundled with other platforms, such as the Red Hat OpenShift Service Mesh. As that trend continues, more organizations are likely to become exposed to Jaeger as a tool for debugging a wide variety of issues.

Although originally developed to address the inherent complexity associated with microservices, Jaeger also can be applied to monolithic applications, Shkuro said. While many of those monolithic applications eventually are likely to be deconstructed into a set of microservices, many of those applications are not going away anytime soon, he noted.

Jaeger now has 15 active maintainers from four companies, with more than 1,200 contributors and 375 authors of commits and pull requests. It also has more than 9,000 GitHub stars and has been pulled from Docker Hub more than 10 million times.

While distributed tracing as a concept has been around for a while, the rise of microservices is forcing IT teams to look for tools that make it possible to engage in deeper forensics. The dependencies between microservices coupled with the ephemeral nature of containers often make it challenging for IT organizations to discover the root cause of intermittent issues. Within IT environments that have adopted Kubernetes to run those containers, it’s also become easier to deploy Jaeger using tools as Kubernetes templates, Operator software and a Helm Chart.

As developers are held more accountable for applications, interest in programmable forensics tools is rising. Performance issues that developers once viewed as a problem to be solved by faceless IT operations staffs are now being solved much faster by developers. As a result, application experiences have improved now that developers are seeking out tools such as Jaeger to identify issues that are preventing them from focusing their efforts on writing additional code. Given the long, difficult history of IT, there are more than a few IT leaders wondering what took them so long to figure that out.

— Mike Vizard

November 8, 2019
Eficode Adds Analytics to Managed DevOps Service

Eficode has added an analytics module to a DevOps platform it makes available as a managed service.

Tuomas Keränen, product manager for Eficode ROOT, said Eficode ROOT Insights provides different types of end users with access to an analytics module designed to make it easier to understand how changes to a software development project will impact delivery timetables. To make that capability more accessible throughout the organization, Eficode has created dashboards for specific types of end users such as project managers.

Eficode has crafted a DevOps platform from various tools and platforms to create a toolchain based on best practices it has defined that the company then manages on behalf of end customers. Organizations can choose to have that DevOps platform hosted on-premises or in a public cloud. That approach frees organizations to devote more time and resources to building applications versus managing the DevOps platforms, said Keränen. Eficode ROOT Insights is provided as a complement software-as-a-service (SaaS) application.

As DevOps continues to evolve, it’s apparent that an alternative approach that relies on external IT service providers to manage the underlying platforms is gaining traction. Many IT organizations simply don’t have the expertise required to build and maintain a DevOps platform. The trade-off is that the best practices are defined by the external service provider, which means the IT organization needs to bend its culture to align with those best practices.

Another factor that potentially will push organizations toward managed DevOps services is analytics. As the amount of data that needs to be collected to drive analytics applications steadily increases, it becomes apparent that DevOps analytics applications are going to be invoked more easily as SaaS applications. Once an IT organization moves down that path, it’s not too long before the case is made for using the analytics platform to also host the DevOps platform. In addition, as machine learning algorithms and other forms of artificial intelligence (AI) are applied to DevOps, the volume of data required to drive an AI model may require an organization to rely more on external service providers to provide that expertise.

It’s not at all clear how many organizations may prefer a managed service approach to DevOps. Many of the earlier adopters of DevOps have built custom workflows that are designed specifically to optimize their software development life cycle. However, the adoption of DevOps has been uneven at best. As managed DevOps services proliferate, the number of organizations that can effectively embrace DevOps should increase significantly.

Of course, managing the tension between internal and external IT service providers is nothing new. However, given the complexity of DevOps processes, relying on a managed service requires a level of collaboration that is not easy to achieve. Just as importantly, once an organization decides to partner with a provider of a managed DevOps service, unraveling that relationship later may prove to be all but impossible.

— Mike Vizard

November 8, 2019
Microsoft Extends Azure Reach to On-Premises IT Environs

Microsoft today at its Ignite 2019 conference previewed an Azure Arc management service that extends the reach of the Microsoft cloud to on-premises IT deployments.

Azure Arc will be made available on both local Windows and Linux servers as well as Kubernetes clusters or an instance of Kubernetes that Microsoft is making available on Azure Stack for on-premises IT environments. With these announcements, Microsoft is, for the first time, extending its hybrid cloud computing strategy beyond systems running a version of the Azure operating environment on an on-premises IT environment.

Jason Zander, executive vice president for Microsoft Azure, told conference attendees Azure Arc creates an opportunity for IT organizations to extend the best DevOps and cloud management practices employed on Azure to on-premises IT environments. Rival cloud service providers, he noted, are only paying lip service to hybrid cloud computing.

In addition to extending the Azure management plane to on-premises IT environments, Microsoft today extended its portfolio of edge computing platforms capable of running instances of Azure Stack to include previews of commercial series and rugged series for Azure Stack Edge. Configurable with graphical processor units and field-programmable gate arrays (FPGAs) capable of running machine learning algorithms in harsh environments, the ruggedized instance of Azure Stack Edge even includes a portable server designed to be carried in a backpack.

To complement those systems, Microsoft is also previewing a range of additional services for Azure Stack, including a fully managed, real-time data ingestion service designed to stream millions of events per second from any source to build data pipelines the same way the company does on the Azure cloud; a cloud database management service for Microsoft SQL Server and Postgres; and an Arc-enabled application programming interface (API) management platform.

While Microsoft generally would prefer organizations to adopt Azure Stack as an on-premises extension to Azure cloud, not many organizations have the robust modern server infrastructure in place required to run Azure Stack. Azure Arc is an effort to extend the reach of Azure to multiple types of edge computing platforms without requiring organizations to deploy yet another operating system. Alternatively, organizations can employ a diverse range of Kubernetes distributions, of which there are now more than 70 that have been certified by the Cloud Native Computing Foundation (CNCF). Most organizations at this stage have yet to standardize on a single distribution of Kubernetes.

It’s unclear what the appetite is for extending the management plane Microsoft created for its Azure cloud to on-premises environments. However, as the scope of the hybrid cloud management challenge facing organizations grows as various new forms of edge computing manifest, Microsoft clearly sees an opportunity to increase the scope and reach of its cloud platform strategy. Each edge computing instance is essentially a smaller instance of a cloud platform for which most IT organizations will not have the tools required to manage at scale. In fact, many IT organizations might not even attempt to deploy workloads at all on those platforms without something equivalent to Azure Arc to manage and secure those environment first being in place.

— Mike Vizard

November 4, 2019
New Relic Bolsters Serverless Monitoring Strategy

New Relic has strengthened its ability to monitor serverless computing frameworks by acquiring IOpipe, a provider of a monitoring tool for the serverless computing framework service provided by Amazon Web Services (AWS).

Andrew Tunall, general manager for serverless and emerging cloud services at New Relic, said IOpipe’s monitoring technology will be used to augment the monitoring tool for AWS Lambda included in the New Relic One platform, which was launched earlier this year.

New Relic also plans to expand its observability capabilities for serverless computing to other platforms based on customer demand, said Tunall.

Serverless computing frameworks are gaining traction because they enable developers to write less code within their applications by allowing them to employ functions to call on a cloud service to process, for example, analytics externally rather than within the application itself. The challenge serverless computing frameworks create from a DevOps perspective is they don’t create any logs that can be analyzed. Instead, monitoring tools need to be able to employ distributed tracing tools to analyze the streams of metadata that serverless computing frameworks create based on event-driven architectures. That requirement has forced providers of monitoring tools to extend the capabilities of their core platform to enable the consumption of that metadata.

Adoption of serverless computing frameworks is already outpacing the ability of many DevOps teams to observe. According to AWS, hundreds of thousands of customers are already doing trillions of invocations a month of AWS Lambda. Gartner has predicted that by 2023, 100% of enterprises using IaaS or public cloud will also use some form of serverless platform-as-a-service (PaaS) capability in production applications, up from 25% in 2019. In most cases, those serverless computing frameworks will be employed to process stateless workloads, while stateful workloads continue to run on a virtual machine or within a container.

While most of the usage of serverless computing frameworks thus far is on public clouds, it’s only a matter of time before organizations increasingly make use of multiple serverless computing frameworks in on-premises IT environments. There are already more than a dozen different types of serverless computing frameworks, most of which are being made available as open source projects.

Naturally, the rise of serverless computing frameworks complicates DevOps even further. DevOps teams will now need to build, deploy and update applications that are making frequent external application programming interface (API) calls to potentially multiple serverless computing frameworks. Rather than requiring organizations to acquire separate tools to monitor serverless computing frameworks, New Relic is making a case for extending a single platform to monitor all the various types of IT platforms being employed.

There’s almost no doubt most organizations will wind up invoking serverless computing frameworks in one fashion or another, but it’s too early to say how pervasive serverless computing frameworks will be. However, DevOps teams will be required to monitor those serverless computing frameworks alongside every other platform already being employed across an increasingly diverse IT environment.

— Mike Vizard

November 4, 2019
Survey Surfaces Uneven Approaches to DevSecOps

A ZeroNorth survey shows implementing DevSecOps is rife with questions for many organizations, with no clear answers

There’s general agreement that digital business transformation initiatives are driving an overall acceleration in the rate at which applications are developed. At the same time, however, given the critical nature of those applications, cybersecurity has never been more of an imperative for DevOps teams. The challenge they are encountering is not so much a lack of tools to address that requirement, but rather a lack of clarity in terms of what tool to use when.

A survey of 57 cybersecurity professionals conducted by ZeroNorth, a provider of a platform for orchestrating vulnerability scanning tools, highlights the extent of the DevSecOps challenge. The survey finds 63% of respondents said their organization currently employs six or more scanning tools. The most widely employed are network scanning (53%) and vulnerability scanning (51%). However, a quarter (25%) don’t know if their organization is using interactive application security testing (IAST), while 19% don’t know if they are using software composition analysis (SCA) tools.

As far as DevSecOps is concerned, there’s little to no clarity in terms of where to primarily focus scanning efforts. Build/CI environments (68%) receive the most focus, but 46% are focused on scanning within integrated development environments (IDEs). Container/artifact management (67%), source code repositories (58%) and deployment (56%) all fall somewhere in between, the survey finds.

There’s also no clear consensus on the merits of open source versus commercial testing tools Open source software (OSS) tools were identified as a priority for less than half of respondents (47%). However, 27% of respondents said they expect to begin using open source tools in 2020. Of the respondents currently employing OSS tools, 14% said believe these tools are more effective than commercial test and scan tools. Well over a third (39%) said they believe they are more effective when combined or customized. Just under a third (32%) said OSS tools are equally as effective as commercial options, while only 9% said they are less effective.

The survey also shows disparity when it comes to the various areas that make up a digital business transformation, with the most mature being cloud migration (80%), followed by DevOps (67%), continuous integration/continuous delivery (CI/CD) (62%) and microservices (62%). Overall, 79% of respondents said they have a digital business initiative underway.

ZeroNorth CTO John Steven said it’s clear that in many cases, the need for faster iterations of application development is outpacing the operational capabilities of IT organizations, especially when it comes to DevSecOps. Given the chronic shortage of cybersecurity professionals, there may be an average of only one cybersecurity professional for every 100 developers. Having cybersecurity professionals participate in every scrum session isn’t feasible, so there needs to be a way for cybersecurity professionals to provide guidance to developers specifically when it comes to what scanning tool should be applied and when, said Steven.

The survey finds network (53%) and vulnerability (51%) scanning are the most broadly employed. However, that also suggests that many IT teams involved in digital business transformation initiatives are not making use of scanning at all.

The good news is that survey respondents said identifying bugs, flaws and vulnerabilities throughout the software development life cycle (SDLC) is either “extremely” (58%) or “very” (42%) important to all participants involved. A total of 47% said it was either “extremely important” or “very important (35%) to improve visibility around operations by integrating security earlier into the software development life cycle (SDLC). However, while the DevSecOps spirit may be willing, the ability to implement best DevSecOps practices is still clearly weak.

— Mike Vizard

November 4, 2019
Report: More Salesforce Customers Adopting DevOps

A survey of 201 executives who work in organizations that have adopted the Salesforce Lightning platform finds a surprising number are employing DevOps practices to customize Salesforce software-as-a-service (SaaS) applications.

Conducted by Beagle Research Group on behalf of Copado, a provider of a commercial continuous integration/continuous delivery (CI/CD) platform for Salesforce SaaS environments, the survey finds 48% are using open source platforms to drive those DevOps processes, while 26% are relying primarily on in-house developed CI/CD toolchains. Another 36% are using commercial platforms developed for the Salesforce platform.

Andrew Leigh, senior vice president of marketing for Copado, said DevOps has gained traction in Salesforce application environments because most digital business initiatives revolve around customer records and marketing applications. As organizations attempt to drive new digital customer experiences, they find they need to frequently update what have become highly customized SaaS applications.

Many of those organizations are surprisingly agile. A quarter (25%) said they release code to their Salesforce production environment multiple times per day, while another 29% said they can implement changes in less than one day. More than half (53%), however, said deployment can take between a day and a week.

Ambitions in terms of DevOps capabilities are running high. A total of 19% want to be able to deploy multiple times per day; while another 16% would like to release between once per hour and once per day. One-third (33%) want to able to at least be able to release customizations once per day to once per week.

More than half, (54%) said their lead time for making changes to their Salesforce environment is between one day and a week. However, 21% said lead time is less than a day and 8% said they need less than an hour. Collectively, 83% said they can make changes in a week or less.

Overall, 77% described their Salesforce DevOps strategy as being as mature as the DevOps strategies for other technologies in their companies. However, only 42% are consistently employing automation to drive DevOps processes.

Like most organizations that have adopted DevOps, it doesn’t appear customers who rely on Salesforce are immune from their share of DevOps issues. Almost half (43%) said they have performance problems after a deployment up to 15% of the time. Only 2% said they had issues between 76% and 100% of the time. One-fifth (21%) said the time to restore service levels is less than an hour, while 43% said it could take up to a day to rectify an issue.

As far as future plans are concerned, the top three priorities identified by survey participants are increased speed to market and increased developer productivity (tied for first place), making applications more customer-relevant and continued innovation (tied for second place) and increased employee satisfaction and release quality (tied for third place).

Salesforce may not be getting its full due for being a provider of a SaaS platform for building customized applications. However, it is clear that most Salesforce customers have come to recognize that SaaS applications are just another type of platform for building and deploying customized applications using best DevOps processes.

— Mike Vizard

November 1, 2019
CircleCI Achieves SOC 2 Compliance for DevOps Platform

CircleCI has achieved a SOC 2 compliance rating for the DevOps platform it makes available via a software-as-a-service (SaaS) model.

Tad Whitaker, security manager at CircleCI, said CircleCI is the first provider of a SaaS platform for DevOps that has invested the hundreds of thousands of dollars required to achieve SOC 2 compliance.

SOC 2 compliance requires organizations to pass an annual audit based on the Trust Services principles and criteria defined by the American Institute of Certified Public Accountants (AICPA). That criteria evaluate IT environments on everything from the cybersecurity controls they have in place to the integrity of the data management processes employed. A SOC 2-level certification means DevOps teams can have confidence in the fact that their data is being kept completely confidential, said Whitaker.

With interest in best DevSecOps processes on the rise, Whitaker noted more organizations are starting to ask questions about how data is managed and secured on the cloud services they rely on to build and deploy applications. Cybersecurity professionals who are now participating in those processes are starting to ask challenging questions. To address those concerns, Whitaker said CircleCI created a team within the company to first attain SOC 2 compliance and, now, maintain it.

That may lead to additional processes and controls being put in place, but DevOps teams can be confident that everything possible is being done to secure their data from prying eyes, including employees of CircleCI.

A lot of the data being employed to build new applications is among the most sensitive an organization is likely to possess. As organizations embrace DevOps practices to drive digital business transformation initiatives, there’s a much greater need to ensure the DevOps environment is secure end to end. However, most of the DevOps platforms delivered as a service today are not able to validate the level of security they claim to have put in place, said Whitaker.

It’s unclear how many organizations are going to insist of SOC 2-level certifications before agreeing to develop applications on a specific DevOps platform. However, SOC 2-level certifications are routinely required for cloud service providers so it’s only a matter of time before the same audit requirements are applied to other cloud services. The challenge will come when DevOps teams have to adjust their existing DevOps processes to accommodate the security processes that SOC 2-compliant cloud service providers are required to make.

In the meantime, the days when DevOps teams could employ cloud services to bypass cybersecurity policies are coming to an end. Cybersecurity teams are finally catching up in terms of figuring out how to enforce cybersecurity policies beyond an on-premises IT environment. Not every DevOps team may appreciate the impact those policies may have on productivity. However, if the alternative is to have sensitive data that DevOps teams are now being held accountable for exposed on the web because of careless processes than the time to come to terms with cybersecurity has finally come.

— Mike Vizard

October 31, 2019
Red Hat Launches Holistic DevOps Training Initiative

Red Hat this week announced it has created a Global Transformation Office focused on bringing about digital transformation via broad adoption of best DevOps practices.

The Global Transformation Office initiative is comprised of Andrew Clay Shafer, vice president of transformation at Red Hat; Jabe Bloom, chief sociotechnical officer for PraxisFlow; Kevin Behr, general manager and chief science officer at PraxisFlow; and John Willis, CEO of Botchagalupe Technologies.

Shafer said Red Hat is trying to encourage organizations to take a more holistic approach to transformation by simultaneously addressing the need to understand how new technologies impact the organization in terms of skills required and the business model around which the organization is built.

Instead of focusing solely on IT skills, Shafer said the Global Transformation Office at Red Hat is also seeking to educate line of business executives how to engage with DevOps teams to advance digital transformation initiatives, many of which never come to fruition because the IT teams working on those projects don’t know what the end business goal really is. If line-of-business executives can communicate that goal in a way DevOps teams can appreciate, they soon discover how much faster those DevOps teams will be able to drive the organization toward that desired outcome, he said.

Rather than simply telling IT teams they will have a new role, Shafer said business leaders need to back up those claims by investing in training. Otherwise, IT professionals who today often associate their identity within an organization to the process they manage will resist that transition out of fear of losing their position. Right now, too many organizations are also asking IT teams to embrace DevOps without ever really informing DevOps teams why any given project matters to the business strategy, added Shafer.

Red Hat is investing in this initiative because the amount of demand for enabling technologies such as the Red Hat OpenShift application development platform will be constrained unless business and IT models evolve in tandem. It makes no sense for organizations to embrace containers only to try managing them using the same processes they previously employed to manage virtual machines and bare-metal servers, said Shafer. Organizations need to realize they will not get the maximum value out of such platforms unless they have the skills and expertise needed to apply them within the context of achieving a business goal, he added. In many cases, organizations may need to reorganize themselves because too many business leaders still value themselves in terms of the size of the organization they lead instead of the contribution the business unit makes to the company.

It’s not clear to what degree the DevOps tail may be able to wag the business dog. In many ways, it’s only a matter of time before the business needs to be reorganized in a way that makes it as agile as DevOps teams are becoming. The real question is how long that transition will occur. Of course, many organizations that don’t make that cultural DevOps transition won’t be around to find out how it all turns out.

— Mike Vizard

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

October 30, 2019