devopsy.kinsta.cloud

Author: Mike Vizard

Instana Rolls Up 3 Acquisitions to Extend APM Reach

Instana revealed today it has acquired three technologies that will extend the capabilities of an application performance management (APM) platform optimized for microservices-based applications.

Capabilities being added to the Instana platform include StackImpact, a polyglot production application profiler developed by StackImpact GmbH that can be applied to applications built in multiple languages; a high-frequency metrics analysis tool developed by BeeInstant; and a tool for analyzing complex system signals developed by JINSPIRED B.V.

Instana has acquired StackImpact and BeeInstant outright and acquired only the software JINSPIRED B.V developed.

Instana CEO Mirko Novakovic said that as organizations embrace microservices typically built using containers that get deployed on Kubernetes clusters, IT organizations are discovering their existing APM platforms are not able to monitor and observe microservices-based applications to the level of depth required.

The Instana APM platform achieves that goal by automatically deploying monitoring sensors for each part of the application technology stack. Those sensors trace all application requests without requiring any configuration or application restarts. Instana also detects changes in the application environment that allow it to adjust models and visualizations in real-time.

As IT organizations embrace the Instana APM platform to manage microservices-based applications, Novakovic said they discover they can employ Instana also to monitor legacy monolithic applications, enabling them to standardize on one APM platform. Instana currently claims more than 300 customers, most of which are using its APM to monitor multiple types of application workloads, he said.

In general, Novakovic said it’s becoming easier for organizations to swap out APM platforms because the proprietary agents that many legacy APM platforms rely on are being replaced by open source initiatives that make it possible to gather metrics from multiple platforms. In fact, as APM platforms continue to evolve, Novakovic said it’s apparent that tools for tracing, tracking metrics and log analytics are all starting to converge.

Of course, the biggest challenge Instana and other providers of APM platforms face today is that many developers are relying on open source Prometheus software developed under the auspices of the Cloud Native Computing Foundation (CNCF). Instana and other APM platform providers are making a case instead for commercial platforms that provide richer visualizations and are easier to employ than Prometheus.

It’s still too early to say how the APM platform wars might play out. However, all the dependencies between microservices make APM platforms a requirement today. Historically, many IT organizations have opted to make use of APM platforms only for their most mission-critical monolithic applications because of the costs involved. Many organizations going forward are likely to try to strike a balance between APM costs and the need to monitor application services more broadly.

Naturally, different DevOps teams within an organization may wind up preferring to employ different APM platforms. However, the pressure to standardize on a single APM platform to contain costs will only increase over time.

— Mike Vizard

December 17, 2019
DataStax to Support Multiple Distributions of Cassandra

DataStax today announced it will provide support services for any distribution of the open source Cassandra database via a subscription offering dubbed DataStax Luna.

The company also announced it has made available two additional free tools in the form of DataStax Apache Kafka Connector for integrating Cassandra with the open source real-time streaming engine, and Bulk Loader to make loading and unloading data into Cassandra faster and simpler.

Based on a wide column store architecture, Cassandra has emerged as a popular NoSQL alternative to traditional distributed databases because the column store on which Cassandra is based can also be organized into rows made up of multiple columns.

Previously, DataStax only supported its own distribution of Cassandra alongside an enterprise variant through which it makes available additional features. There’s also a managed service, available in beta, through which DataStax will run Cassandra on a public cloud on behalf of customers.

Created at Facebook, Cassandra is currently maintained under the auspices of the Apache Software Foundation (ASF). DataStax was subsequently created to provide a curated distribution of Cassandra alongside the distribution made available by ASF. Cassandra also makes use of Cassandra Query Language (CQL) as an alternative to SQL for processing queries. DataStax is now the largest contributor of code to the upstream Cassandra project.

DataStax CTO Jonathan Ellis said that as the adoption of Cassandra has increased, there is now enough critical mass of multiple distributions of Cassandra to support. DataStax is now offering support via community and enterprise editions of DataStax Luna.

Adoption of DataStax largely has been driven by developers. However, as the number of instances of Cassandra deployed increases, IT teams are finding they don’t have the expertise required to manage yet another database platform on their own. DataStax Luna provides a subscription service through which IT teams can rely on support from DataStax regardless of what distribution or version number of Cassandra they are running, said Ellis.

In many cases, Cassandra databases are being managed by DevOps teams rather than traditional database administrators (DBAs). However, it’s not clear whether more DBAs will be expanding their roles to include managing alternatives to traditional relational databases. Many organizations are now coming to terms with the need to support multiple types of databases. In fact, in many cases, the management of databases on which modern applications are built has been incorporated into a larger DevOps team.

Regardless of who manages the database, Ellis said the most important thing for any organization embracing Cassandra to understand its data model. As organizations look to process analytics alongside transactions in real-time, Cassandra affords IT organizations a lower-cost alternative.

When it comes to databases, there is no shortage of alternatives. The days when organizations standardized on a single database are, for all intents and purposes, over. The challenge now is defining the best DevOps practices that will be required to manage multiple database engines as instances of each type of database continue to proliferate.

— Mike Vizard

December 17, 2019
Survey Sees More Complex API Challenges Ahead

A survey of more than 10,000 developers of application programming interfaces (APIs) suggests there’s lots of room for improving the overall efficiency of API lifecycle management.

The survey was conducted by Postman, a provider of a platform for building APIs. Respondents on average said they only spend a quarter of their time (26%) on the development of APIs. The rest of the time is consumed by debugging and manual testing (22%), automated testing (11%), designing and mocking APIs (11%), managing others (9%), documentation (7%), monitoring (6%) and publishing (4%). A full 70% said they are spending more time on manual testing and debugging than they thought they should.

All that time spent on manual testing and debugging may be having an adverse impact on the number of APIs that can be built, tested and deployed at a time when a transition to microservices-based architectures is requiring organizations to build and support more than ever.

According to the survey results, about a quarter of respondents (24%) work with more than 20 APIs. Well over half those employed on average (53%) are for internal use, compared to 28% employed specifically for integration and 19% that are made public.

In terms of technologies survey respondents are most excited about for the coming year, microservices (54%), containers (46%) and serverless computing frameworks (44%) top the list.

As far as the performance is concerned, survey respondents are evenly split. Just under half (48%) said they feel that their APIs do not break, stop working or materially change specification often enough to matter. However, 28% said these issues arise on a monthly basis, while 16% said they deal with these issues weekly. Another 3% said it was a daily challenge.

In terms of security, survey respondents are relatively confident: Nearly three-quarters of respondents (73%) said they feel that their APIs are “very secure” or have “above-average security.” Only 2% said they felt they were not at all secure.

It’s hard to say how secure any API is without testing it. Rebecca Johnston-Gilbert, a marketing manager for Postman, said it’s apparent more organizations are starting to address security at the design phase rather than after the API has been built and deployed. Many organizations have already adopted an API-first approach to application development that enables them to manage them in isolation from the applications they are designed to support, she said.

Among other survey findings, 73% of survey respondents said they work on a team of 10 members or less, while a quarter (26%) work on teams with 22 to 50 members. In addition, 78% of respondents have five or fewer years of experience in developing APIs.

In general, survey respondents said they would like to see improvements in the areas of documentation (64%), standardization (59%) and sample code (58%), which suggests consuming APIs is still not all that simple.

There is no doubt organizations increasingly will be applying best DevOps practices to the building and maintaining APIs. The challenge organizations face is, not only do they need to build and maintain what could soon be hundreds (if not thousands) of APIs to support microservices but also those APIs will need to be a lot more resilient as the dependencies between microservices exponentially increase.

— Mike Vizard

December 16, 2019
Cloudera Calls for MLOps Standards Initiative

Cloudera put out a call this week for the IT industry to define a set of open standards for machine learning operations (MLOps) and machine learning model governance that could be universally applied.

Santiago Giraldo, senior product marketing manager for data engineering for Cloudera, said the idea is to create the equivalent of a set of best DevOps practices to create the equivalent of a set of best DevOps practices for employing machine learning models employed by artificial intelligence (AI) applications that will serve to foster portability, interoperability and explainability.

In the absence of such standards, most AI models are essentially black boxes optimized for specific platforms that many organizations are reluctant to adopt because no one is quite sure how they operate. Furthermore, it’s not all that feasible right now to integrate multiple AI models built using different classes of tools.

At the same time, Giraldo said the further down the AI path organizations go, the more they realize the AI models they are building need to be either updated frequently or outright replaced as new data sources become available. Most AI models are trained to respond to specific events based on access to a finite set of data. As new data sources are introduced, organizations are discovering the accuracy of recommendations being made by an AI model start to degrade. In fact, only a limited number of AI models are making it into production environments today largely because they didn’t scale as expected.

Cloudera is already moving down the MLOps path with Apache Atlas, an open source framework designed to integrate data management across explainable, interoperable and reproducible MLOps workflows. Now Cloudera is inviting the industry, including competitors, to collaborate on a broader set of metadata specifications that Anduago said is more a call to action than a specific proposal.

It’s unclear precisely how such an initiative might be managed. There is no widely recognized consortium initiative focused specifically on MLOps. Thus far, the closest thing might be The Deep Learning Foundation, an arm of The Linux Foundation that connects organizations working on innovative technical projects focused on AI and machine learning.

Despite all the hype, it’s apparent that AI is still in its infancy in terms of practical use cases. Most organizations can’t afford to hire the data scientists required to build AI models, let alone find them. Even when they do, the competition for AI talent is so fierce that organizations are also finding it difficult to retain that talent. Giraldo said the goal should be to make it easier not only to build AI models but also slipstream them into both new and existing applications.

Obviously, many of the best DevOps practices that have already been defined can be applied to AI models. The next big challenge might very well be educating data scientists on how to work more closely with developers to build, test and deploy AI models with applications at scale. In the meantime, the existing DevOps community might want to do as much as possible to help prevent a nascent MLOps community from reinventing some wheels that might already exist.

— Mike Vizard

December 13, 2019
Solo.io Creates Registry for Extensions to Envoy Proxy Server

Solo.io has created a WebAssembly Hub registry designed to make it easier to discover and share extensions to the open source Envoy proxy server.

Now being developed under the auspices of the Cloud Native Computing Foundation (CNCF) after being created by Lyft, Envoy is gaining traction as a proxy server in IT environments that have embraced microservices.

Solo.io CEO Idit Levine said DevOps teams are challenged by finding a way to extend the Envoy platform, which was developed using the C++ programming language. WebAssembly Hub provides an alternative approach to extending Envoy by employing the portable WebAssembly (Wasm) binary instruction format, known as a Wasm stack machine, that can be embedded as an execution environment in other platforms.

Wasm, which itself was developed under the auspices of the World Wide Web Consortium (W3C), provides a portable target for compilation of high-level languages such as C, C++ and Rust for building applications in a way that enables DevOps teams to add or modify extensions dynamically by moving code into a running Envoy process without having to stop a process or recompile code, said Levine.

That approach provides the added benefit of isolating extensions from Envoy, which means if the extension crashes it will not take down Envoy with it, added Levine.

Levine said Solo.io already employs Wasm to facilitate the development of extensions to Solo Gloo, an open source API gateway optimized for Kubernetes environments built on top of Envoy. Solo Gloo already supports the WebAssembly Hub registry.

As it turns out, however, Envoy is also at the base of the Istio service mesh. Any platform that employs Envoy now can take advantage of WebAssembly Hub to build and distribute extensions, said Levine. Among other use cases, Solo.io envisions DevOps teams using WebAssembly Hub to discover a web application firewall that can be added to, for example, an Istio service mesh via a few clicks of a mouse—which could significantly advance the adoption of best DevSecOps processes.

It’s not clear whether IT organizations will replace legacy proxy servers with rival offerings such as Envoy that claim to be more optimized for microservices architectures. In many cases, developers are making decisions based on personal preferences, which results in organizations soon discovering they are supporting multiple proxy servers across a range of classes of applications. Whatever the path chosen, however, those same organizations also may soon discover that a raft of extensions that were built for an Envoy-based platform may usurp a whole range of security, network and application services that today are all invoked in isolation from one another. The one thing that is clear, however, is that most of those services will be invoked programmatically instead of relying on an administrator who has mastered all the nuances of a specific graphical user interface for a single-function platform.

It may take a while for a new generation of proxy servers to achieve critical mass. However, at this point, it’s no so much about whether they will as much as it is to what degree.

— Mike Vizard

December 13, 2019
SolarWinds Acquires VividCortex for Database Monitoring

SolarWinds announced this week it is extending its portfolio of DevOps tools with the acquisition of VividCortex, a provider of tools for monitoring a wide range of databases that is delivered as a set of software-as-a-service (SaaS) applications.

Company president and CEO Kevin Thompson said the acquisition of VividCortex adds a database monitoring platform capable of monitoring so-called cloud-native databases such as MySQL, PostgreSQL, Amazon Aurora, MongoDB and Redis, complementing the company’s existing tools for monitoring databases to support legacy applications.

In addition, Thompson noted the VividCortex tools are highly extensible; support for a new database can be added within 90 days.

VividCortex claims to have nearly 300 customers today, including Etsy, GitHub, SendGrid, DraftKings and Yelp. SolarWinds, meanwhile, boasts more than 300,000 customers.

Thompson said the number of databases organizations need to monitor is increasing as open source alternatives gain ground on proprietary databases. The result is a hybrid computing environment that requires tools to manage centrally since it’s not practical to try and master each set of monitoring tools provided for each database platform, added Thompson.

IT organizations also want to be able to compare and contrast the cost of deploying workloads on databases running in different environments, he added. Many IT organizations have already discovered that the cost of deploying certain types of workloads on public clouds is more expensive than anticipated.

Thompson said it’s not really feasible to observe an application without being able to monitor the underlying database on which that application depends. In this respect, VividCortex adds a critical capability for DevOps teams, he said. SolarWinds intends to integrate VividCortex with a growing portfolio of DevOps tools that already includes a range of application performance management (APM) and infrastructure management tools. As is always the case, Thompson said IT organizations should also expect SolarWinds to drive the cost of employing database monitoring tools lower.

As IT continues to evolve Thompson said SolarWinds believes many more organizations will embrace best DevOps practices. Much of that effort will involve retraining existing staff, because there are not enough college graduates to fill a rapidly expanding skills gap within IT organizations.

It’s not clear to what degree lowering the cost of tools will accelerate the transition DevOps. Many organizations already rely on open source tools. However, the total cost of setting up and maintaining those tools often winds up being higher than a SaaS platform. In addition, all the upgrades to the SaaS platform are handled by the provider of the service.

In many cases, developers wind up embracing open source tools to lower the cost of building an application, which the IT operations team then manages using commercial tools once that application is deployed in a production environment. In some cases, however, open source tools embraced by developers also end up being employed in the production environment. In either case, IT organizations now have more tools to choose from than ever.

— Mike Vizard

December 13, 2019
Survey: DevSecOps Progress Remains Elusive

Results of a survey of 103 IT professionals attending the recent DeveloperWeek Austin conference suggests that awareness of cybersecurity issues is clearly rising among developers, yet most organizations still have a long way to go toward before approaching anything resembling adoption of best DevSecOps practices.

Conducted by WhiteHat Security, a unit of NTT Communications, the survey on DevSecOps adoption finds nearly 75% of developers worry about the security and 85% rank security as being a very important element of the coding and development process. However, nearly half of the respondents said their development teams lack a dedicated cybersecurity expert. Only 30% of respondents said they have achieved security certifications in their current or prior roles.

More than half (57%) of survey respondents said their teams have the right application security tools in place to incorporate security into the software development life cycle (SDLC). Among those respondents who do use application security tools, a third (33%) scan for vulnerabilities daily, while 29% said they scan weekly and 20% said monthly. The remaining 18% scanned either quarterly, annually or at random.

Also, 14% said they have not been given the proper tools to incorporate security into the SDLC and a third (33%) were unsure what their organizations provided in terms of cybersecurity tools.

While the survey finds 57% are realizing that application security should be a key part of the SDLC, it also finds 43% of respondents still prioritize meeting their application release deadlines over security.

WhiteHat CTO Anthony Bettini said it is apparent organizations are struggling to strike a balance between application delivery velocity and security. Organizations are under pressure to digitize more processes faster. However, that pressure can result in a lot more friction being created between developers trying to meet a deadline and cybersecurity professionals who ultimately are held accountable for the integrity of the overall IT environment, he noted.

To bridge that divide, Bettini said a lot more work needs to be done in terms of driving the convergence of processes, people and tooling required to achieve DevSecOps. On the plus side, however, he noted within many organizations, DevSecOps is starting to supersede DevOps as a development philosophy.

The biggest issue organizations may need to worry about as they strive to achieve that goal may be burnout. The survey finds more than half (52%) of participants have experienced burnout as a result of the intense pressures to deliver the applications on time that are secure.

Overall, the survey makes it clear developers at the very least are willing to pay a lot more attention to cybersecurity. Compared to the way developers tended to view cybersecurity just a few short years ago, that alone represents substantial progress. The challenge organizations face now is finding a way to make it as simple as possible for developers to do the right thing from a cybersecurity perspective. There always will be the natural temptation to address a security issue later in the development cycle to meet a deadline. The trouble is that when cybersecurity issues continue to get kicked down the DevOps road, they all too often wind up becoming a major issue after an application has already been deployed in a production environment.

— Mike Vizard

December 13, 2019
Survey Sees Massive Adoption of Microservices

Under increasing pressure to innovate faster, a majority (84%) of organizations taking part in a recent survey have already embraced microservices.

The survey, conducted by Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT leaders in organizations with more than 1,000 employees. Among the results, 89% of technology leaders agree that companies that are not able to effectively support microservices will be less able to compete in the future.

The report also finds on average organizations are running 184 microservices, with 60% of respondents running 50 or more. The primary reasons cited for adopting microservices are improvements to security (56%), increased development speed (55%), increased speed of integrating new technologies (53%), improved infrastructure flexibility (53%) and improved collaboration across teams (46%).

Kong CTO Marco Palladino said the report makes it clear that just about every organization is on a journey to making a transition to microservices as part of an effort to reduce reliance on inflexible monolithic applications. Initially, that transition involves lifting and shifting monolithic applications in the cloud before decoupling functions using microservices, he said.

As part of that journey, Palladino noted, the survey also finds significant microservices challenges remain, including ensuring security (36%), integration with legacy applications (32%), the complexity of management (31%) and updating API documentation (31%).

Despite these concerns, however, more than 80% of survey respondents who have adopted microservices report that their organization performs well against metrics for development efficiency, the ability to use new platforms, collaboration across teams and sharing of services across applications.

Overall, a full 90% of respondents said securely connecting applications and ensuring performance at scale collectively represent one of the greatest technical challenges of the 21st century. Also, 71% said they believe that organizations would be out of business within six years if they fail to keep pace with innovation in their industry. For public companies, the urgency is even greater, with 39% reporting they believe organizations will be out of business in less than three years if they fail to keep pace with innovation. Overall, 57% of technology leaders feel organizations are concerned that they are at risk of competitive displacement.

Pressure on IT leaders is high as a result. Nearly three-quarters of respondents (74%) agree that a failed digital transformation effort will result in a missed promotion, lost bonus or even termination. The report identifies the top three priorities for IT leaders as improving efficiency (47%), reducing cost (41%) and increasing security (40%).

Technology leaders, however, continue to place the highest importance on the availability (75%), security (74%), performance (65%) and scalability (64%). At the same time, technology leaders are focused on faster development speeds (95%), increased collaboration (94%) and reduced deployment risks (93%) as key desired outcomes for adopting any new technologies.

The challenges most cited in terms of achieving those agility goals are the complexity of using multiple technologies (35%), lack of automation (32%) and reliance on legacy technologies (29%).

The survey also notes 83% of organizations are relying on open source software to become more agile. The most commonly used open source technologies are databases (64%), containers (48%), API gateways (41%), infrastructure automation (40%), container orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%).

In terms of cloud adoption, Microsoft Azure (43%) narrowly beat Amazon Web Services (AWS) (42%), with Google Cloud Platform (GCP) coming in third at 27%.

On the plus side, 78% of respondents said their organizations are increasing IT budgets in the coming year, with 27% of public companies expecting their budgets to grow 26% or more. Nearly 90% of companies will also be increasing headcount, with 56% hiring internally and 31% relying on more freelancers and/or outsourcing to meet hiring goals.

Hopefully, with that increased funding more organizations will be able to strike that elusive balance between stability and innovation.

— Mike Vizard

December 12, 2019
HashiCorp Advances Open Source Consul Service Mesh

HashiCorp this week updated its Consul service mesh to make it easier to manage namespaces across multiple services.

Previously, DevOps teams would have to manually ensure each namespace assigned to a group of services did not conflict with each other. The release of 1.7 of Consul enables teams to restrict access to services residing in isolated environments on a shared cluster, eliminating the issue.

In addition, DevOps teams can now delegate administrative privileges for a given namespace to individual teams, which enables them to manage their own services in keeping with best DevOps practices, rather than having to rely on a cybersecurity team to manage that process for them.

With the rise of microservices based on containers, interest in service meshes to provide a means to discover and manage services is on the rise. However, services span both emerging microservices-based applications and legacy monolithic applications. Rather than adopting a service mesh that only runs on one platform, HashiCorp is opting for an open source service mesh that spans multiple platforms and is easier to deploy and manage than rival offerings such as Istio.

Amith Nair, vice president of product marketing at HashiCorp, said that approach also makes it easier to deploy a service mesh at scale across multiple clouds and on-premises IT environments. Because Consul is designed to deployed on top of proxy servers such as Envoy or NGNIX, it can be deployed almost anywhere to manage services sprawl across the extended enterprise, noted Nair.

As far as the adoption of service meshes are concerned, it is still early days. Many organizations are in the process of shifting away from managing applications to focusing on services that span multiple applications. Given all the dependencies that exist between various services, that shift represents a major challenge. A service mesh alleviates some of that challenge by providing a mechanism for both discovering and governing services that are increasingly interdependent.

That approach also provides the added benefit of allowing teams tasked with governing and auditing IT environments to focus more on higher levels of abstractions versus updates to every line of code on which those services are constructed.

For now, there are no standards, de facto or otherwise, in terms of service meshes. Many organizations may find themselves adopting multiple frameworks, which may lead to further advances in interoperability specifications such as the Service Mesh Interface between rival platforms.

Less clear for now is who inside an IT organization will be responsible for acquiring and managing a service mesh. In some organizations it might be a network operations or cybersecurity team. In other organizations, those roles may have already been incorporated within a larger DevOps team.

Regardless of the approach, the need for some type of service mesh is becoming more apparent. The good news is there is now no shortage of options. However, DevOps teams should note that in terms of overall complexity and amount of compute resources consumed, not all services meshes are the same.

— Mike Vizard

December 11, 2019
Testing Emerges as DevOps Hurdle in Mainframe Shops

A survey of 400 senior IT leaders responsible for application development using mainframes finds 90% believe automating more test cases could be the most important factor in their success, as the pressure to accelerate innovation increases. However, the same survey finds only 7% of organizations automate the execution of test cases involving mainframe code today.

The survey, which was conducted by Vanson Bourne on behalf of Compuware, also finds the time required to conduct thorough testing is the biggest barrier to integrating the mainframe into agile and DevOps processes for just over the half the survey respondents (53%), followed by a lack of skills (39%) and lack of understanding how code changes will impact distributed applications (34%).

A total of 82% said that unless they can automate more test cases, they will not be able to meet the need for speed the business now requires. That may account, in part, for why 56% of respondents said they plan to start automating the execution of test cases on mainframe code within the coming year.

The biggest benefits expected to be derived from those investments include greater efficiency within the IT team (59%), improved consistency of testing (53% ), reduced chance of human error (47%), reduced pressure on IT teams (47%), accelerated innovation cycles (46%) and less chance of bugs making it into production (40%).

Primary areas of focus for automated testing are ranked as functional testing (63%), followed by integration testing (53%) and unit testing (37%).

The survey also finds development teams are spending, on average, more than half their time (51%) on testing during the release of a new mainframe application, feature or function. That compares to 39% of their time testing applications, features or functions on applications that don’t run on mainframes.

A full 92% said mainframe teams are spending more time testing code than they needed to in the past because of the growing complexity of cross-platform application environments. Issues organizations are contending with are “Manual and time-consuming test processes” (44%), “Mainframe testing processes require specialists that are not always readily available” (40%), “Testing processes are costly” (39%) and “It’s hard to visualize and understand dependencies” (35%).

Not surprisingly, 77% of respondents find it increasingly difficult to simultaneously increase quality, velocity and efficiency to meet business innovation goals when developing and testing mainframe application code. Top concerns when it comes to mainframe development are introduction of security flaws (50%), impact on customer experience (38%) and disruption to operations (36%).

A full 85% said it is becoming more difficult to deliver innovative and faster applications without compromising quality or increasing the risk of bugs finding their way into production.

Steen Brahe, product manager at Compuware, said organizations that have mainframes are usually under pressure to innovate faster now because competition from startups relying on DevOps processes and modern platforms has increased sharply. Rather than incurring the cost of replacing mainframe applications on which the business currently depends, organizations that have mainframes are looking to extend DevOps processes to integrate emerging and legacy applications.

It’s not clear to what degree those organizations will succeed. However, the one thing that is clear is organizations with mainframes that fail to embrace best DevOps processes are already most certainly doomed.

— Mike Vizard

December 11, 2019