Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: A new Linux kernel drops and layoffs at Amazon Web Services point to trouble. (more…)
Category: DevOps Toolbox
-
Linux 6.3: What’s New ¦ AWS Layoffs are a Worry
-
InfluxData Makes Processing Observability Data at Scale More Efficient
InfluxData today made available an update to its open source time series database that can now analyze metric, event and trace data in a single datastore with unlimited cardinality in terms of how they are aggregated.
The company is now making available a single-tenant instance of InfluxDB as a managed service alongside its already-existing multi-tenant cloud service that is based on a serverless architecture.
Finally, InfluxData also announced that later this year it will make available InfluxDB 3.0 Clustered and InfluxDB 3.0 Edge to provide a curated version of the database that organizations can deploy themselves where they best see fit.
InfluxData CEO Evan Kaplan said InfluxDB has been developed to support a wide range of emerging applications that require access to time series data, including the observability platforms core to DevOps workflows that require visibility into metrics, events and trace data.
Over the past three years, InfluxDB has been revamped to run on a columnar engine, dubbed IOx, that leverages the open source Apache Arrow memory format and written in the Rust programming language. Kaplan said that approach makes it possible to continuously ingest, transform and analyze hundreds of millions of time series data points per second without limitations.
At the same time, InfluxDB takes advantage of high compression object storage to reduce the total cost of storing all that data. It also provides interoperability with Open Data Architecture (ODA) to integrate with data lakes based on open source platforms such as DataFusion, Flight SQL and Parquet that are being advanced by the Apache Software Foundation.
The arrival of version 3.0 of InfluxDB comes as many DevOps teams are starting to struggle with the amount of observability data being generated. DevOps teams want to be able to move beyond monitoring a set of pre-defined metrics and query data in a way that enables them to surface anomalies indicative of a potential issue before there is a major disruption to an application service.
One of the major challenges today is the tradeoff between how much data is collected and analyzed versus the cost of processing and storing it. InfluxDB provides a mechanism for analyzing high cardinality data involving metrics, events and traces cost-effectively.
Observability is, of course, only one of several use cases for a time series database capable of processing data in near-real-time. As organizations embrace digital business transformation initiatives, they need to be able to process data in near-real-time at the point where it is being created and consumed. Those applications won’t necessarily replace existing applications based on batch-oriented processing but, over time, they create two distinct classes of applications that process data in fundamentally different ways. The challenge, as always, will be defining the DevOps workflows required to manage applications running on multiple distinct types of architectures.
-
Cycode Adds ASOC Module to Streamline DevSecOps Workflows
Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.
Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.
That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.
In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.
While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.
As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.
Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.
Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.
-
Sendbird Adds API to Invoke ChatGPT From Mobile Apps
Sendbird today added an application programming interface (API) to its low-code platform for building mobile applications that enables developers to add bots that communicate with OpenAI’s ChatGPT.
Shailesh Nalawadi, head of product for Sendbird, said this API makes it possible to add the ability to communicate directly with the generative artificial intelligence (AI) platform from within both new and existing applications in just a few minutes.
Most developers will add natural language processing (NLP) interfaces to complement the graphical user interfaces that most mobile applications today surface, added Nalawadi. It will be up to each development team to determine how best to employ that capability, but Sendbird envisions, for example, a health care application being able to invoke ChatGPT to answer queries, he noted.
In the longer term, Sendbird will provide APIs to enable mobile app developers to invoke a wide range of large language models (LLMs). LLMs are increasingly being developed for generative AI platforms and are being optimized for a range of use cases.
While OpenAI’s generative AI model is being widely used thanks mainly to Microsoft, there are already LLMs that are being created for a narrower range of use cases using much less data. DevOps teams should expect APIs invoking any number of generative AI platforms from within applications to become commonplace in the weeks and months ahead as more end user come to expect to be able to engage these platforms from within almost every application Sendbird’s chatbot API can now be invoked by more 1,300 existing mobile applications alone.
In general, developers have tended to employ chatbots sparingly because they are often too scripted and inflexible. ChatGPT, conversely, provides a much more open-ended user experience. Organizations can also feed historical conversations or customer relationship management (CRM) data to ChatGPT to drive more personalized and accurate responses, given the veracity of some of the data used to train ChatGPT.
A recent survey of digital quality testing professionals conducted by Applause, a provider of a platform for accessing a networking of independent testers, found nearly one-third (30%) of respondents are dissatisfied with their current chatbot, IVR and conversational assistant experiences, with wrong answers (29%) and a lack of understanding (24%) as the top two reasons cited. The results indicate there is plenty of opportunity for improvement.
Nearly three-quarters (74%) said they had a positive experience with the ChatGPT generative artificial intelligence (AI) platform, with more than two-thirds (67%) reporting the platform provided helpful answers to questions. In terms of work-related tasks, most said ChatGPT would either be “very” (43%) or “somewhat” (37%) helpful.
It’s apparent now that generative AI platforms are about to change the way humans engage with machines. Instead of always creating an abstraction to interface with a machine it’s now feasible for interactions to occur between them using language humans readily understand. As such, the way applications are built and employed is about to fundamentally change in ways that are difficult to predict.
-
DORA Report 2022: The Magnitude of Software Supply Chain Security
The term ‘software supply chain security’ (SSC) can be interpreted in many ways. Following the White House executive order in May 2021 and the European Cyber Resilience Act (CRA) of 2022, both governments and corporations are taking a more active role in ensuring their software is secure. Fundamentals such as having a software bill of materials (SBOM) and being able to cross-reference it with known common vulnerabilities and exposures (CVEs) are now the standard, but supply chain security covers far more than just the software that builds your products.
To create certainty and clarity, leading standardization bodies such as OWASP, OpenSSF and others have set up ongoing efforts to define and mitigate SSC threats. They have active working groups, SIGs and TACs all working in vendor-neutral ways to help define and solve parts of the SSC problem.
A great example of this is the continuous work being done by Google Cloud’s DevOps Research and Assessment (DORA) initiative. More specifically, the subject was reflected in the September 2022 DORA report that focused on security in general and supply chain security in particular. Using the Supply-chain Levels for Secure Artifacts (SLSA) framework as well as the NIST’s Secure Software Development Framework (SSDF) as benchmarks for actively addressing supply chain security issues, the researchers assessed how organizations were successful in approaching and addressing threats at all levels of the organization.
My view of the major findings of the DORA report are summarized below.
Who Owns Software Supply Chain Security?
The report stated that organizations should empower individual teams and developers to “own” security while administering a consistent security policy and posture across its products. While I agree with this, we need to examine both sides of the ‘ownership’ coin. By nature, this hybrid approach creates complexity—and even friction—between the security team that, by definition, is responsible for all facets of security and the developers that are being tasked to ‘fix’ security issues in addition to their daily tasks. There has to be common ground between developers, their tasks associated with security and the security team.
Individuals in organizations that build software care about what they build; they have a stake in the overall success of the final product and this feeling of ownership strengthens that level of care. However, asking for such ownership while adding a security component to the mix without providing sufficient knowledge, tools, proofs, and “power” to make decisions could lead to a lack of trust, confusion, execution problems and frustration. To alleviate this, the security team should provide developers the tools, education and resources they need to feel empowered to enhance security efforts at the source. Organizations that provide evidence in a scalable, digestible manner are successful in building trust and creating common ground between the developer, security and the security team.
There’s also another dimension that could potentially create silos between developers and security teams rather than bringing the two together: There’s no one single security team or owner of SSC. SSC is tricky to define as a category; it involves shift left security, runtime security and everything in between. Some portions of it are being governed by the security office, some by AppSec, some by DevOps and some by the developer. The ownership of each isn’t well-defined and the entire effort is very difficult to consolidate as one process or methodology. In addition to upskilling the developer with tools and training, long-term education, thought leadership and access to good technology are the keys to gradually reduce these friction points..
Security Processes Slow Down Development
Defining the tools, methodologies and processes that should be employed in an organization to add sufficient security while not impacting development speed is not a trivial task.
The following are four principals I think correspond well with the SLSA framework and that help address the development slowdown challenge:
Set preventive measures: Avoid using known vulnerable and malicious packages from the beginning of development. By eliminating vulnerabilities introduced in first-party code (due to bad coding practices) as well as misconfigurations, wrong encryption and secrets exposures, you are preventing known threats from entering your product.
Examine proactively and continuously: The security state of software changes because the software itself always evolves and new vulnerabilities are continuously being introduced. It makes a software artifact that was just secured suddenly become susceptible to attack. This requires continuously rescanning and revisiting software artifacts as well as frequently recalculating any potential risk.
Set preemptive measures: Create a plan that initiates a prompt response when a potential risk is discovered. Both development and security teams should create the plan for decision making and execution. The measures should include ways to identify vulnerable artifacts across development and production, how to understand exploitability and true impact and how to prioritize and remediate accordingly.
Do it all in an automated manner: Create automated processes based on reliable data and scanning tools to dramatically reduce the effort needed by developers and DevOps teams.
DORA report co-author Eric Maxwell said one of the main principles is to remain tool- and platform-agnostic while focusing on capabilities and practices. From that perspective, automation is essential and it is enabled by security-as-code. Having a common language–code–allows teams to communicate about security as well as collaborate. It drives the things we discussed earlier around democratizing the security process and helps break down silos.
The DORA findings—alongside the topics described above—encourage community awareness and continued shared efforts to bring much-needed attention to software supply chain security. Gradually, SSC security will evolve, but as it does so, the only way to properly address it is by ensuring the developers and security teams are on the same page and both have ownership of responding to and resolving issues as they appear. For more in depth review of the DORA report I encourage you to view Leap Left for Security: The DORA Report Roundtable.
-
Atlassian Embeds Generative AI Across Cloud App Portfolio
At its Team 23 conference today, Atlassian announced it is adding an artificial intelligence (AI) capability to the enterprise editions of its cloud portfolio to automate a wide range of routine tasks.
Sherif Mansour, distinguished product manager for Atlassian, said Atlassian Intelligence uses natural language to drive a virtual agent that resolves routine help desk issues from within Slack or Microsoft Teams. Atlassian Intelligence can also identify incidents that have been previously resolved along with issues that are related to one another.
In addition, IT teams can also leverage Atlassian Intelligence to create summaries for projects being tracked using the company’s Jira project management software, noted Mansour.
The overall goal is to streamline incident management processes while also making it simpler for application stakeholders to collaboratively participate in software development, he added.
Generative AI capabilities are likely to be infused into almost every imaginable application going forward, but Atlassian is clearly at the forefront of an effort to leverage AI to improve productivity. For example, instead of spending time handling routine issues that increase the amount of daily toil, IT teams should be able to spend more time resolving more complex issues, noted Mansour.
The cumulative effect of AI should result in a significant decrease in the backlog of tasks that many IT teams would otherwise have to manually perform, he noted.
It’s not clear just yet how much generative AI will impact the way software is developed and how IT is managed, but it’s already apparent that fundamental change is on the way. The Atlassian Intelligence approach is intended to augment the capabilities of IT teams so they can do more with the same number of or fewer personnel.
The challenge IT teams will face is identifying tasks they couldn’t previously accomplish simply because there wasn’t enough time available.
Fundamentally, generative AI changes the way humans interact with machines. Instead of requiring a developer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. That makes it possible for anyone to make use of large language models used to create generative AI platforms to, for example, automate a routine task or, one day soon, create code.
At this point, like it or not, the generative AI genie is out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of IT organizations, the ultimate impact should involve less drudgery as many of the tasks that make managing IT tedious are eliminated.
Hopefully, as IT continues to evolve, there will still be plenty of demand for human expertise. For better or worse, the nature of the expertise required, however, will undoubtedly be at a much higher level than it has been for the past four decades or more.
-
AI Chatbots: Game Changers for DevOps Transformations
In today’s fast-paced digital world, organizations are constantly looking for ways to accelerate their software development processes and ensure the seamless integration of their development and operations teams. DevOps has emerged as a popular methodology to achieve this goal, but even with its adoption, many companies still face challenges in their transformation journey. AI chatbots can revolutionize DevOps transformations, making them more efficient and effective than ever before.
How AI ChatBots Improve DevOps Transformations
Enhance collaboration by automating routine tasks and facilitating communication between teams: AI chatbots can handle repetitive tasks, freeing up team members to focus on more critical issues while also providing a centralized communication hub for both development and operations teams.
Expedite incident management by providing real-time alerts and smart recommendations: AI chatbots can analyze logs and system metrics to quickly identify issues and suggest the most appropriate resolution steps, reducing downtime and improving overall system performance.
Streamline deployment and monitoring processes using AI-driven automation: AI chatbots can intelligently manage deployment pipelines, ensuring that the right code gets deployed to the right environments while also monitoring system health and performance in real-time.
Offer real-time analytics and insights into the development pipeline for informed decision-making: AI chatbots can gather and analyze data from various sources, providing valuable insights that help teams make better decisions related to code quality, release schedules and resource allocation.
Identify skill gaps and recommend targeted training resources for continuous improvement: AI chatbots can analyze team performance and individual skill sets, helping organizations identify areas for improvement and providing personalized learning resources to close those gaps.Roadmap to Implement AI Chatbots in DevOps Transformations
Evaluate your organization’s current DevOps maturity and identify areas for improvement: By assessing your existing processes and infrastructure, you can better understand the gaps where AI chatbots can make the most significant impact.
Select an AI chatbot platform that aligns with your organization’s technology stack and goals: Choose a platform that complements your existing tools and supports your specific DevOps objectives to ensure seamless integration and adoption.
Define and prioritize use cases for AI chatbot implementation in your DevOps processes: Identify the key areas where AI chatbots can provide the most value, such as incident management or deployment automation and prioritize their implementation accordingly.
Develop a phased implementation plan that includes integration, testing and deployment of AI chatbots: Create a step-by-step plan to integrate AI chatbots into your existing DevOps processes, ensuring proper testing and validation at each stage to minimize potential disruptions.
Train your teams on how to leverage AI chatbots effectively and continually refine their usage based on feedback and performance metrics: Provide education and training resources to help your team members understand how to use AI chatbots to their full potential and foster a culture of continuous improvement.Benefits of AI Chatbots in DevOps Transformations
AI chatbots offer several benefits that can significantly improve DevOps transformations, including:
Increased efficiency by automating manual tasks and streamlining processes: This leads to faster development cycles, quicker releases and a more agile response to changing business requirements.
Enhanced collaboration and communication among development and operations teams: AI chatbots can break down silos between teams, fostering a more collaborative and unified approach to software development and delivery.
Faster incident resolution and reduced downtime: With AI chatbots’ help, issues can be identified and resolved more quickly, minimizing the impact on end users and maintaining a high level of service quality.
Real-time insights into the development pipeline for more informed decision-making: AI chatbots enable teams to make data-driven decisions by providing real-time analytics and insights into various aspects of the development process, such as code quality, resource allocation and release timelines.
Continuous learning and improvement through AI-driven recommendations: By identifying skill gaps and suggesting targeted training resources, AI chatbots can help teams continuously improve their knowledge and expertise, ultimately leading to better performance and more successful DevOps transformations.Summary
In conclusion, AI chatbots are poised to revolutionize DevOps transformations by addressing common challenges, enhancing efficiency and fostering a culture of continuous improvement. By automating routine tasks, facilitating communication and providing valuable insights into the development pipeline, they can significantly improve the effectiveness of DevOps processes. As organizations continue to adopt and refine their DevOps strategies, incorporating AI chatbots into their workflows will become increasingly essential to remain competitive in the ever-evolving digital landscape.
-
Mobb Launches Community Edition of Automated Remediation Tool
Mobb today made available a free community edition of a namesake tool that creates fixes to open source vulnerabilities. The fixes are based on the results of code scanning by a static application security testing (SAST) tool.
Fresh from raising $5.4 million in seed funding, Mobb CEO Eitan Worcel said the company developed a tool that creates validated patches based on the scan results of third-party SAST tools from Checkmarx, GitHub and Snyk. Initially, the tool is aimed at Java vulnerabilities.
Worcel said that most vulnerabilities can be traced back to eight types of mistakes that developers routinely make. The company created a pattern for those common mistakes, along with patterns to fix them, called Mobb rules. That ability enables Mobb to accurately produce a code fix that both remediates the vulnerability and adheres to the correctness of the language to eliminate code defects. Mobb then makes available a patch to address those issues in a way that can be readily downloaded and applied by developers. Mobb does not automatically apply those fixes because most developers prefer to review them first, noted Worcel.
The Mobb approach eliminates the need for IT teams to sort through SAST scans themselves, which can result in the discovery of thousands of vulnerabilities that might theoretically need to be fixed. Each vulnerability, at minimum, is going to require 30 minutes to fix, so the Mobb platform provides a better return on investment and reduces patch backlogs, added Worcel.
For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing which types of vulnerabilities should have a higher remediation priority.
Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities being discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool addresses that later issue by automatically creating the necessary patch, said Worcel.
Many organizations just allocate junior developers to the task of remediating vulnerabilities, which Worcel noted frees up more experienced developers to focus on writing additional business logic.
There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that have already been developed.
One way or another, the process by which patches are prioritized, developed and then applied has long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities wherever they may be found.
-
Endor Labs Taps ChatGPT to Identify Secure Open Source Software
Endor Labs has launched DroidGPT, an extension of its software for assessing risks in open source code. DroidGPT integrates the ChatGPT generative artificial intelligence (AI) platform to make it simpler to discover the most secure version of an open source package.
That capability makes it possible for developers to launch a natural language query from within the Endor Labs platform that asks ChatGPT to identify, for example, the most secure logging modules of Java applications.
Endor Labs CEO Varun Badhwar said the goal is to make it simpler to apply guardrails to application development processes that today rely heavily on reusing open source packages. Developers often wind up using an older version of those packages that are not as secure because a known vulnerability has not been remediated.
Endor Labs’ Dependency Lifecycle Management platform applies graph analysis to identify the depth of dependencies that exist within an application. That capability makes it simpler to identify where vulnerable components have actually been employed within an application. DroidGPT extends that capability to identify the most secure versions of those components that developers should be using, said Badhwar.
Having a full understanding of their dependency graph also lets customers generate and analyze accurate software bills of materials (SBOMs) as applications are dynamically updated, noted Badhwar.
The level of dependency on open source software packages to create applications has risen sharply over the years. An analysis of nearly 2,000 software packages published by Endor Labs found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer used an open source component. Functional dependencies are created whenever developers download a third-party component, so it is crucial to assess the risk levels created by those dependencies.
Fortunately, in the wake of a series of high-profile breaches, there has been increased focus on securing software supply chains. The ongoing challenge is most developers don’t have a lot of cybersecurity expertise, so as contributions are made to open source projects it’s relatively easy for mistakes to be made. The simple truth is many applications deployed in production environments are riddled with known vulnerabilities that have yet to be addressed. DroidGPT is designed to make it simpler to begin the process of remediating software vulnerabilities in applications as they are built and after they are deployed.
There is no doubt that it will take years before organizations are able to implement a set of truly mature DevSecOps best practices to teach developers how to build more secure applications. That journey, however, needs to begin with tools that enable them to address fundamental issues that dependencies inevitably create. After all, the best way to combat application vulnerabilities is to make sure they don’t manifest themselves in code in the first place. Making it easier to update applications using older versions of open source modules is nothing less than critical at a time when cybercriminals are getting more adept at exploiting them.
-
PagerDuty Bets on AIOps and Automation to Simplify IT Management
PagerDuty this week made generally available an artificial intelligence for IT operations (AIOps) platform that leverages the data model embedded in its incident management software to reduce the amount of time required for an AI platform to learn how an IT environment operates.
Jonathan Rende, senior vice president and general manager for PagerDuty, said that approach enables the PagerDuty AIOps platform to begin surfacing valid recommendations sooner than other AIOps platforms. Other platforms first need to be integrated into IT environments by an expensive team of consultants and integrators, he added. The PagerDuty approach makes the benefits of AIOps immediately available to both IT operations teams and application development teams alike, he said.
The arrival of PagerDuty AIOps comes on the heels of the launch of PagerDuty Process Automation, a platform for orchestrating automation across multiple platforms that is integrated within PagerDuty Operations Cloud. That capability makes it possible for organizations to centralize the management of islands of automation that have emerged across the enterprise without having to replace any framework that has already been deployed, said Rende. There are also more than 700 integrations between PagerDuty AIOps and the PagerDuty Operations Cloud platform.
Like other platforms, PagerDuty AIOps relies on machine learning algorithms and an AI model created by PagerDuty to correlate events so that the platform can put them in context. Incident response recommendations are then made, which an IT team can accept and automatically implement or reject. The platform then uses those inputs to surface more accurate recommendations over time, said Rende.
The platform will also automatically group apply defined rules coupled with its machine learning capabilities to aggregate alerts. That capability reduces the overall alert noise that might otherwise be generated, noted Rende.
Organizations are looking to invest in AI and automation more heavily at a time when many of them are reducing the overall size of their IT staff, said Rende. The challenge with AI, however, is that it can take six months or more for a rival AIOps platform to learn enough about an IT environment to begin making recommendations. The PagerDuty approach takes advantage of the data within the PagerDuty incident management platform to train an AI model more quickly, in a way that reduces the time to generate valid recommendations to a matter of days, noted Rende.
PagerDuty has been building that AI model for the last four and a half years with that specific goal in mind, he added.
It’s not clear how quickly organizations are embracing AIOps, but as IT environments continue to evolve, many once-manual tasks are being automated. There is a natural fear of the impact those advances might have on specific roles within an IT organization, but as IT environments get more complex, there will always be a need for IT personnel that can focus on higher-order tasks, said Rende.
Overall, the rate of IT staff turnover should also decline as much of the toil that contributes to burnout is also eliminated.
It may be a while yet before AI becomes pervasively applied to manage IT, but the proverbial genie is not going back into the bottle. The challenge is determining precisely where the line between the man-machine interface with IT environments is today versus where it might be tomorrow.