Most IT teams regularly use a range of tools to monitor application performance. But in an era where applications run everywhere from the cloud to the edge of the network, the visibility provided is limited. The metrics and analysis shown are roughly akin to driving a vehicle on a rainy night and only being able to see a few yards ahead. Instead, managing modern applications requires platforms that provide the equivalent of radar and sonar capabilities so that IT teams can better understand the application environment, which today remains too hidden to effectively manage.
Achieving this goal requires a deeper understanding of how various Internet services impact application performance. Almost every application depends on the quality of one or more of these services. The more application services you rely on the Internet, the more likely you are to encounter intermittently performance-impacting issues that are difficult to understand, let alone predict.
Unfortunately, most IT teams today have limited ability to discern how Internet service performance affects their applications. Of course, there are Internet Performance Management (IPM) tools that display network performance metrics. The challenge and opportunity now is to combine these metrics with all the other telemetry data DevOps teams collect from various application performance management (APM) and observability platforms to monitor and troubleshoot application environments.
Why applications are becoming more distributed
First, with the rise of cloud computing, the proliferation of software-as-a-service (SaaS) applications, and now edge computing, applications are increasingly becoming more distributed. The challenge is that each application is called over the network, which adds latency that cannot be efficiently analyzed by existing APM and observability platforms.
The rate at which applications become more distributed will only accelerate. As organizations deploy near real-time applications, more data is being processed and analyzed at the edge of the network. Rather than transmitting raw data to the cloud, these applications process and analyze the data as it is created and used. Only then does the application stream or pass the aggregated results to a cloud service or local IT environment for further analysis.
However, most DevOps teams lack an understanding of how Internet services impact highly distributed applications, beyond the cloud services or on-premises IT environments where they have deployed applications in the past.
Internet blind spots
In general, there are three main categories of blind spots that affect the performance of distributed applications. The first and arguably least transparent are the services provided by third-party vendors. From content delivery networks (CDNs) to software-as-a-service (SaaS) applications, every service is controlled by an external service provider, which often does not allow DevOps teams to collect telemetry data by deploying agent software within the application. their IT environment. At best, they might expose an application programming interface (API) to enable an agentless approach to collecting data, but this approach often doesn’t provide the level of control needed to optimize application performance.
The second major blind spot is at the device level. For example, a configuration error in the browser can have a significant impact on load times, adversely affecting application performance.
Finally, various platforms and protocols, from domain name servers (DNS) to publish and subscribe services, can affect applications in ways that APM or observability platforms cannot detect.
The only way to provide the required level of visibility is to leverage an IPM platform, which collects telemetry data from a global network of thousands of points of presence (PoPs) to accurately determine what level of Internet service is provided to any user. given end point.
Background and controls
Integrating telemetry data collected through IPM provides DevOps teams with context to better troubleshoot distributed applications. Rather than wondering if a certain piece of code is to blame, DevOps teams can instantly determine whether internet traffic flowing through a specific location is causing additional latency or blocking access entirely.
Armed with these insights, the team can contact the Internet service provider at the time to resolve the issue, or reroute through other services if necessary to ensure application availability.
Regardless of approach, the days of DevOps teams finding themselves subject to the vagaries of network services over which they had little influence are coming to an end.
DevOps meets Netops
The integration of IPM and APM or observability platforms creates a foundation upon which best practices for managing network operations (NetOps) and DevOps can ultimately be converged. Instead of convening a “war room” to identify the root cause of an issue, both teams can immediately understand the extent to which network services may be adversely impacted. Now, all the time spent guessing the cause of the problem can be used to fix the problem.
In an era when applications are more dependent on network services than ever before, the need to integrate NetOps and DevOps workflow management has never been more important.
in conclusion
Most DevOps teams are well aware that there are often significant differences between what DevOps teams relying on APM and observability platforms believe and what is actually happening in distributed computing environments. The challenge is that they often lack the visibility needed to determine the best course of action to solve the problem. As IPM becomes more integrated with APM and observability platforms, network blind spots that previously uncovered root causes of problems will quickly be eliminated.
Of course, every DevOps team needs to determine to what extent gaining these insights is a priority. However, considering the number of issues DevOps teams are trying to solve that can be traced back to Internet services, it’s clear that by simply providing more network visibility to these services, the overall level of stress and hardship DevOps teams often experience can be greatly reduced.