devopsy.kinsta.cloud

Category: News

Red Hat Adds Support for Nested Workflows to Ansible Automation Framework

Red Hat today announced it is adding support for nested playbooks created using the open source Ansible automation framework within one another, which, in turn, will make it easier to automate complex IT processes.

Bill Nottingham, product manager for Ansible, said the goal is to enable DevOps teams to reuse existing Ansible playbooks to kick off a series of nested IT jobs and workflows using version 3.4 of Ansible Tower, the console Red Hat provides for creating and managing Ansible playbooks.

Version 3.4 of Ansible Tower also now makes it possible to slice an IT job into a series of smaller jobs that can be distributed across a cluster to accelerate execution. That capability makes it possible to scale out the processing of an Ansible playbook, he said.

Finally, Red Hat also announced that Ansible Tower. 3.4 is now able to run on Red Hat Enterprise Linux in Federal Information Processing Standard (FIPS) compliant mode.

Nottingham said Red Hat expects the ability to reuse Ansible playbooks within a set of nested processes will encourage IT organizations to create more playbooks now that it’s easier to reuse them as a set of modular components. IT organizations can even make launching jobs dependent on the completion of other jobs using a scheduling mechanism within Ansible Tower, he added.

Although adoption of IT automation frameworks has been uneven, the last few years has seen IT organizations rely more on them to manage tasks as IT environments become more complex. That level of complexity will only increase as IT organizations deploy more applications that are based on microservices created using containers that need to be updated frequently. IT automation frameworks also go a long way toward making up for what has become a chronic shortage of skilled IT administrators. That capability is especially critical as both the number of applications and the rate at which they are being updated continue to accelerate.

Most IT administrators have limited programming skills, which is why a declarative approach to IT automation in the form of an Ansible open source project has been gaining significant traction. In fact, thanks to automation, traditional IT metrics such as the number of servers being managed per administrator increasingly are becoming obsolete.

It may take a little while longer before IT automation frameworks are the rule than the exception. But as the IT community now approaches the end of the second decade of the 21st century, reliance on manual processes that were developed at the end of the last century is no longer viable in this era of distributed workloads. In fact, regardless of where applications are deployed, the expectation in the DevOps era is that existing IT operations teams will be able to manage them without having to hire additional IT administrators.

— Mike Vizard

January 9, 2019
7 DevOps Lessons in 2018: The Path to DevOps Success in 2019
We all learn from mistakes, right? But it would be better if we learned faster and didn’t repeat them in our future exercises. And this is exactly what we will discuss here in this blog.

For a while now, we’ve been overwhelmed by the idea of the DevOps principle. We love how the collaboration between development and operations provides room for automation, continuous integration/delivery and enhanced time-to-market.

But what about the tiny shortcomings we overlook in the process of continuous delivery?

Listed below are some of the don’ts—or, rather, lessons learned from our DevOps implementation in 2018:

Gauging Employee Capacity Over DevOps Delivery

When Carmen DeArdo, Tasktop’s senior value stream management strategist, posed two questions to a crowd of 200 people, they had no answer to give. What were the questions, you might ask?
- How many treat their delivery pipeline tooling as an integrated product with a product owner and an architect?
- How many have any measure of how long it takes for them to deliver a feature or defect?
Companies treat their delivery pipeline tooling as different components along the delivery chain. And, when it comes to measuring time taken, all that matters is getting the product to the finish line.

These components are important if companies need to avoid obvious mistakes on the path to success. Consider the above questions the next time you set out on your DevOps mission. Within this aspect, measuring team happiness is as important as an integrated delivery pipeline tooling, and time is taken to introduce a feature.

Companies need to strike a balance between managing work and achieving team happiness. This is important if the company has a long-term vision. Unhappy employees burdened with work don’t deliver the expected results. A sustainable pace helps companies ensure that employees don’t succumb to pressure.

Revise the Management Strategy

Organizations need to encourage their managers in a way that they are not put off by the DevOps process but rather motivated to build and maintain their team.

Most organizations emphasize giving managers incentives to deliver expected results, maintain quality, expand team size, set immediate goals and rake larger profits. However, this strategy could backfire when applied to a DevOps implementation.

Companies instead should encourage their managers to create an environment where the teams grow and become flexible, not only contributing to that process but also adding value to other processes, hence, the organization’s overall success. This thought process will lead to a chain of positive outcomes.

Upskilled and Cross-Skilled

Gone are the days when specializing in a particular skill was rewarding! The competitive market is looking for a workforce that is upskilled and cross-skilled. In short, employees need to be a package of multiple skills, with an emphasis on soft skills.

Being multi-skilled not only supports transformational goals but also supports an organization’s goals. When the lack of new skills becomes a constraint, companies must invest in hiring individuals to propel transformation, which is equivalent to investing in automation.

Automation ≠ DevOps Success

Somewhere between adopting the DevOps culture and being DevOps-equipped, professionals have shifted from the purpose of DevOps to automation.

In the process, people have lost control over the overall management of DevOps. Either professionals are in a situation in which the code is not built in the intended way or that the automated part is managed but the steps required for automation are not.

Organizations instead should refocus their attention on the scalable nature of DevOps, building a new, fully automated process rather than automating an end-to-end process over time, as it is difficult and also time-consuming. Hence, automation does not equal the DevOps mission accomplished!

From Idea to Blackboard

DevOps once was more an idea of a team discussion rather than full-fledged process. But we saw 2018 transform DevOps from a mere idea to a part and parcel of everyday business—so much that it defines the way businesses plan their finances, regulations and organizational strategy as a whole.

Additionally, DevOps experts in 2018 emphasized the need for value delivery than just focusing on details of technical practices. This can be achieved by constructing a managerial framework that bridges the gaps between business and technology.

Relieve Your DevOps of Old Tech

Last year also witnessed DevOps professionals moving toward new technology such as containers, Kubernetes and serverless. Why? It’s obviousthese technologies enable DevOps to deliver its promises. Trying to innovate the DevOps process or even innovate its end product with old technology will only take you backwards in the DevOps process.

In 2019, we should realize that holding on to old technology will mean limiting your organization’s capabilities and impact.

Identifying the Right DevOps Adoption Patterns

While there are several DevOps adoption patterns out there, some organizations choose a central DevOps team enabling standard CI/CD tooling. The approach is in sync with DevOps thought leaders’ approach of reducing global complexity.

However, this approach fails at catering to the needs of different teams. With the focus only on addressing CI/CD tooling, many centralized teams struggle with adoption.

In another approach, companies seek to engage ambitious and autonomous tools to use DevOps tools and practices.

This approach tends to match the common DevOps belief, ‘First prove that new work methods fit the enterprise, then spread.’ However, these teams are only successful in delivering projects with high levels of automation involved but have quickly failed to convert team-level experience to company-level.

A 2019 DevOps adoption approach should focus on having high levels of team autonomy and reducing global complexity.

Here are some tips to help you achieve this:
- The central architecture team collect and share recommendations about languages, libraries and tools.
- Teams consider these recommendations and experiment to see if there’s an opportunity for greater gain.
- If things aren’t working, teams can change change and undo dead-end technology decisions/ideas.
Now that we are ready with our lessons, it’s time to go live! Are you ready for your DevOps 2019 showdown?

— Veritis
January 3, 2019
Anaxi Delivers Project Management App for DevOps

Anaxi, a provider of project management software designed specifically for DevOps teams, has made its web application generally available. The web application complements an existing iPhone application, while an Android version of the company’s project management application is still under development.

Company CEO says Marc Verstaen said that as DevOps has evolved around multiple repositories, IT organizations are finding it challenging to keep track of code from projects they are using within what applications. Anaxi is designed to not only make it simpler to navigate repositories, but also apply analytics to track individual developer productivity and team performance. Project managers now can, for example, analyze efforts in terms of code added and removed, refactoring and code churn on a weekly basis.

Armed with that intelligence, IT operations teams will be better able to prioritize development plans based on the dependencies that exist between the various components that make up an application, said Verstaen. The number of those dependencies is only expected to increase as organizations increasingly shift away from building monolithic applications in favor of more complex microservices architectures that promise to make the overall business more agile.

The fundamental project management issue with repositories such as GitHub is that there is no way to categorize all the project labels that get entered as text. That makes it difficult to monitor and track all the tasks associated with a specific label or even simply browse from one task to the next, Verstaen said. Via Anaxi, project managers can edit their issues and pull requests, which are then synchronized back to their GitHub and Jira projects.

It’s not clear to what degree the lack of sophisticated project management tools has hindered adoption of DevOps in the enterprise. Legacy approaches to application development provide project managers with a rich portfolio of applications that may serve to bias them toward one style of application development over another. But given the pressure organizations are now under to become more agile, project managers need to evolve alongside the rest of IT organization.

Before too long many organizations may also find themselves trying to manage projects spanning multiple repositories. It’s not uncommon for development teams to favor one repository over another. Standardizing on one repository would be preferred, but not every project manager has the political capital inside their organization required to force such a decision. Many projects also now span multiple companies, each with their own repositories, that project managers may find themselves forced to navigate.

At the same time, business leaders are making it clear they want more visibility into the pace at which applications are being developed whenever those applications are expected to generate revenue or improve the overall customer experience. In fact, project managers who can ensure projects are delivered consistently on time and within scope are invariably considered among the most valued of employees.

— Mike Vizard

December 19, 2018
AWS Finally Embraces On-Premises IT

Amazon Web Services (AWS) announced this week it will make available instances of its IT infrastructure available in on-premises IT environments, which it will then manage on behalf of customers. The announcement was made at its AWS re:Invent 2018 conference.

AWS CEO Andy Jassy said AWS Outposts platforms, scheduled to be available in 2019, will come in two flavors: one will run the same stack of software AWS uses to manage its public cloud, while the other will be based on the software stack VMware currently makes available on the AWS cloud.

VMware announced it will make available a managed service of its own for AWS Outposts based on its entire platform stack, in addition to making its management and networking software in the form of VMware Cloud Foundation available on instance of AWS EC2. That move represents a significant expansion of the VMware approach to hybrid cloud computing because AWS EC2 is based on the open source Kernel-based virtual machine (KVM) rather than the VMware hypervisor.

Regardless of path chosen, each Outposts platform will function as an extension of the Amazon Virtual Private Cloud (VPC) service, with connectivity being provided via the closest AWS Region located to that on-premises platform. Both Amazon VPC and AWS Outposts will be tied into the AWS Control Tower service to create a common management plane.

After years of making the case for moving all workloads into the public cloud, Jassy admitted this week that there are instances when performance and compliance concerns will result in some workloads never moving to the public cloud. In response to demand from customers who want to be able to deploy and manage the same infrastructure on-premises as they have in the cloud, Jassy said AWS is now committing to making racks of systems available via an AWS managed service.

The challenge DevOps teams will now face is determining the degree to which they will want to integrate their DevOps processes with managed services provided by AWS, VMware or any number of third-party service providers. In some cases, DevOps teams may simply decide that additional layer of management adds to much complexity. In other cases, the decision might lean more toward allocating more resources to application development, as IT operations spanning hybrid clouds become more of an automated service provided by an external vendor.

Heading into 2019, it appears the specious debate over public clouds versus on-premises IT environments is coming to an end. Not only will there be workloads running in both environments for the foreseeable future, but a recent study conducted by International Data Corp. (IDC) notes that 80 percent of IT organizations surveyed have repatriated workloads back into on-premises IT environments from public clouds. To make matters even more complex, a whole new generation of so-called cloud-native applications based on microservices enabled by containers running on Kubernetes clusters is adding even more complexity to IT environments.

The goal, of course, is to make modern businesses more agile. The irony is that achieving that goal appears to requires paradoxically making IT environments more complex than ever.

— Mike Vizard

November 29, 2018
VMware Wavefront Adds AI, Distributed Tracing

VMware has updated its Wavefront monitoring service to include support for distributed tracing along with anomaly detection capabilities enabled by machine learning algorithms.

Stela Udovicic, senior director for product marketing for Wavefront by VMware, said the addition of the distributed tracing support, now available as part of a public beta, means that a single monitoring service now can provide metrics, histograms and the tracing function required to provide a holistic view of the IT environment. Those capabilities eliminate the need to employ multiple services to achieve the same goal, she noted.

In contrast, Wavefront makes it easier to search for traces containing a specific service or application programming interface (API) to determine which ones have errors or long response time. Additionally, DevOps teams can filter the trace search to show traces containing spans from a given cluster or shard.

At the same time, VMware is adding an AI Genie capability that promises to make it easier to troubleshoot existing needs and identify future application and IT infrastructure requirements, said Udovicic. That data is collected in real time and presented in a way that allows even the most novice users to visualize using analytics tools built into the Wavefront services, added Udovicic.

Wavefront is based on an agentless architecture that in part makes it possible for the service to process millions of metrics, histograms and traces per second. That capability is especially critical in IT environments that have embraced microservices based on containers that tend to expand across an enterprise IT environment, said Udovicic. Wavefront already supports Kubernetes clusters.

In general, Udovicic noted that developers tend to embrace a variety of open source approaches to monitoring applications as they build their applications. But a SaaS application such as Wavefront makes it easier for enterprise IT organizations to apply monitoring across a broad range of applications. To facilitate that transition, Wavefront provides an OpenTracing/OpenCensus compliant solution that includes a drop-in replacement for the Zipkin and Jaeger distributed tracing software, which is at the core of many open source monitoring tools.

VMware is clearly betting that increased reliance on AI will push organizations toward relying more on cloud services. Machine learning algorithms require access to massive amounts of data before they can construct AI models capable of accurately predicting events. The cost of collecting and storing all that data, plus the expertise required to train the AI models, are beyond the capabilities of most DevOps teams.

Most enterprise IT organizations have applied monitoring tools to only their most critical applications, mainly because of cost concerns. But as applications based on microservices proliferate across the enterprise, it’s becoming apparent that all the dependencies that will exist between various application services will need to be continuously monitored. The only issue now is determining how best to achieve that goal as part of an integrated set of DevOps processes.

— Mike Vizard

November 26, 2018
Red Hat Injects DevOps Flexibility into RHEL 8

With the beta release of the next version of Red Hat Enterprise Linux (RHEL), Red Hat is setting the stage for making it easier for DevOps teams to consume emerging operating system services without having to upgrade their entire operating system.

The beta release of RHEL 8 adds an Application Streams capability designed to make it possible to leverage userspace more flexibly, as modules running in userspace now can be updated more quickly than the core operating system.

Matt Micene, the technical product marketing manager for RHEL 8, said it’s also now possible for multiple versions of the same package—for example, an interpreted language or a database—to be made available via an application stream. That means different DevOps teams will be able to more easily work with different versions of various classes of technologies without having to wait for the next upgrade of the operating system, he said.

As part of that focus on flexibility, Red Hat is also moving to make it easier for organizations that have embraced microservices based on containers to build applications. Open source tools such as Buildah for container building, Podman for running containers and Skopeo for sharing and finding containers are now fully supported in the operating system. Red Hat is also extending support for container networking using IPVLAN, which enables containers nested in virtual machines (VMs) to access networking hosts. There’s also a new TCP/IP stack with Bottleneck Bandwidth and Round-trip propagation time (BBR) congestion control. As organizations increasingly adopt containers, many of them are starting to make operating systems decisions based on which platform has the most containerized optimized services built in.

Other capabilities being added include support for OpenSSL 1.1.1 and TLS 1.3 along with Systemwide Cryptographic Policies; a Stratis file management system for dealing with lots of volumes; a Composer tool for building custom images that can deployed on hybrid clouds; support for the Yum 4 packager; and a new web console for managing the RHEL environment that presents administrators the same user interface experience regardless of their experience.

Micene said Red Hat is trying to strike a balance between stability and IT agility. There are plenty of organizations that still prefer to upgrade their operating systems at very well-defined intervals. But there are also an increasing number of organizations that want to be able to take advantage of the latest IT innovations without having to wait for an operating system upgrade. Many of those organizations increasingly view IT as being core to their ability to compete, he said.

Over time most organizations will develop a more schizophrenic approach to IT. There will be some application workloads where stability trumps all other requirements. At the other end of the scale, innovation will be the most prized attribute. To one degree or another, every workload is going to fall along a spectrum between those two extremes. The challenge is defining the right mix of DevOps processes to serve the needs of every and any workloads regardless of its attributes.

— Mike Vizard

November 26, 2018
Cisco Looks to Build DevOps Community

Cisco Systems is making a concerted effort to create an era of détente between networking professionals and the rest of the IT operations teams that have embraced DevOps practices.

Susie Wee, senior vice president for the DevNet community at Cisco, said the goal is to provide network operations (NetOps) teams the skills required to programmatically expose a range of self-service capabilities to developers.

At the same time, Cisco is encouraging developers to deploy applications directly on routers and switches that now incorporate general-purpose processors. Those processors would run applications in a way that significantly reduces network latency, while the custom ASICs that Cisco develops would continue to handle all the networking functions.

Wee said that dichotomy is now driving Cisco to classify two classes of developers within its DevNet community. The first is aimed at traditional application developers and the second community is more focused on managing infrastructure as code.

Cisco is now extending that latter initiative into the realm of software-defined wide area networks (SD-WANs). The company has added integrated firewall, intrusion prevention and URL-filtering technologies to its SD-WAN platform. In addition, there are code samples, videos, learning labs and sandboxes available on Cisco DevNet that are intended to make easier to learn how to programmatically manage Cisco SD-WANs using open application programming interfaces (APIs).

Cisco claims to now have 530,000 developers participating in DevNet. One the one hand, the company is trying to entice NetOps teams that have been reluctant to give up legacy command line interfaces to modernize their networking environments. On the other hand, Cisco is trying to attract more application developers who increasingly find themselves encountering latency issues as they move to deploy applications in highly distributed computing environments, such as an Internet of Things (IoT) application.

Over time, Cisco and other providers of network operating systems also will be moving away from monolithic architecture to embrace microservices, which would make it possible to programmatically invoke networking services on a more granular level.

Of course, there may be some developers who would prefer to programmatically take control over networking along with the rest of the IT infrastructure. But Cisco is clearly betting most organizations will want to make it easier for their NetOps and DevOps teams to work more closely together. Today, most enterprise IT organizations can spin up a virtual machine in a matter of minutes; provisioning the network connections to that virtual machine, however, is still measured in days and weeks.

Other networking infrastructure companies besides Cisco have realized the need to make networking more programmable. But in terms of the resources the company is making available to solve that problem, it would appear to ready to make a significantly larger commitment.

— Mike Vizard

November 20, 2018
IBM Allies with ServiceNow to Bridge DevOps Divide with ITIL

IBM and ServiceNow today announced an alliance under which IBM Global Technology Services (GTS) will collaborate with ServiceNow to make DevOps processes and events managed via the IBM Cloud Migration Factory visible to a cloud-based IT service management platform from ServiceNow based on the ITIL framework.

Jim Comfort, general manager for cloud services at IBM GTS, said that from a governance and compliance perspective it has become clear IT organizations need more visibility in to DevOps processes. In general, enterprise IT organizations are increasingly adopting DevOps processes to accelerate application development and deployment, while still relying on ITIL to manage governance and compliance, he said.

IBM GTS, via the alliance with ServiceNow, will be able to bridge that divide by integrating ServiceNow with a set of tools and services IBM provides across hybrid cloud computing environments that are based on DevOps process.

The IBM Cloud Migration Factory is based on a methodology IBM developed to move applications to cloud. IBM Services claims it has completed more than 100,000 migrations. In addition to allying with ServiceNow, a new toolset is being added to IBM Cloud Migration Factory that employs algorithms based on the migrations IBM has completed that improve planning accuracy and uncover application dependencies. Included in that portfolio is cloud brokering software that IBM gained via the acquisition of Gravitant in 2015.

Comfort said the alliance with ServiceNow will make it possible to have DevOps processes and events register automatically in the change management database (CMDB) provided by ServiceNow. That’s critical because it should allow IT organizations to maintain governance and compliance without having to impose an overhead that otherwise would slow down application development and deployment using DevOps processes, he said, adding there’s no need to impose an artificial construct on top of a DevOps process.

As hybrid cloud computing continues to evolve, Comfort said IBM GTS expects IT organizations will be relying on a mix of ITIL and DevOps processes for the foreseeable future. In fact, he noted that while managing one to ten DevOps processes is relatively simple, keeping track of hundreds of DevOps processes requires a more static set of processes to maintain governance and compliance. The IBM approach is to create a unified approach to integrating DevOps and ITIL processes that doesn’t require organizations to integrate a variety of point products on their own.

Proponents of DevOps processes have been making a case against ITIL processes that they tend to view as being too rigid to support agile application development. Comfort said the next iteration of the ITIL framework will incorporate many of the concepts advocated by DevOps proponents. But the two frameworks will remain distinct.

The alliance between IBM and ServiceNow represents a clear signal that DevOps is going mainstream in enterprise IT environments. The challenge now is finding a way for organizations that have spent more than a decade adopting ITIL processes to embrace DevOps processes with a minimal amount of friction possible.

— Mike Vizard

November 16, 2018
Virtual Instruments Extends Scope of AIOps Platform

Virtual Instruments has extended the reach of its AIOps platform to add application service assurance, predictive capacity management, workload infrastructure balancing and problem resolution and avoidance capabilities.

Based on a combination of machine learning, statistical analysis, heuristics and expert systems technologies, VirtualWisdom is designed to enable DevOps teams to be able to apply analytics to resolve issues in near real time versus having to convene a “war room.”

Len Rosenthal, chief marketing officer for Virtual Instruments, said the whole war room concept has become antiquated in the age of DevOps. Instead of wasting time having individual departments within an IT organization coming together to defend their innocents every time an issue arises, VirtualWisdom identifies the likely source of the problem instantly.

The latest release of VirtualWisdom adds to that a predictive capability that identify workload balancing opportunities intended to prevent problems from arising in the first place, he added.

As part of an ongoing effort to infuse AIOps into DevOps processes, the latest release of VirtualWisdom also adds integration with application performance management (APM) tools from Dynatrace, in addition to enhancements to existing support for APM tools from AppDynamics, a unit of Cisco.

VirtualWisdom is also now able to collect Linux and Windows operating systems along with metric generated on Amazon Web Services (AWS) or Microsoft Azure. There also a now iSCSI wire data monitoring support in the NAS Performance Probe, which complements existing NFS and SMB monitoring capabilities.

Rosenthal said the rate at which applications are being developed and deployed soon will force the AIops issue in most organizations. As those applications become more distributed across hybrid cloud computing environments, it’s become impossible for any single IT team to manually keep track of all the dependencies that could adversely impact all their applications, he noted.

While increased reliance on artificial intelligence (AI) is all but inevitable at this point, it’s less clear to what degree IT organizations themselves will be reorganized as a result. Most organizations have embraced DevOps to bridge the divide between their IT operations and application development teams. But many of the silos within their IT operations teams soon may be automated out of existence as the need for dedicated compute, storage and networking specialists declines. In some instances, developers are already taking advantage of application programming interfaces (APIs) to assume control over IT infrastructure end to end. That scenario may become even more common as AI continues to automate more of the rote IT operations tasks.

None of that means there won’t be a need for someone to architect the IT operational workflows required to support applications at scale. But it does mean many lower-level administrator tasks soon might be sharply reduced or eliminated altogether. The challenge IT organizations soon will face is retraining those administrators to handle tasks beyond what’s possible to automate using AI.

In the meantime, organizations will continue to experiment with AI. Not every organization is comfortable enough with AI to turn over control to what many still view as a “black box” that doesn’t provide any visibility into those processes being automated. But as more of that visibility is provided, it’s now only a matter of time before AI platforms take move control of the IT environment.

— Mike Vizard

November 13, 2018
Survey: Rapid Automation of IT Ops Looms Ahead

The rate at which IT operations will become automated is about to accelerate significantly over the next two years. A global survey of 1,500 senior IT leaders conducted by Cisco Systems finds that 64 percent of respondents today would describe their approach to IT operations as either reactive (26 percent) or proactive (38 percent), but within two years more than two-thirds expect their approach to be either become predictive (33 percent) or preemptive (33 percent). Only 14 percent of respondents describe their IT environments as being preemptive today.

In general, the survey finds 88 percent of IT leaders said their investment in IT operations over the past 12 months had improved external customer satisfaction, while 89 percent said there have been improvements in innovation. But only 26 percent collect data on an ongoing basis and even fewer (17 percent) employ any kind of real-time automated analysis, the survey finds.

Nevertheless, 42 percent of respondents said they expect artificial intelligence (AI) to have the biggest impact on their ability to automate. More than half (51 percent) said they already rely on AI to some extent today to automate IT operations.

A full 82 percent also already collect operational and performance data about their security infrastructure.

Joseph Bradley, global vice president for IoT, Blockchain, AI and Incubation Business at Cisco, said much of the investment in automating IT operations is being driven by the realization that IT has become a profit center rather than cost center. As organizations increasingly realize they are a software company that happens to make something, they are looking to maximize the return on their investments in IT wherever possible, said Bradley, adding as a result, line of business (LOB) executives are exercising more influence over what applications get built and deployed within the context of an overall digital business transformation strategy.

Naturally, all that increased appreciation for the value of IT is putting more pressure on IT organizations to modernize their processes. As the number of applications that need to be built, deployed and maintained continue to increase, the need to embrace DevOps processes becomes a greater imperative. To facilitate that shift across enterprise IT environments that now routinely span multiple clouds, Cisco has been making a two-fold case for centralizing the management of highly distributed IT environments and upgrading to next-generation software-defined infrastructure that makes use of machine learning algorithms to automate IT management.

Cisco is not the only IT vendor pursuing a similar strategy. The success of those strategies, however, depends as much on the ability of the IT organization to implement the processes required to modernize their IT environments as much as it does the technology platforms. That creates something of a chicken-and-egg relationship between processes and platforms. It is difficult, but not impossible, to implement some level of DevOps without having a lot of automation. But applying DevOps at any meaningful scale within an enterprise undoubtedly will require a lot more automation than currently exists within most IT environments.

— Mike Vizard

November 9, 2018