Performance issues regularly confound DevOps teams after an application is deployed, despite the number of tests run before deployment. Upon further investigation, the issue that is most frequently overlooked is the distributed nature of the application itself. End users accessing applications from multiple locations are never going to have the same level of internet service, so software that may be running perfectly well in locations that are major urban technology hubs, such as New York, San Francisco or London, is not necessarily going to provide the same experience in farther-flung regions, especially rural areas that are halfway around the world.
All internet services are not created equal. Intermittent network latency issues can have a profound impact on application performance simply because of the laws of physics. The farther away an end user is from the data center where the application is hosted, the more likely it becomes network latency will adversely affect application performance.
Unfortunately, most DevOps teams lack any visibility beyond the data center environment where the application is running. Naturally, the first step toward gaining that level of insight starts at the edge of the network.
Internet Stack Visibility
There is a wide range of services that make up an internet stack, each of which can adversely impact the performance of distributed applications. Everything from virtual private networks (VPNs) and content delivery networks (CDNs) to domain name system (DNS) servers and switches adds latency that, depending on how network traffic is being routed, can have a major impact on application performance. Any one of these services might be experiencing an outage or, more challenging to detect, intermittent degradations that unpredictably impact application performance. Whether it’s a software-as-a-service (SaaS) application being accessed in the cloud or an internet-of-things (IoT) platform running at the network edge, pinpointing which internet service might be the root cause of an issue requires the ability to closely monitor and observe that traffic.
Without any visibility into the internet stack, surfacing the insights needed in a way that provides the context required to optimize and troubleshoot a specific application becomes an impossible challenge. All the time and effort spent building an application can come to naught simply because no one understood the impact network latency would have on the application before it was deployed. Even after an application is deployed, any change to the way network traffic is being routed can have major consequences. Without any means of understanding what changes may have occurred, it might be weeks or months before an organization realizes it may need to log a service request or switch service providers.
Any truly comprehensive approach to observability clearly needs to include an analysis of the internet services upon which organizations crucially depend to ensure a consistent application experience is delivered and maintained. Depending on how the IT team is structured, those insights can be fed into an observability platform that the organization has adopted or correlated using an internet performance monitoring (IPM) platform.
DevOps Needs NetOps
Regardless of the approach, it’s never been more crucial for network operations (NetOps) and DevOps teams to be able to align their approaches to monitoring distributed computing environments. More latency-sensitive applications are being deployed than ever. In an ideal world, DevOps teams working closely with NetOps should be able to programmatically provision and alter networking services as needed. Not every internet service can be adjusted via an application programming interface (API), but most NetOps teams have access to consoles that enable them to upgrade to different service levels when needed. At the very least, a service provider will work with them to make any changes required.
Of course, it becomes more challenging to negotiate if the NetOps team doesn’t know which element of the Internet stack needs to be upgraded. A service provider that typically doesn’t have any visibility into the application might spend weeks trying to determine which element of the Internet stack they manage is at fault. IT teams that have their own means of monitoring a set of internet services are going to be able to work with their service providers to resolve those issues much faster.
Summary
Savvy IT teams are all too aware of how prone internet services are to outages and brownouts, so as a rule, they tend to make sure network traffic can be rerouted from one service to another. That approach also provides the added benefit of maintaining some pricing leverage as they negotiate fees for the services provided.
It’s also worth remembering providers of networking services that know a customer is locked in may not have as much incentive to make sure networking services are running at peak efficiency. The only way an IT team is ever going to know what level of service is being delivered at any given time is, of course, to generate an IPM report that precisely details what services were actually available at what level of performance. Otherwise, they are wholly dependent on the report a service provider presents alongside their monthly bill.
Just as critically, the reports generated by an IPM platform also surface insights that, when shown to application developers, create a potential opportunity to optimize their code. Without that level of analysis, every developer will assume the network services are either broken or poorly managed. The challenge and the opportunity now is to provide internet performance intelligence in a way that every stakeholder cannot just act on but, just as critically, implicitly trust.