devopsy.kinsta.cloud

Author: Mike Vizard

Electric Cloud Applies Machine Learning to DevOps

Machine learning algorithms are being applied to advance DevOps via analytics software that Electric Cloud is making available.

Electric Cloud CTO Anders Wallgren said ElectricFlow DevOps Foresight is made possible because of the massive amounts of data that Electric Cloud is able to acquire providing an application release and continuous delivery platform-as-a-cloud service.

Electric Cloud applies predictive analytics against all the data it collects to identify and contrast patterns, which it then uses to generate recommendations to specific DevOps teams based on what’s occurring in their local environment, said Wallgren.

ElectricFlow DevOps Foresight is able to generate a risk score metric that predicts the probable outcome of a release before being deployed in a production environment. Based on that score, he said, a DevOps team can decide to go ahead and deploy that code or hold it back for further testing.

The application also will make recommendations on how to improve pipelines based on, for example, the complexity of the code being deployed, Wallgren added.

As part of this effort, Wallgren noted that Electric Cloud has been extending the level of integration it provides with application performance monitoring (APM) tools that serve as a source of data for a predictive analytics application.

The goal is not so much to provide a “big brother” application that will determine who should be fired, , for example, but rather reduce as much friction in the DevOps process as possible, he said.

Being able to apply machine learning algorithms to large amounts of data is becoming a compelling reason to shift DevOps processes into the cloud, he said, adding most organizations aren’t going to be able to collect the critical mass of data required to train machine learning algorithms running in an on-premises environment. ElectricFlow DevOps Foresight enables DevOps teams to leverage a turnkey application where support for those algorithms is already embedded into the cloud service, he said.

Wallgren noted the result should be a significant reduction in the amount of anxiety surrounding any release of an application.
Ultimately, the question many organizations will have to come to terms with is the degree to which they want to rely on machine learning algorithms and other forms of artificial intelligence (AI) to automate the DevOps processes. For now, Wallgren said Electric Cloud is focused on predictive applications that make recommendations versus taking independent action.

It remains to be seen just how comfortable DevOps teams will become with various forms of AI. On the one hand, DevOps teams are clearly interested in accelerating application deployments at a time when the number of applications being developed simultaneously is increasing exponentially. On the other hand, automating DevOps processes using AI could result in flaws being propagated at a level of unprecedented speed and scale. Long term, however, those organizations that fail to embrace AI to advance DevOps are more likely to find themselves at a competitive disadvantage.

— Mike Vizard

July 6, 2018
CA Technologies Looks to Shift Automation Left

CA Technologies, at its recent CA Automation Summit, advanced its case for leveraging automation to create a software development factory via an update to the CA Automic One automation platform that adds automation-as-code functionality.

Gwyn Clay, vice president of product management for the Automation Business Unit at CA Technologies, said the latest release of CA Automic One make is simpler to “left shift” automation artifacts by making it possible for developers to embed those artifacts within application code versus having to wait for a DevOps teams to run them out of band.

The latest version of CA Automic One also now includes version control and lifecycle management for automation artifacts that enables automation objects such as jobs, workflows and scripts to be promoted from development to production as part of an integrated DevOps process, said Clay.

CA Technologies also revealed it is embedding intelligence into workflows enabled by CA Automic One, which enables dynamic runtime estimations that can predict potential issues within certain paths in the workflow execution.

Other new capabilities added to the automation platform include support for PostgreSQL databases, as well as new integrations with CA Workload Automation, CA Continuous Delivery Director and CA Jarvis analytics software delivered as a cloud service.

CA Technologies has been on a multi-year campaign to embed automation across the entire DevOps processes. With this latest release, that campaign effort is being extended to developers themselves. Clay said the rise of digital business transformation—much of which is being driven by cloud-native applications built with technologies such as Docker containers, Kubernetes orchestration software and serverless computing frameworks—is finally forcing the automation issue in the enterprise. Not only are applications being built faster than ever, but the complexity of those applications has increased exponentially. And yet, the size of the overall IT staff has remained stagnant. Without some form of automation being embedded within the applications itself modern software development practices becomes difficult to sustain, she said.

Clay noted that most organizations are not yet at the point where they are deconstructing monolithic applications into a set of microservices. But it’s already clear most new applications will be built on a microservices architecture. CA Automic One represents an opportunity to apply automation across both legacy monolithic applications in addition to embedding artifacts directly within new applications, she noted.

It’s not clear the impact the ability to embed automation artifacts will have on how enterprise IT is managed going forward. IT operations teams still will need to be able to set policies and constraints concerning the level of automation a developer might be able to invoke. Most developers don’t have much regard for the need to share limited infrastructure resources with other applications. But as the ability to infuse automaton into almost every application becomes pervasive, the locus of power within enterprise IT organizations will continue to shift to the left. The challenge now is determining the best way to strike a balance between all the competing factions looking to control who gets to automate what exactly when.

— Mike Vizard

July 2, 2018
Compuware Extends DevOps Push for Mainframes

Compuware has advanced its campaign to erase the DevOps divide between mainframes and distributed systems via an update to Topaz for Enterprise Data that makes it easier to generate data from mainframe applications for testing purposes without compromising the security of some of the most sensitive data in the enterprise.

Company CEO Chris O’Malley said Topaz for Enterprise Data now includes a data masking capability that preserves essential data relationships and characteristics without letting developers see the data being copied.

Designed to be compatible with Eclipse integrated development environments (IDEs), Topaz for Enterprise Data also automates the extract, transform and load (ETL) process by enabling developers to convert file types.

O’Malley noted that, at a time when compliance regulations such as the European Union’s General Data Protection Rule (GDPR) are becoming more stringent, it has become more important for organizations to be able to demonstrate that personally identifiable information (PII) has not been exposed during any point in the application development cycle. That’s especially important when it comes to mainframe data, which typically is used to drive transaction processing applications.

In general, O’Malley said the historic divide between mainframes and distributed systems is narrowing as organizations embrace DevOps processes. Instead of proponents of these platforms battling within organizations for control over specific classes of workloads, there’s more awareness of the need to leverage both platforms to drive a new generation of digital business applications, O’Malley said.

The challenge is that most mainframe applications are built and updated using waterfall methodologies. Compuware has been developing a series of DevOps tools for mainframe environments that are intended to modernize those processes. As the IT organizations that have mainframes adopt those tools, it becomes easier to federate application development and deployment across mainframes and distributed systems, O’Malley said.

Of course, this all assumes various teams within the IT organization can lay aside historic animosities. The shift to DevOps has always required as much process and cultural change as it does new technologies. But in the case of IT organizations that have mainframe teams, that shift may take years. The good news is a that a new generation of IT professionals doesn’t have much history with infighting within internal IT organizations. The simple fact is there are classes of workloads that run better on mainframes, O’Malley noted, but that doesn’t mean every workload running on mainframe is ideally suited for that platform—or conversely, that every workload running on a distributed system is ideally suited for that platform.

Arguably, the rise of DevOps processes might create an opportunity to revisit many platform decisions that were made in the heat of a larger argument. In the meantime, it’s clear that applications integration spanning multiple platforms is the new order of the day. The question now is how best to go about achieving that goal in a way that erases the divide existing between all the platforms that now make up the extended enterprise.

— Mike Vizard

June 29, 2018
GitLab Moves to Automate DevOps

GitLab is looking to eliminate the pain of setting up and maintaining DevOps processes by making available an option that automates DevOps processes end to end using a prescriptive approach defined by GitLab.

The latest version of GitLab includes an Auto DevOps option that organizations can employ to automate the building, testing, code-quality scanning, security scanning, license scanning, packaging, performance testing, deploying and monitoring their applications.

GitLab CEO Sid Sijbrandij said the company is now able to make this service available because GitLab 11.0 can now be deployed as a set of more integrated applications running on top of a cluster based on Kubernetes container orchestration software. That support for Kubernetes also makes it easier to deploy GitLab 11.0 in a public cloud or on-premises environment as needed. To facilitate that process, GitLab now includes templates that simplify the spinning up of Kubernetes clusters as needed, Sijbrandij said.

To further its support for Kubernetes, GitLab also decided to start deploying the software it makes available as a cloud service on Google Cloud Platform. Previously, GitLab had been committed to Microsoft Azure. Microsoft recently announced plans to acquire GitHub.

GitLab is all in favor of automating DevOps processes, but doesn’t think organizations should be forced to move everything into a public cloud to achieve that goal, explained Sijbrandij. Organizations can still elect to construct their own DevOps processes using GitLab as they best see fit.

But as interest in DevOps continues to rise, more organizations now would prefer to rely on a set of best practices that are defined to make them much easier to consume, he said.

GitLab 11.0 also adds security scanning capabilities for application built using .Net and Scala programming language in addition to existing support for C, C++, Java, Python, Ruby on Rails, Go and PHP.

In general, Sijbrandij noted that organizations that embrace DevOps usually find themselves trying to manage various islands of automation with mixed success. Auto DevOps is intended to provide a more comprehensive approach that eliminates the friction that often exists between those various islands of automation. Sijbrandij acknowledged that a prescriptive approach may not appeal to every IT organization, but as traditional enterprise IT organizations start to embrace DevOps, many of them prefer a more platform-centric approach that’s easier to both set up and maintain, simply because they lack internal DevOps expertise.

Sijbrandij also noted that as DevOps gains more traction in the enterprise, many of the decisions about what platforms to employ will be driven from the top down. Today, most acquisitions of DevOps tools and practices are driven from the bottom up, which accounts for why there are already so many silos of automation, he said.

Over time many organizations will conclude that the opinionated approach enabled by Auto DevOps will free developers to spend more time on writing code instead of on managing the infrastructure employed to create it, Sijbrandij said. Most traditional enterprise IT organizations today are at least aware they should be employing DevOps practices, they just know exactly what such an effort fully entails.

Thanks to advances in automation, many IT leaders may never know or care what specific DevOps processes are in place. After all, what most of them are primarily interested in how fast the next set of application code is going to be delivered.

— Mike Vizard

June 28, 2018
Splunk Pushes Into the Realm of DevOps

On the heels of its recent acquisition of VictorOps, provider of incident management software, for $120 million, Splunk is gearing up to expand its foothold in DevOps significantly.

Rick Fitz, senior vice president of IT Markets for Splunk, said the provider of widely used operational analytics software in the enterprise sees a significant opportunity to expand its presence across a range of DevOps processes.

Incident management is a natural extension of operational analytics, said Fitz, noting Splunk chose to acquire VictorOps because the investments the company has made in applying machine learning algorithms to monitoring IT events. That approach significantly reduces the number of irrelevant alerts being generated and provides actionable intelligence into potential events that could adversely impact IT operations.

Most IT operations teams suffer from alert fatigue, Fitz noted, and most alerts are ignored because of a lack of context. The combination of Splunk and VictorOps will result in alerts that more precisely identify the root cause of any IT issue, he said, and a better overall “systems of engagement” for IT operations teams in keeping with DevOps principles.

Splunk has been steadily expanding its focus on DevOps. Earlier this year the company announced Splunk Insights for Infrastructure, which IT organizations can host on an Amazon Web Services (AWS) public cloud to monitor IT infrastructure deployed anywhere. The latest versions of Splunk Cloud and Splunk Enterprise also make use of machine learning algorithms on top of a revamped metrics engine that enables IT administrators to monitor everything from CPU speeds and available hard disk space to temperature readings in internet of things (IoT) devices and sensors. Splunk recently also added connectors for Docker and Kubernetes, as well as the Apache Kafka messaging platform for streaming data in real time.

IT operations and cybersecurity teams already rely on Splunk operational analytics software extensively to identify anomalies. By investing in machine learning algorithms and acquiring incident management software, Splunk is moving to turn all the data it analyzes into actionable intelligence, which then could be shared in real time with developers to ensure application availability and optimize application performance.

While adoption of DevOps processes in traditional enterprise IT organizations remains spotty, IT vendors that focus on IT operations such as Splunk have clearly seen the writing on the wall. Fitz noted that investments made in machine learning algorithms, for example, will enable IT operations teams to more respond to changing application requirements with greater agility at a time when the IT environment has become exceedingly complex. That agility is critical for any organization engaged in digital business transformation, Fitz said, because invariably those efforts lead to more applications being deployed.

It’s not clear the degree to which incumbent providers of IT operations software will be able to remain relevant in the age of DevOps. But most of them certainly have the financial resources to at the very least acquire a portfolio of DevOps tools that will enable them to exert a lot more influence than many of them have to date.

— Mike Vizard

June 25, 2018
Oracle Advances AI Effort to Automate DevOps

Oracle today announced the general availability of an expanded Oracle Cloud Platform service that promises to automate most back-end DevOps processes by relying on a combination of machine learning algorithms and other forms of artificial intelligence (AI).

The Oracle platform-as-a-service (PaaS) environment has also been expanded to include Oracle Mobile Cloud Enterprise, Oracle Data Integration Platform Cloud and Oracle API Platform Cloud alongside existing continuous integration and continuous deployment (CI/CD) cloud service. Oracle also revealed today that later this year it will also add blockchain, security and management and support for additional database workloads, including OLTP and NoSQL, that expand on existing Oracle Database, Oracle Autonomous Data Warehouse Cloud, Oracle Analytics Cloud, Oracle Integration Cloud and Oracle Visual Builder services.

Siddhartha Agarwal, vice president of product management and strategy at Oracle, said via the cloud service, Oracle plans to automate DevOps processes to the point where organizations will be able to allocate most of their time and effort to building applications. Today, developers are spending as much as 50 percent to 60 percent of their time on DevOps processes rather than writing application code, he said, and the Oracle Cloud platform automates a broad range of operational functions including tuning, patching, backups and upgrades.

Oracle Cloud Platform is designed to be an infinitely elastic autonomous cloud service that can both anticipate application requirements and dynamically adjust to changing workload conditions. Over time, the platform also will be able to increasingly provide recommendations based on the characteristics of the application workloads being built and deployed, Agarwal said.

The Oracle API Platform Cloud service, for example, already continuously learns about usage patterns to recommend allocation limits, configurations and policies using predictive algorithms, he said.

Meanwhile, the Oracle Cloud Mobile Enterprise service provides access to machine learning algorithms that make it much easier to incorporate chatbots into mobile applications, Agarwal said. Machine learning algorithms are now also relied on to create Big Data lakes and the data pipelines needed to make that data available to application developers.

Those services are all extensions of an Oracle Developer Cloud service for building applications that supports build frameworks such as Maven, Ant, Gradle, npm, Grunt, Gulp and Bower, as well as command line interfaces for Docker, Kubernetes and Terraform. Frameworks such as JUnit and Selenium for both logic and UI testing are also included.

Agarwal said one of the primary reasons DevOps process have not been as widely adopted across the enterprise is that it’s simply too complicated for most IT organizations to set up and then continuously manage all the underlying infrastructure required. By moving more of the responsibility for the operations side of the DevOps equation on to an autonomous cloud service managed by Oracle, he said, it becomes simpler for enterprise IT organizations to focus their energy on application development processes.

It may take some time for enterprise IT organizations to get comfortable with ceding that level of control to a cloud service provider. But whatever DevOps path they choose, it’s apparent that machine learning algorithms coupled with other AI advances are about to automate broad swaths of the DevOps universe.

— Mike Vizard

June 13, 2018
Riverbed Throws Down APM Gauntlet

Riverbed Technology has expanded its approach to unifying application performance management (APM) and user monitoring based on a new architecture for its SteelCentral platform, now capable of supporting tens of thousands of agents monitoring billions of transactions per day.

Nik Koutsoukos, vice president of product marketing and product management for Riverbed, said auto-tuning and data compression mechanisms combined with cluster architecture now makes it possible to analyze all the data in the enterprise to determine precisely where bottlenecks are adversely affecting user experience.

In contrast, rival APM offerings only sample transactions and sacrifice metadata as well as depth in terms of being able to delve into a complete stack of software and associated IT infrastructure, he said.

Koutsoukos noted the way APM is being applied will fundamentally change as organizations embrace digital processes. Most organizations today apply APM sparingly across a limited number of mission-critical applications. But as business processes become digitized, customer satisfaction increasingly will be determined by the quality of the application experience. That can’t be accurately determined without being able to leverage a set of software-as-a-service (SaaS) applications capable of monitoring the entire IT environment, he said.

Riverbed, with this release of SteelCentral, is also adding analytics infused with artificial intelligence capabilities, as well as machine learning and predictive analytics to keep track of transaction trends over time. This release introduces a “Prism” report that analyzes longitudinally at the conversion funnel for a business transaction flow to visualize trends over time, spot issues and then resolve associated problems.

In addition, Riverbed is adding support for Riverbed Xirrus Wi-Fi access points, which the company acquired last year, to the SteelCentral platform.

Industry research suggest that only 5 percent of enterprise applications are actively monitored, Koutsoukos noted, but Riverbed is expecting that to change in a digital age where IT essentially has become the business. More senior business executives are soon going to be equating application performance with customer engagement and, by extension, opportunities to generate revenue.

Riverbed expects that monitoring all those distributed applications and associated IT infrastructure will be possible only by using a set of software-as-a-service applications, which Koutsoukos said in many cases will pay for itself by eliminating the need for various application and infrastructure monitoring tools in silos across the enterprise.

Given the relative light adoption of APM tools, the rise of digital business may provide an unexpected benefit for DevOps teams. As line-of-business managers demand more insight into the IT environment, the amount of metrics that should become available to DevOps teams should correspondingly increase. The challenge may lie in educating business managers why those metrics are relevant to them and then getting them to fund their acquisition.

In the meantime, DevOps teams should be prepared for a lot more questions relating to application performance coming from business managers. Not every one of those questions might be all that informed. But over time, an educated business executive always makes for the best DevOps customer.

— Mike Vizard

June 12, 2018
Wavefront by VMware Extends Monitoring Reach

The gap that exists between the DevOps tools typically made available to traditional enterprise IT sites that have standardized on VMware and what’s typically employed by web-scale companies continues to close.

The latest edition of the Wavefront analytics and monitoring tools from VMware now comes with pre-packaged support for a range of services running on the Microsoft Azure public cloud in addition to a significant expansion of support for a range of services provided by Amazon Web Services (AWS) and Google.

Rob Markovich, senior director of marketing for the VMware business unit, said Wavefront has added 35 “out of the box” integrations for third-party applications and services to the software-as-a-service (SaaS) application.

Wavefront has also added pre-packaged dashboards for Kong, Micrometer, Github and Bitbucket, VMware vRealize Operations, Hadoop MapReduce, Yarn, HDFS, Ceph, FluentD, Couchbase, Lighttpd, CoreOS, PHP-FRM, Papertrail, Rollbar, Suse Linux, Fedora Linux, FreeBSD, NetBSD, OpenBSD and Oracle Linux. Any Wavefront dashboard can be customized using more than 100 analytics functions, including correlation and predictive functions on any metric data source, he said.

Those additions come on the heels of a wave of investments VMware has made over the last few months spanning everything from cloud extensions to VMware vSphere to embedding analytics within the VMware vRealize IT automation framework.

Markovich said Wavefront is adding integrations at the rate of 10 to 20 a month—the total number he said should increase to more than 200 by the end of 2018. As organizations embrace various types and classes of cloud-native applications such as microservices, there is a much greater need for monitoring and analytics, especially as organizations begin to better understand the level of dependencies that exist between thousands of microservices, he said.

In addition, Markovich noted the number of companies encountering that challenge is also starting to increase as almost every company begins to realize it is a software company that happens to sell something else. That doesn’t necessarily mean every organization will be updating applications at the same rate as a web-scale company, but it does means existing IT processes will need to be modernized, he said—for example, more enterprise IT organizations are starting to create site reliability engineering (SRE) teams.

That shift may not result in every enterprise application being monitored, but it will most definitely increase the number of application workloads within those enterprise IT environments that are continuously monitored.

There is, of course, no single definition of what officially constitutes DevOps. Every organization will tailor DevOps best practices to fit within the confines of their existing IT culture. In some organizations that shift will be driven from the bottom up, while others will be transformed by an initiative led from the top. At this point, the single biggest inhibitor to DevOps adoption has more to do with IT culture than any given set of technologies. But regardless of an organization’s level of DevOps maturity, VMware is betting there will soon be many more traditional enterprise IT organizations employing monitoring and analytics a lot more broadly than ever.

— Mike Vizard

June 11, 2018
Puppet Report Sees Long DevOps Journey Ahead

A recent report published by Puppet suggests the level of DevOps maturity within most organizations is still relatively slight. In fact, most of the respondents reported high levels of manual work still occurring across configuration management, deployment, testing and change approval processes.

Alanna Brown, director of product marketing for Puppet, said the “State of DevOps: Market Segmentation Report” makes it clear that DevOps is being embraced to solve specific pain points with specific IT departments. As a result, silos of DevOps processes are springing up across the enterprise. That next challenge IT organizations will face is trying to unify all the DevOps processes, she said.

The survey finds deployment automation, version control, continuous integration and infrastructure automation were the most common starting points for DevOps. Less-common starting points were lean practices, visualization of key quality and productivity metrics and setting limits on work in progress.

Brown said the one surprising thing that study found is there is little correlation between the size of the companies surveyed and their relative DevOps maturity. Reliance on DevOps process may have more to do with needs arising from satisfying customer demand than anything else, noted Brown. The survey finds that media and entertainment and retail industry have the lowest percentage of low IT performers, while financial services, insurance and manufacturing companies had the highest proportion of low performers.

Not surprisingly, given the relative amount of DevOps immaturity, the survey also finds that reliance on IT automation frameworks is not yet especially widespread.

The Markets Segmentation report is based on the 2017 “State of DevOps” survey of 3,200 IT professionals that Puppet previously published. While it’s possible many companies may have advanced further down the DevOps journey since then, the report makes it clear that for both technical and cultural reasons fully embracing DevOps is an extended process. In fact, Brown said the report shows DevOps is still mainly being driven by the bottom of the organization up rather than by senior IT leaders. It’s only when DevOps success becomes visibly demonstrated that organizations attempt to replicate that success elsewhere in the organization. At the same time, widespread usage of DevOps processes suggests that DevOps itself is now much more than a grassroots movement, she said.

Change obviously comes hard to enterprise IT organizations. Many DevOps concepts were initially pioneered by web-scale companies that have the luxury of not having to support legacy applications and processes. Traditional enterprise IT organizations now typically are trying to support DevOps processes alongside process based on Waterfall and ITIL methodologies. Not every application being supported requires that number of release updates that many modern applications require.

Nevertheless, it’s also clear that as the number of applications being built, tested, deployed and supported continues to grow, the average IT organization is increasingly short-handed. Finding IT professionals with DevOps skill sets is a major challenge. But as more companies come to realize they are really a software company that happens to be selling a specific thing, the higher priority DevOps becomes.

— Mike Vizard

June 11, 2018
Aqua Security Survey Finds Sharp Rise in DevSecOps

A new survey of 80 cybersecurity professionals that attended the recent RSA Conference 2018 event finds the number of organizations that have a formal or informal DevSecOps team in place has increased by several orders of magnitude year over year.

The survey, conducted by Aqua Security, finds 62 percent of respondents have a formal or informal DevSecOps team. That’s up from last year, during which a similar survey found only 13 percent of respondents had a DevSecOps team in place.

It’s still early days when it comes to implementing DevSecOps processes. But Andy Feit, vice president of go-to-market for Aqua Security, said the survey also makes it clear that these formal and informal DevSecOps teams have access to budget dollars. More than three-quarters of respondents (76 percent) said their application security budget has increased over the past five years. One-quarter (25 percent) reported the application security budget went up between 10 percent and 30 percent, and another 14 percent said budget dollars being allocated to application security increased by more than 40 percent.

Well over half of respondents (57 percent) said they have the human and financial resources in place to implement DevSecOps. A total of 70 percent of respondents said they believe their culture can embrace the change needed to fuse security and DevOps. Nearly half the respondents (47 percent) reported they are fairly or very mature in their implementation of DevSecOps, while another 39 percent ranked themselves as maturing.

The three most important elements of DevSecOps as ranked by respondents ranked applying security across the app life cycle (61 percent), automating application security controls (52 percent) and involving DevOps in security processes (43 percent).

The shift to DevSecOps is occurring in tandem with increased reliance on microservices that are based on containers. As that shift occurs, Feit said IT organizations are rethinking their approach to application security. In delivering applications as a series of microservices, it becomes critical to apply a more granular approach to securing those applications that developers can apply as they build applications. Cybersecurity professionals will then be able to focus more of their efforts on crafting the security polices that developers implement, he said.

It may take a while longer before cybersecurity professionals gain enough confidence in containers to deploy them on physical servers with relying on a hypervisor to provide isolation. But it’s also now only a matter of time before developers insist on deploying containers applications on bare-metal servers to attain the maximum amount of performance possible by eliminating all the overhead added by a virtual machine. As that shift occurs, IT organizations will need new tools to secure and manage containers running on bare-metal servers.

As the same time, it’s clear that securing all those containers will require new processes such as DevSecOps because instead of patching applications to remediate them, developers will more easily replace specific containers to add new functions. Less clear is whether the adoption of DevSecOps will be driven from the top down or more as a grassroots initiative driven by the mutual self-interest of developers and IT security professionals. Regardless of the approach, cybersecurity as it is known today will not only be much different, but also arguably better.

— Mike Vizard

June 6, 2018