devopsy.kinsta.cloud

Category: News

Atlassian Adds Pre-Configured Pipelines to Bitbucket CI/CD

One of the primary reasons DevOps processes have not been widely adopted across the enterprise is that building pipelines across all the tools required is a painstaking effort. As a result, most pipelines today are constructed using manual pipelines. However, Atlassian has announced it is now making available pre-configured Bitbucket Pipelines that DevOps teams can access via a simple drag-and-drop interface.

Harpreet Singh, head of product for Bitbucket Cloud at Atlassian, said DevOps teams that rely on the Atlassian Bitbucket continuous integration/continuous deployment (CI/CD) platform will be able to employ a series of pre-configured Bitbucket Pipelines built by Atlassian or one of its third-party partners, rather than having to manually build every pipeline.

The goal is to make it much easier for DevOps teams to incorporate, for example, a new cloud platform into an existing set of DevOps processes without waiting for someone on the DevOps team to write, test and validate a script, said Singh. IT vendors that have worked with Atlassian to create Bitbucket Pipelines include Google Cloud, Microsoft, Slack and Amazon Web Services (AWS).

One of the ironies of DevOps is that while CI/CD platforms make it easier to build and deploy applications, constructing the CI/CD platform can be exceedingly complex. A recent survey conducted by Atlassian found DevOps teams rely on 4.3 tools to move code from development into production environments. A full 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation.

While some organizations might have the engineering resources required to build pipelines, he noted, the average IT organization can’t afford to hire operations specialists that have the requisite programming skills required to build pipelines manually.

Best of all, noted Singh, the pre-configured Bitbucket Pipelines that Atlassian makes available will be maintained and updated by their original authors.

It’s too early to say to what impact pre-configured pipelines is likely to have on DevOps adoption in the enterprise. But most enterprise IT organizations won’t significantly alter their process until it becomes relatively easy to make that transition. Enterprise IT organizations have relied on administrators to manage IT for decades, and most of those administrators wouldn’t know where to begin if asked to manually construct a pipeline. The few enterprise developers who might be able to build those pipelines are simply to busy writing application code. The result is a paralysis that prevents organizations from modernizing their application development and deployment processes.

Of course, any meaningful change in the enterprise also involves a chicken-and-egg debate. Lacking skills and tools, enterprise IT organizations are unable to overcome internal inertia, which in turn results in conservative IT organizations preferring to rely on known processes no matter how inefficient they might be. The real challenge facing IT leaders trying to advance DevOps adoption is to remove as many excuses for resisting change whenever and wherever possible, starting with how pipelines are constructed and maintained.

— Mike Vizard

February 28, 2019
VMware Brings NSX Network Virtualization into DevOps Realm

At the Mobile World Congress (MWC) 2019 conference, VMware moved to bring network virtualization into the realm of DevOps by adding support for a declarative programming model and JSON data formats to version 2.4 of NSX-T.

In addition, VMware is making it possible to use the open source Ansible automation framework to deploy NSX-T.

Finally, VMware is adding support for IPv6 as well as the ability to now extend microsegmentation all the way to Layer 7 of the application stack.

Jonathan Morin, product marketing manager for NSX at VMware, said this release of NSX-T not only will become the dominant version of NSX for VMware in the enterprise, it also represents a concerted effort to make network virtualization directly accessible to both developers and IT operations teams alike. JSON support is critical from that perspective because it makes it easier to programmatically replicate the networking requirements and security controls attached to any class of applications.

Longer-term, JSON support will also make it easier for a wide variety of management tools to consume metrics generated by NSX-T.

IT organizations must determine to what degree they want to fold network operations into DevOps. Some organizations will simply prefer to provide developers with access to self-service virtual networks, while others will move to expose the declarative application programming interfaces (APIs) in NSX-T 2.4 directly to developers, said Morin.

VMware expects that, going forward, a hybrid method for deploying and managing NSX will emerge. Developers will want to programmatically invoke network resources as they build and deploy applications. But network administrators will need to be able to access tools to manage those virtual networks over time. To facilitate that process, the latest version of NSX-T has been updated to add support for an HTML5-based user interface. The goal is to not just distribute NSX-T, but also make it accessible to everyone, said Morin.

Rather than requiring organizations to upgrade switches and routers to enable programmability, VMware has been making a case for employing network virtualization to create a programmable overlay. That approach serves to make the underlying physical network agile enough to be employed with a DevOps framework without requiring organizations to upgrade the entire physical network.

In many ways, networking represents the last major frontier to which DevOps processes need to expand. It’s possible for developers to spin up a virtual machine in the cloud or in an on-premises environment in seconds. But it can still take weeks to manually provision the networking resources in an on-premises environment that a virtual machine requires. VMware has been advocating for the deployment of instances of NSX in both on-premises IT environments and in public clouds to provide a consistent network overlay that can be programmatically invoked and automated.

It remains to be seen to what degree network operations will be pulled into DevOps processes going forward. But the one thing that is clear is that IT organizations have the option to decide to what level they might want to achieve that goal.

— Mike Vizard

February 27, 2019
FinOps Foundation to Help Rein in Cloud Costs

A new consortium has been formed to promote best practices for controlling cloud computing costs.

Announced at the Cloud Economic Summit, the non-profit FinOps Foundation counts among its founding members Atlassian, Autodesk, Cloudability, HERE Technologies, Just Eat and Nationwide.

Cloudability co-founder J.R. Storment said the goal is to bring financial accountability to variable cloud spending that can easily spiral out of control if not monitored carefully. The adoption of best DevOps practices makes IT organizations more agile, but not every organization has the financial controls in place to ensure spending on cloud services is aligned with business outcomes, said Storment.

These days engineers can use their corporate credit card to spin up virtual machines in the cloud. The FinOps Foundation is making a case for more accountability over the spending.

Gartner estimates worldwide cloud spending will reach $360 billion by 2022, which is five times the compound annual growth rate for overall IT spending. The unfortunate truth, however, is that most finance organizations don’t have a lot of visibility into how those dollars are being allocated.

To coincide with the launch of FinOps, 451 Research also published a survey of 300 IT and finance executives in the United States and the U.K. that finds more than half (57 percent) of large enterprises worry about cloud costs daily, with 80 percent admitting poor cloud financial management has had a negative impact on their business.

In fact, the 451 Research report makes it clear most finance departments have little visibility into cloud spending. Almost three-quarters (72 percent) of finance executives acknowledged they have no formal reporting capacity between departments. More than half (51 percent) of respondents admitted to occasionally overspending and 68 percent said they are only alerted to overspend too late. A full 82 percent of finance respondents rely on cloud vendors, spreadsheets and manual processes to track cloud costs.

Despite much of the variable cost hype surround cloud computing, 73 percent of the finance respondents in the United States and 81 percent in the U.K. still treat cloud as a fixed capital expense rather than an operating expense.

To help finance teams better understand how cloud spending is being allocated, the FinOps Foundation will provide access cloud economic research and related articles, FinOps training and meetup groups. Early access to the forthcoming “Cloud Financial Management Strategies, Creating a Culture of FinOps” book published by O’Reilly Media will also be provided.

As IT organizations increasingly employ multiple cloud platforms to run different classes of workloads, understanding the true cost of choosing to use one cloud over another will become more important. At the same time, IT organizations have a greater appreciation for the need to move workloads between platforms as costs rise. Just because an application workload was created in the cloud doesn’t mean that workload should be deployed there. Many long-running applications are less expensive to deploy in an on-premises IT environment. The challenge IT organizations arguably face going forward will be integrating streams of real-time financial data into DevOps processes to make more economically informed decisions about how to allocate their cloud resources.

— Mike Vizard

February 26, 2019
Kemp Adds Predictive Analytics to ADC to Advance DevOps

Kemp this week enhanced the automation and predictive analytics capabilities it makes available within its application developer controller (ADC) as part of an effort to ease deployment of applications across multi-cloud computing environments.

Company CEO Ray Downes said the goal is to make it easier for DevOps teams to avoid overprovisioning IT infrastructure, at a time when applications are more distributed than ever.

The Kemp ADC offerings are comprised of a mix of physical and virtual appliances that have now been deployed more than 60,000 times. The volume of data generated by those deployments now makes it possible for Kemp to apply predictive analytics via a 360 Central monitoring tool that, for example, can now make suggestions concerning where to deploy a workload based on current utilization rates, Downes said.

Kemp also now can provide comparative analytics, he noted. For example, the company revealed that its analytics show 61 percent of application experience issues are related to events caused by capacity issues such as failing or degrading application servers. Kemp also revealed that 48 percent of organizations see as many as nine application incidents per week.

Now that Kemp has begun to apply predictive analytics to its ADC platforms, Downes said the next logical step will be to apply machine learning algorithms to help further automate application deployments.

While ADCs provide critical load balancing capabilities, they are often overlooked as a source of actionable intelligence for DevOps teams. That data is more critical than ever because as IT organizations modernize their application portfolios by embracing more complex microservices, many of them are discovering every application will soon require its own load balancing capability. Previously, the primary role of an ADC had been to enable as many applications as possible to share the same IT infrastructure efficiently. Now the goal is becoming to orchestrate and optimize the allocation of IT infrastructure resources across a range of loosely coupled microservices. The Kemp ADC is designed to enable DevOps teams to define a desired state of all the load balancers in the distributed IT environment, including F5 Big-IP, AWS Elastic Load Balancer, Nginx, and HAproxy load balancers. That capability then makes it easier to roll out distributed application services.

Over time, Downes said Kemp will extend that capability to open source load balancers such as Envoy, which are starting to be deployed on top of Kubernetes clusters. Both Kubernetes and Envoy are being developed under the auspices of the Cloud Native Computing Foundation (CNCF). As critical as load balancing will be within a Kubernetes cluster, however, Downes noted distributed applications will span cloud-native and legacy IT infrastructure environments as well as multiple Kubernetes clusters.

It may take a while for DevOps teams to fully sort out what form of ADC platform and load balancing capability to employ when and where. But as IT becomes more distributed, there’s rising interest in making sure IT infrastructure utilization rates for those applications remain as high as possible regardless of how they have been developed.

— Mike Vizard

February 21, 2019
Survey: DevOps Progress Slow, but Steady

Atlassian has published the results of a survey of 500 IT and software professionals that suggest now is the best and worst of times when it comes to DevOps.

On the plus side, the survey found that more than half of respondents (57 percent) are encountering fewer bugs and outages after deploying a continuous integration/continuous deployment (CI/CD) platform. Nearly half (47 percent) of those who have adopted a CI/CD platform also report they make changes and receive customer feedback faster. A full 71 percent who have embraced microservices have also discovered it is much easier to test and deploy new software features, according to the survey results.

However, the survey found three-quarters (75 percent) of development teams face issues with bugs, defects or delays when it’s time to release. A total of 73 percent of software development teams also reported spending 10 percent to 50 percent of their time on updates and upgrades to self-hosted software. On average, according to the survey results, teams rely on 4.3 tools to move code from development into production environments.

More frustrating, 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation. However, among those organizations that have adopted feature flagging to ease management of the application development process, 63 percent report better testing a feature and higher overall rates of software quality.

The metric IT organizations are employing to measure DevOps success appears a little soft. A full 93 percent of respondents consider customer satisfaction to be the most important DevOps metric, but 60 percent admit it’s difficult to measure customer satisfaction for the features that have been developed.

Sean Regan, head of growth for software teams at Atlassian, said that while there is clearly much work still to be done, the democratization of DevOps continues unabated. Rather than being limited to a few high IT practitioners, Regan said DevOps processes increasingly are being pushed into the realm of everyday enterprise IT operations. At the same time, many line of business executives are being included within those teams to ensure the software being developed achieves the desired business outcome, noted Regan.

IT organizations are also starting to apply more engineering principles to the management of IT infrastructure, added Regan. In many cases, IT organizations are discovering a single engineer can be more efficient than 10 systems administrators. However, finding and retaining those engineers is a major challenge. The goal needs to be to create a set of DevOps processes defined by an engineer that are simple enough to be implemented by IT administrators, said Regan.

Of course, many of those IT administrators today are schooled in less agile ITIL processes. But as ITIL continues to absorb some of the concepts and best practices pioneered by the DevOps community, the divide between engineers and traditional IT administrators should become that much more narrow to bridge.

— Mike Vizard

February 21, 2019
New Relic Accelerates AIOps with SignifAI Acquisition

New Relic, following its acquisition of SignifAI, is in the process of accelerating its investments in machine learning algorithms and other forms of artificial intelligence (AI) as part of an effort to make it easier to separate the signal from the noise created by all the alerts in an IT environment.

Aaron Johnson, senior vice president of product management at New Relic, said SignifAI represents an opportunity for New Relic to create a superset platform that can apply advanced analytics to a much wider range of data sources. SignifAI has already created more than 60 integrations spanning open source and commercial monitoring tools that are widely used across DevOps toolchains, he noted, adding that as New Relic moves to add other data sources, there’s an opportunity for the company to distinguish itself beyond providing software-as-a-service (SaaS) tools for monitoring applications and infrastructure.

It’s obviously still early days for AI in the realm of DevOps. But it’s also clear that with the rise of microservices and containers, soon it will be impracticable for IT organizations to manually manage their IT environments. Various forms of automation based on AIOps platforms infused with machine and deep learning algorithms will be required. As a provider of SaaS-based tools for monitoring applications and infrastructure, New Relic already has access to vast amounts of data required to train AI models on optimizing a specific IT environment.

Of course, there’s lots of competition across the IT monitoring category, so it remains to be seen which vendors will have the resources required to drive continuing investments in AIOps.

In the meantime, DevOps teams will need to adjust their processes to take advantage of AIOps. It’s unlikely AIOps platforms will eliminate the need for DevOps teams, but the number of applications and platforms any DevOps team must manage effectively will increase substantially. Rather than replacing humans, AIOps platforms will reduce the pressure to hire additional IT staff when professionals with DevOps skills are already in short supply. The AIOps platform, for all intents and purposes, acts like a co-pilot.

The biggest issue IT organizations are likely to encounter along that journey is establishing trust with any AIOps platform they implement. It takes a while for most AI models to learn the IT environment before that platform makes any reliable recommendations. In most cases, DevOps teams will have to dedicate staff to train and update AI models continuously as the IT environment changes. It may take years, however, before DevOps teams are comfortable enough to move beyond trusting a recommendation and enable an AIOps platform to automate processes on its own. After all, the only thing worse about being wrong about any IT decision is being wrong about it at scale.

AI at this point is all but inevitable in DevOps environments. But it doesn’t necessarily follow that just because something is based on AI it always will be smarter than experienced DevOps professionals.

— Mike Vizard

February 20, 2019
IBM Adds Automated Testing Tool for Mainframe to DevOps Portfolio

IBM has added an automated testing tool to the portfolio of DevOps tools it has developed for mainframes.

Sanjay Chandru, director of Z DevOps for IBM, said IBM Z Open Unit Test adds a continuous testing capability to the continuous integration/continuous development (CI/CD) platform based on an instance of an open source Git repository developed by Rocket Software that IBM launched last year. The automated unit testing tool automatically records and plays back test data for both batch-oriented applications written in COBOL or PL/I and CICS transaction processing applications.

Chandru said IBM Z Open Unit Test is unique in that it eliminates the need to employ traditional debugging tools. Developers can generate test cases for COBOL CICS programs, as well as “stub out” CICS to achieving environment independence from CICS runtime during test case execution. A stub is an object that holds predetermined data, which is provided in response to calls made during tests. That approach eliminates the need to have objects that answer with real data. That means Z Open Unit Test operates without adding the overhead of a debugging tool, said Chandru.

Any test case and the resulting program created then can be stored in any source code management (SCM) system.

IBM is making a concerted effort to make mainframe a natural deployment target for any DevOps team, said Chandru. It increasingly has become apparent that millennials in particular aren’t biased toward one platform or another, as long as each platform is equally accessible, he noted, adding that as organizations embrace best DevOps practices to modernize their application portfolio, IBM wants to make sure the mainframe remains relevant.

IBM launched the z14 mainframe in the fourth quarter of 2017. According to the company, 92 of the world’s 100 biggest banks use its mainframes, which handle most global credit card transactions alongside billions of ATM transactions and annual passenger flight bookings. While use of mainframes overall isn’t growing, the platform isn’t going away anytime soon.

IBM has also enhanced the cryptographic capabilities of the z14 to make it one of the most secure platforms available and continues to invest in an instance of Linux for the mainframe. That latter capability makes the mainframe a more natural target for applications being developed and deployed using DevOps processes, said Chandru.

Of course, the biggest challenge when it comes to DevOps and mainframes is not necessarily the technology. Most mainframe applications have been developed using waterfall processes for decades. Getting those teams to embrace DevOps processes represents a significant cultural hurdle for any IT organization.

At the same time, however, DevOps teams who ignore mainframes are not taking advantage of an existing platform investment that has performance and security capabilities that are still unmatched after more than five decades. The real challenge is finding a way for old mainframe dogs to learn some new DevOps tricks while exposing proverbial whippersnappers to the capabilities of the most powerful mainstream platform ever built.

— Mike Vizard

February 19, 2019
IBM Extends Cloud Reach to Include Integration

At the IBM Think 2019 conference this week, IBM unfurled an IBM Cloud Integration Platform that pulls together a range of tools in a single development platform that the company promises will reduce the amount of time it takes to deploy applications by making it easier to reuse integration code.

Hillery Hunter, vice president and CTO for IBM Cloud Infrastructure, said by bringing all of its primary integration tools into a single cloud platform, IBM is effectively making an integration platform-as-a-service (iPaaS) environment available for the first time.

IBM this week also formally rolled out IBM Services for Multicloud Management, a portal through which multiple clouds can be managed using software-as-a-service (SaaS) applications developed by ServiceNow, along with a set of IBM Services for Cloud Strategy and Design through which IBM will advise clients on how to architect the right holistic cloud strategy. The premise of both those services is that organizations soon will be rightsizing workloads to run on whatever cloud or on-premises IT platform that best suits them. The portal developed with ServiceNow provides access to dashboards and analytics designed to enable IT organizations to analyze cloud spend and manage workloads deployed on any platform, including Amazon Web Services (AWS) and Microsoft Azure.

IBM is also extending the cloud services it provides to include the IBM Cloud Hyper Protect Crypto Service, which makes use of IBM LinuxONE mainframes to provide encryption key management built on the only FIPS 140-2 level 4-based technology.

Hunter said IBM’s approach assumes organizations have already bought into best DevOps practices and API management to provide the means through which multiple clouds will be managed. The challenge many of those organizations are now wrestling with is implementing processes that determine where a workload not only should be developed and deployed but also moved as its characteristics evolve. To provide that analytics, IBM is employing machine learning algorithms running on distributed instances of Kubernetes to continuously track changes and updates to cloud platforms, said Hunter.

IBM previously outlined a strategy under which it is trying to meld DevOps and ITIL-based processes to make it easier to manage workloads running on any cloud or on-premises IT environment. While the growth of cloud computing continues at an exponential rate, IBM executives this week took pains to remind conference attendees that 80 percent of enterprise-class workloads still run in on on-premises IT environment. In fact, IBM’s rationalization for spending $34 billion to acquire Red Hat is based on that fact. However, while many workloads will continue to run on-premises, IBM is clearly making a case for centralizing the management of all those platforms on IBM Cloud.

It most likely will take the better part of the next decade to determine where different types of applications may wind up running. Predictions concerning the percentage of application workloads that will run in the cloud continues to be one of the most hotly debated topics in the IT industry. Whatever the outcome, however, it’s 100 percent certain more than one cloud platform will be involved.

— Mike Vizard

February 14, 2019
Python Benefiting From Increase in DevOps Use

DevOps and Python have developed a mutually beneficial relationship.

In a recent survey released by the Python Software Foundation and software development company JetBrains, researchers found that more and more developers are using the program language for an array of versatile projects, including DevOps and machine learning.

In fact, Python developers told the researchers that DevOps is increasingly part of their professional development work.

“In 2018 we had significantly more respondents specifying they’re involved in DevOps (an increase of 8 percent compared to 2017). In terms of Python users using Python as their secondary language, DevOps has overtaken web development,” according to the “2018 Python Developers study,” which is based on responses from 18,000 developers in 150 countries.

Over the last two years, Python has grown more important to developers thanks to its flexibility, especially when it comes to web development. It’s no surprise that as other projects have gained popularity in the enterprise—DevOps and machine learning—developers have started adopting the language to other disciplines, especially as businesses invest more in application development.

In TIOBE’s February 2019 index, Python now ranks third behind favorites such as Java and C, edging out C++ for its current position.

Digging into the numbers, the survey finds that 43 percent of developers are using Python for DevOps projects, as well as system administration and writing automation scripts. That’s an increase from the 35 percent who reported the same types of uses for the programming language in 2017.

The report notes that these numbers reflect a combination of Python used as either the primary or secondary language for various projects. As the report notes: “DevOps/system administration/writing automation scripts has moved into first place among Python users using it as a secondary language.”

Machine learning is another up-and-coming category, with 38 percent of developers using Python for these projects compared to 31 percent last year.

Overall, data analysis remains the No. 1 use case for Python developers, with 58 percent reporting that it’s their main focus when it comes to development.

In second place is web development, according to the report.

In terms of the top cloud platforms for Python developers, Amazon Web Service is the top choice, with 36 percent of respondents reporting that they use AWS. From there, it’s Google Cloud Platform (29 percent) Heroku (26 percent), DigitalOcean (23 percent) and Microsoft Azure (16 percent).

About a third of those surveyed responded that they don’t use any cloud platforms.

When asked about running code in a cloud production environment, 47 percent responded that they use virtual machines, although 40 percent of Python developers reported that they prefer containers. Another 28 percent use platform as a service (PaaS) and 21 percent are taking the leap to serverless computing.

Additionally, when developing for the cloud, about 35 percent of those in the survey report that they use Docker containers.

This increase use of Python within DevOps, as well as other connected areas such as serverless computing, does not surprise Anshu Agarwal, the CEO and co-founder of Nimbella, a cloud-agnostic, serverless cloud platform for developers. She noted the language’s use within a wide range of projects, specifically machine learning and AI, are driving this change.

“Python developers are driving serverless requirements in new and unique ways, primarily because of the interest in data analysis, ML and AI,” Agarwal wrote in an email. “These data analysis and ML/AI-centric serverless use cases are different than request/response style serverless functions which run for much shorter durations. Python functions in serverless may have much longer durations (10s of minutes or hours), and consume a lot more memory. For such functions a different kind of serverless framework needs to be adopted that can handle long running workloads.”

When it comes to continuous integration systems, about a third of respondents don’t use any. However, when they do, Jenkins is the most popular at 25 percent, followed by Gitlab CI and Travis CI, with 18 percent each. For configuration management, 20 percent reported using Ansible, while 9 percent used custom tools. Puppet, Salt and Chef also appeared in the list.

Finally, about two-thirds of Python developers (69 percent) use Linux as their main operating system of choice for development. Microsoft Windows comes in a distant second at 47 percent and Apple’s macOS in third at 32 percent, according to the study.

— Scott Ferguson

February 14, 2019
Datadog Acquires App Dev Testing Platform Madumbo

Datadog announced it is extending its reach beyond IT monitoring to include application testing by acquiring Madumbo.

Madumdo CEO Gabriel-James Safar said it’s become increasingly apparent that application testing needs to be more informed by the metrics gathered by IT monitoring tools. The combined Datadog/Madumbo will bring intelligence to automated testing processes using both application and infrastructure data gathered via the Datadog platform.

The Madumbo platform already makes extensive use of machine learning algorithms and predictive analytics to inject artificial intelligence (AI) into the application testing process. The more data those algorithms can access, the more precise the AI models become over time.

That approach made it possible for Madumbo to build a bot that checks for errors using code running on a real browser, which Safar said means DevOps teams can capture the same defects as they are experienced by end users. That’s critical because much time is wasted by IT organizations that are unable to prioritize tasks to either identify the root cause of a problem or, arguably more importantly, prevent issues in the first place, said Safar. Because of that issue most organizations lack the time required to develop best-in-class DevOps processes.

Datadog provides a complimentary set of IT monitoring tools that are consumed as a software-as-a-service (SaaS) application. That data will then become a trusted source for Madumbo, which in turn will increase confidence in the AI recommendations being made by Madumbo, said Safar.

How many of those customers will wind up replacing whatever application testing tools they currently employ with Madumbo remains to be seen. But if Datadog can provide a more efficient approach to testing, testing tools may wind up driving organizations to replace their monitoring tools. Most organizations spend an inordinate amount of time trying to correlate data across tens of monitoring tools that often generate either conflicting alerts or alerts about issues the IT organization has already been informed of by another tool. Most IT organizations eventually will see the rise of AI platforms that will drive consolidation across the entire DevOps tools category.

In the meantime, the more issues that get addressed during the application development process, the fewer number of problems that will raise their ugly head in production environments. In fact, it’s arguable the whole point of investing in best-in-class DevOps processes is not just to roll out applications faster, but also make sure those applications are of a markedly higher quality than previous generations of applications. That’s not going to happen, however, unless DevOps teams can derive actionable intelligence from the millions of alerts that get generated up and down the IT stack.

— Mike Vizard

February 13, 2019