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: The npm registry suffers spam infestation, and Microsoft makes Google sad. (more…)

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: The npm registry suffers spam infestation, and Microsoft makes Google sad. (more…)

New Relic is preparing to extend the capabilities of its observability platform by making use of both additional machine learning algorithms and the ChatGPT generative artificial intelligence (AI) platform.
Peter Pezaris, senior vice president for strategy and experience at New Relic, said during an interview on an episode of TechStrong TV that a prototype of an AI model created using machine learning algorithms will automatically notify developers when code in a production environment is not performing well—right within their integrated development environment (IDE). The notification will then take developers to the precise line of code identified as the root cause of the issue, he said.
DevOps teams will need to add two lines of code to applications running in production environments to take advantage of this capability. New Relic also plans to use a similar approach to integrate with generative AI platforms such as ChatGPT to create suggestions for fixing code, he added. ChatGPT now makes it possible to create entire programs in ways that output HTML and JavaScript code, so DevOps teams should expect to be able to use the platform to create natural language queries that invoke the proprietary query language New Relic makes available for its observability platform, he noted. Conversely, ChatGPT will make it possible to explain how a piece of code functions in plain language, Pezaris added.
Previously, New Relic employed a similar approach to integrate its observability platform with machine learning operations (MLOps) platforms used to build and deploy AI models. This was part of a larger effort to integrate MLOps and DevOps workflows, added Pezaris.
These AI extensions to the New Relic platform are part of a larger effort to extend the reach of the New Relic One observability platform further left toward developers. Most recently, New Relic added a free CodeStream module to its observability platform to give developers access to metrics and telemetry data that will enable them to write higher-quality code faster.
That approach eliminates the need to wait for IT operations teams to surface issues that usually don’t manifest until long after the code in question was originally developed. The overall goal is to provide development teams with frictionless access to observability data at every stage of the software development life cycle to reduce mean-time-to-detection (MTTD) and mean-time-to-resolution (MTTR) of issues.
Organizations should also be able to reduce technical debt faster by making it easier to identify issues that, for example, adversely impact application performance.
In general, most organizations are still in the early stages of achieving full-stack observability. A recent New Relic survey found only 27% of respondents have achieved full-stack observability, and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found.
On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability, and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals. However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.
The hope is, of course, that by augmenting DevOps teams with AI capabilities, the number of those outages will be dramatically reduced in the months and years ahead.

Vega Cloud today made a commitment to save customers at least 10% on their cloud infrastructure spending or it won’t charge for its software. Vega Cloud’s software automates cloud infrastructure management.
The Vega Cloud platform enables IT teams to connect, automate, manage and optimize new and existing networks, applications and other multi-cloud IT environments from a single console. As part of those capabilities, the company includes cost allocation and cost identification tools using a curated set of data to surface daily recommendations for cost improvements.
Vega Cloud CEO Kris Bliesner said the goal is to provide a financial operations (FinOps) capability within the context of a platform capable of acting on those recommendations that, on average, reduces cloud costs by 15% to 25%.
During uncertain economic times, IT leaders are under more pressure than ever to reduce costs. FinOps has emerged as a discipline for applying a set of best practices for specifically reducing cloud costs. In addition to reducing cloud costs, Vega Cloud is also making a case for reducing the total cost of IT by relying on a single automation framework to manage multiple clouds.
In the cloud era, many organizations have found themselves employing multiple clouds, each of which requires a separate set of tools to manage. IT teams then need to hire additional staff to manage each of those tools. As a result, the total cost of IT increases with each additional platform added to the overall IT estate.
Many organizations, of course, have allowed the number of platforms they manage to proliferate. This is because many application deployment decisions were driven by developers who can easily provision cloud infrastructure on their own. However, as concerns over the cost of cloud computing continue to rise, many organizations are revisiting how cloud infrastructure resources are used. Many of those reviews are being driven by finance teams that want cloud costs to become more predictable as cloud computing continues to account for a much larger percentage of the IT budget, noted Bliesner.
In fact, one of the challenges IT leaders have is finding a way to make sure developers and DevOps teams are more motivated to reduce costs rather than focusing entirely on how fast they can build and deploy applications, he added.
The reality is the average developer doesn’t need application build infrastructure running 24/7, so application development and testing is a great place to focus on cutting cloud costs initially, noted Bliesner. There’s also plenty of opportunity to better schedule workloads to reduce costs by relying more on lower-cost instances of cloud infrastructure, he said.
DevOps engineers, by nature, don’t want to be inefficient, so the issue comes down to providing them with the tools needed to identify resources that are being wasted, added Bliesner.
Most cloud service providers, of course, provide tools that enable IT teams to optimize spending, but Bliesner said those tools don’t go deep enough in terms of exposing issues. As a provider of an independent management framework, Vega Cloud is more committed to providing cost optimization capabilities that can be applied to multiple clouds, he added.
In general, interest in controlling cloud costs has risen sharply. Vega Cloud has been engaged with more customers researching this issue in the last four weeks than in the last three years, said Bliesner. The challenge—and the opportunity—is to not just cut cloud costs but also identify patterns that make it easier to predict them, noted Bliesner.
At this juncture, cloud costs are coming down. The only issue left to be determined is whether that goal will be accomplished with precision versus a fiat that adversely impacts an organization’s ability to continue to build and deploy software.

Developer experience (DX) is in the zeitgeist, and for a good reason. Digital demands are increasing, yet the market faces cautious IT budgeting, workplace burnout, and high resignations. The idea is that quality developer experience can help keep the remaining talent happy and increase productivity. And organizations are considering many strategies for increasing DX, such as creating more usable interface interfaces, maintaining intuitive documentation and abstracting complexity with more automation and low-code.
Another way to increase productivity is by slimming down the time it takes to test and deliver software. There are many potential hurdles in the way of deploying new code, and a cumbersome pipeline can easily take a programmer out of the flow. The practice of streamlining this toolchain is known by some as Developer Productivity Engineering (DPE). DPE focuses on improving developer productivity through accelerating DevOps processes, like CI/CD pipelines.
I recently met with Hans Dockter, founder and CEO of Gradle, to understand the core tenants behind DPE. According to Dockter, the dialogue with the toolchain is a developer’s bread and butter, and optimizing this exchange is vital for quickly validating new ideas. Below, we’ll seek to understand what DPE is and how it might increase the pace of software delivery. We’ll also consider some methods for implementing DPE in practice.
Engineers are always experimenting with new feature development. “A developer needs to have a dialogue with their toolchain to see if their hypothesis makes sense,” explained Dockter. Yet, there are many potential barriers to instant feedback. For example, a toolchain may be comprised of code compilation, static code analysis, unit testing, performance testing, security testing and other checks. Running new changes through a CI/CD pipeline can take anywhere from a few seconds to minutes or hours. In his work, Dockter has even encountered teams that deal with a 24-hour feedback cycle time.
Long wait times can be taxing as they demand users to switch contexts. Neuroscientists say that multitasking depletes glucose in the brain and leads to exhaustion. Similarly, Dockter argued that long waiting periods with the toolchain can take developers out of the flow and slow down the pace of software delivery. “You cannot have a good developer experience without good productivity.”
Furthermore, he added that engineers often encounter untrustworthy signals from their toolchains. If testing suites produce too many false positives, for example, you can lose faith in the tooling altogether. This equates to a bad experience and may result in developers overlooking important signals that do matter.
DPE is all about improving developer efficiency. And quickening the feedback cycle is one method to enhance developer productivity. According to Dockter, DPE applies a few strategies to streamline this feedback loop and shorten the timeframe:
DPE principles have already been applied at DoorDash, LinkedIn, Netflix and other organizations.
In the last few years, DX has moved from niche to mainstream, said Dockter. In fact, DX has even entered the C-suite, as certain companies have embraced the role of chief developer experience officer CDX). And with the emerging discipline of platform engineering, we’re seeing an even greater focus on streamlining internal DevOps workflows.
And although platform roles may have been viewed as second-class engineers in the past, said Dockter, they are held in high esteem nowadays. “It’s as important as the other engineering work we’re doing,” he said. Developer productivity engineering seems to align with these principles, helping organizations manage the effects of an exponentially expanding code base. In the end, an investment in DPE, like platform engineering, could bring more satisfactory working conditions and accelerate the pace of software development.
“DX is a transformative opportunity, but most companies invest incrementally. The economic benefits are transformative for companies developing infrastructure to get more output from their developers.”

env0 today announced it has added support for additional infrastructure-as-code (IaC) tools and the Microsoft Azure DevOps platform to its workflow automation and management platform.
Fresh from raising an additional $35 million in funding, env0 CEO Ohad Maislish said while Terraform remains the most widely used IaC tool, there are now more organizations using alternatives such as CloudFormation from Amazon Web Services (AWS) along with Pulumi and Terragrunt.
Other capabilities added to the env0 platform include automated drift detection, multi-tier workflows, auditing, external logging platform integration, support for plug-ins and expanded role-based access controls and OpenID Connect (OIDC) authentication.
Finally, env0 is extending its existing Terraform support to include support for remote backend, module registry, remote plan, and the ability to plan and apply pull requests. The capabilities are especially critical for organizations that are now building microservices-based applications that require more sophisticated workflows to provision infrastructure resources, noted Maislish.
Most IaC tools are designed to enable developers to address technical implementation and provisioning issues without regard for user experience, security and governance, or business goals. The env0 platform makes it possible to create infrastructure environments with guardrails in place that enable DevOps teams to centrally address governance issues, noted Maislish.
In general, there’s now a lot more focus on continuous delivery (CD) as organizations look to continuously update applications, said Maislish. That requires a more structured approach to provisioning infrastructure across teams of developers that is managed by a platform engineering team, he added. The challenge is that CD is dangerous—in the sense that mistakes can easily be made, noted Maislish.
It’s not clear whether organizations are embracing platform engineering to centralize the management of DevOps workflows, but the number of organizations that have mastered CD best practices remains low. Most organizations are adept at continuous integration (CI), but given the number of unique platforms on which applications are deployed, CD has proven more challenging to adopt. In theory, a platform engineering team should make it easier for DevOps teams to define a consistent approach to CD that could be adopted across an organization.
Regardless of the DevOps approach, the overall goal is to improve developer productivity. The problem is that in the absence of any guardrails, developers have been provisioning cloud infrastructure as best they can. Not surprisingly, cloud computing environments are rife with misconfigurations that create vulnerabilities that cybercriminals have become more adept at exploiting. The fundamental issue is not such much the cloud infrastructure that is available as much as it is the processes employed to provision the resources. In their rush to build and deploy applications, developers will sometimes ignore best practices unless guardrails force the issue.
One way or another, IT organizations are exercising more control over cloud computing environments as the security of software supply chains becomes a bigger issue. The only thing that remains to be resolved now is how to put much-needed guardrails in place in a way that adds the least amount of friction possible.

A survey of 1,300 technology and data executives found that more than a decade after the initial rise of cloud computing, organizations are still struggling to manage these environments.
Conducted by Wakefield Research on behalf of NetApp, the survey found 98% of respondents reported their business has been impacted by everything from the increasing complexity of data and heightened cybersecurity risk to lack of visibility into business operations and staff burnout.
Top challenges include cybersecurity risk (45%), staff not taking full advantage of business applications (44%), increased skepticism about the cloud from leadership (44%), lack of visibility into business operations (42%), going over budget (37%) and burning out staff (31%).
A full 88% continue to encounter technical challenges, including data mobility between clouds (33%), security risks (33%) and interoperability between cloud services (30%).
The top drivers of cloud investments are scaling artificial intelligence (AI) and automation (39%), followed by driving business innovation (35%) and creating digital experiences (34%).
Organizational challenges encountered include having a clear vision for cloud strategy (32%), establishing the right level of governance (31%) and managing costs (30%). A full 84% are under pressure to show short-term return on investments (ROI) in cloud computing platforms, with 76% noting CFOs and other business leaders are skeptical of savings. Nearly half of the tech executive respondents (49%) reported that when cloud strategy discussions occur, cost concerns come up often or all the time. As a result, nearly three-fourths of executives (74%) said tiered workloads are either very or extremely important, the survey found.
Other factors impacting multi-cloud strategy include environmental, social and governance (ESG) concerns (79%) and data sovereignty (74%), the survey found.
Ronen Schwartz, senior vice president and general manager for cloud volumes at NetApp, said as more organizations employ multiple clouds, total costs tend to rise. Each cloud platform requires mastering another control plane, which means someone in the IT organization must have the right skills to manage, he noted. IT leaders are attempting to exercise more control over cloud deployments, but developers, for a variety of reasons, have already deployed workloads across multiple cloud computing environments, added Schwartz. One approach to achieving that goal is to make sure data is stored on the least expensive tiered service possible for any given specific use case, he noted.
Less clear is whether an uncertain economy might push organizations to consolidate workloads on fewer cloud computing platforms. Even then, the cost of moving a workload is not trivial given the proprietary application programming interfaces (APIs) that many developers have likely invoked as DevOps built and deployed cloud applications.
Of course, there is no going back; the issue now becomes how to define a set of best practices for managing cloud computing environments in a way that minimizes costs. It turns out that cloud computing can be more costly than an on-premises IT environment simply because the infrastructure resources made available to developers are almost infinite. In the final analysis, however, that can turn out to be too much of a good thing—especially if organizations wind up spending more on IT to support these environments. Many of those environments are not rigorously managed because, for example, developers may not be inclined to spin down a development environment on a Friday because it takes too long to spin it back up the following Monday.
One way or another, however, a level of long overdue scrutiny of cloud computing costs may be on the horizon.

Enfabrica Corp. today emerged from stealth at the MemCon conference to launch a class of processors for networking in cloud computing environments that are optimized for moving data between CPUs, graphical processor units (GPUs), accelerators and memory.
Enfabrica CEO Rochan Sankar said the Accelerated Compute Fabric (ACF) enables scalable, streaming, multi-terabit-per-second movement of data in a way that also reduces the total cost of cloud networking. That’s critical as the amount of data being generated by applications infused with artificial intelligence (AI) capabilities that require access to larger amounts of data continues to increase, he added.
At the same time, DevOps workflows will need to evolve as it becomes possible to compose AI fabrics of compute, memory and network resources capable of scaling to tens of thousands of nodes versus relying on top-of-rack network switches, network interface cards (NICs), PCIe switches and CPU-controlled DRAM that creates too many bottlenecks when moving large amounts of data.
Enfabrica’s first chip, the Accelerated Compute Fabric Switch (ACF-S), supports standards-based interfaces, including multi-port 800 Gigabit Ethernet networking and high-radix PCIe Gen5 and CXL 2.0+ interfaces. The company claims that Enfabrica’s ACF-S is the first data center silicon product in the industry to deliver headless memory scaling to any accelerator by incorporating CXK memory bridging to enable a single GPU rack to have direct, low-latency, uncontended access to local DDR5 DRAM at more than 50 times greater capacity than GPU-native High-Bandwidth Memory (HBM). That approach should enable customers to cut their cost of GPU compute by an estimated 50% for large language model (LLM) inferencing and 75% for deep learning recommendation model (DLRM) inferencing, the company claimed.
Simulation tests suggested ACF-enabled systems could achieve the same target inference performance using only half the number of GPUs and CPU hosts compared to the latest GPU servers.

The cost of building AI applications today is prohibitive for many organizations, but as processor advances are made, there may come a time when the cost of building and training AI models substantially decreases. Advances in networking processor technologies will, as a result, accelerate the pace at which network operations are integrated into programmable DevOps workflows versus relying on dedicated networking teams to manage top-of-rack switches.
It’s not clear yet whether cloud service providers will embrace ACF, but the chip makes it clear there is a significant opportunity to reduce the amount of networking infrastructure needed to build and deploy AI applications.
Less clear, of course, is to what degree machine learning operations (MLOps) might ultimately be folded into DevOps workflows. While developers of AI models create a unique type of software artifact, they still need to be integrated with application code running in a production environment via application programming interfaces (APIs). One way or another, the total cost of building and deploying applications infused with AI models will need to decline.
In the meantime, the networking bottlenecks that conspire to make deploying distributed computing applications difficult today may soon become overcome as latency issues are increasingly overcome.

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.
Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:
M-Logic
Dallas, Texas/Chicago, Illinois
Security Engineering – DevOps
$150,000 to $160,000
SimplyHired
Cisco Systems
Waltham, Massachusetts
DevOps Engineer
$134,200 to $197,700
Indeed.com
AT&T
McLean, Virginia
DevOps/Python Specialist
$111,000 to $140,000
Monster.com
Capgemini FS
Charlotte, North Carolina
AEM Full Stack Developer
$110,000 to $130,000
Dice.com
Booz Allen Hamilton
McLean, Virginia
Lead DevOps Engineer
$99,300 to $212,000

Tabnine has extended its alliance with Google Cloud to advance the adoption of generative artificial intelligence (AI) to automate the writing and testing of code.
The generative AI platform provider has already developed its own large language model that is hosted on Google Cloud. Tabnine is now also committing to leveraging the large language model that Google is developing to automate software development life cycle processes.
Brandon Jung, vice president of ecosystems for Tabnine, said it’s apparent that application development and deployment teams will be making use of multiple large language models across SDLC workflows. Not all those large language models will be developed by one single platform provider, he noted.
Rather than being dogmatic about large language models, Tabnine plans to make it possible to invoke multiple models via application programming interfaces (APIs) that are integrated with development environments, he added.
The Tabnine platform supports multiple programming languages, including Python, Java and JavaScript and is designed to be integrated with integrated development environments (IDEs) such as Visual Studio Code and Jetbrains. The company also previously integrated its code completion tool with the GitLab continuous integration/continuous delivery (CI/CD) platform. The overall goal is to make it easier for developers to automatically write code based on custom models using approved source code hosted in a secure private repository.
Generative AI creates a large language model that assesses the probability of what the next line of code will be based on what has preceded it. It’s not likely DevOps teams will be replaced as generative AI is extended across workflows, but the overall size of those teams might shrink as it becomes possible to do more with fewer people. At the same time, the barrier to DevOps adoption will also fall as AI platforms make it simpler for more organizations to embrace DevOps best practices.
The challenge will be making sure the data collected to train AI models is of a high enough quality to ensure the desired outcome. Organizations will need to find a way to apply generative AI to data models that have been validated by DevOps teams.
One way or another, it’s only a matter of time before generative AI capabilities are applied more broadly. Platforms such as OpenAI’s ChatGPT are only the tip of an iceberg that impacts almost every manual process, including software development and deployment. The issue will be determining how quickly those innovations will become practical enough to employ.
In the meantime, it is already apparent generative AI platforms are having a significant impact on the rate at which code can be developed. Inevitably, that means the amount of code moving through DevOps pipelines at any one time should increase significantly. DevOps teams should expect generative AI technologies to be applied both before and after application code is built and deployed, noted Jung.
In the meantime, the biggest issue is, arguably, keeping up with a rate of generative AI innovation that is occurring faster than many organizations can absorb.

A survey of senior IT leaders suggested the level of confidence in application modernization projects that many organizations initially had is now starting to wane.
The survey polled 200 senior IT leaders at organizations with more 1,000 employees and was conducted by Global Surveyz Research on behalf of EvolveWare, a provider of platform for automating application modernization processes. The survey found 70% of respondents reported they were confident or very confident in their understanding of their applications when they prepared for modernization. However, that level of confidence dropped to 41% at the planning stage and even lower (28%) at the point the project began, the survey found.
More than half of respondents (51%) are already experiencing or anticipating critical issues that need to be addressed immediately, the survey found. The top areas of importance are understanding the parts of the code that contain business policies (47%), database access details (43%) and understanding the complexity (40%).
EvolveWare CEO Miten Marfatia said the survey makes it clear organizations are encountering issues associated with capturing tribal knowledge that has been lost mainly because the teams that initially built an application are no longer with an organization. In fact, the survey found a full 81% of respondents reported they currently have or anticipate challenges hiring or retaining talent to support legacy applications. Nearly half (46%) currently don’t have enough talent available to manage legacy applications.
The survey found the primary reason these initiatives are launched is to boost employee productivity (40%), followed by retiring mainframe infrastructure (37%), reducing the dependency on legacy code (36%), reducing maintenance costs (30%), improving customer experience (29%) and cloud migration (22%). Most of these projects are generally focused on critical applications (55%) as well as applications that have few or no dependencies (55%), the survey finds.
The primary success metrics for assessing these projects, however, are improving customer experience (46%), the readiness to migrate to the cloud (46%) and meeting the performance requirements of the modernized application (45%).
Less than a third of respondents (31%), however, reported having access to modern tooling. More than half would like to automate code transformation and business rules extraction (BRE) while 40% would like to automate documentation.
Nearly two-thirds (64%) said freezing code during the modernization process would have significant business and financial consequences, with 59% noting that finding a way to modernize applications without freezing code is at the top of their technology wish list.
Application modernization efforts usually have multiple goals. IT teams are usually motivated by a desire to reduce the amount of time and effort required to support legacy applications that are generally less efficient than modern applications. In addition, many IT teams are also looking for ways to reduce the total cost of running those applications, especially during uncertain economic times. Business leaders, meanwhile, are funding digital business transformation initiatives that typically require some level of modernization of legacy applications.
Regardless of motivation, it’s apparent many IT teams initially underestimate the amount of effort required to achieve those goals.