SD-WAN and SLAs: Why crafting internal SLAs is a smart move
IT teams can use SD-WAN to keep track of network performance, upping the possibility to create and enforce internal SLAs that better reflect business requirements.
A service-level agreement, or SLA, is a commercial agreement, typically between a service provider and customer, based on specified operating parameters. While IT teams purchasing WAN connectivity services should factor in fix times, latency and uptime SLA figures, the basis of any buying decision should focus on real-world traffic performance.
An internal SLA, on the other hand, is an agreement between enterprise departments that offers a set of parameters more specific to an individual business, such as application flow and user requirements. These don't describe potential repercussions for inadequate service, but they provide the business-level service requirements necessary to avoid negative effects, like revenue loss.
WAN services now include software-defined WAN technology, so enterprises need to take into account the correlating requirements. SD-WAN is often marketed as an internet virtual private network (VPN) technology that can achieve cost savings and meet user demands for access to public cloud-based services. In reality, however, SD-WAN can terminate any connectivity type -- and, subsequently, the existing SLAs -- from internet services to Layer 3 MPLS and Layer 2 virtual private LAN services.
As enterprises adopt SD-WAN using internet connectivity, an internal SLA can help define what they require from their SD-WAN providers in standard SLAs. Let's look at how enterprises should approach setting SLAs for SD-WAN services and internal SLAs.
Traditional VPN SLAs vs. SD-WAN options
A service-level agreement surrounding an internet VPN service is often fairly high-level. Most providers offer a performance indicator as an average across any given month. When looking at those averages, it's important to understand the results can suggest a consistent performance level when they actually contain peaks of high latency at certain times. In some sectors, this could result in major application usage creating revenue loss. To complicate matters, the SLA often only covers the provider's core network and doesn't include the local loop circuit.
In addition to latency, other common SLA measurements include packet loss and network uptime, which providers also offer as averages. While average figures are often of little practical use, they give at least an idea of how the WAN is performing. But if an SLA is simply an indication of desired performance or, at best, a commercial agreement, how does an enterprise effectively create an SLA?
SD-WAN allows enterprises to craft their own internal SLAs based on required business factors, like mission-critical traffic or applications. If an enterprise needs to prioritize voice traffic, for example, SD-WAN lets an enterprise use an underlying MPLS transport that offers better quality of service across the network.
If an enterprise sends traffic over the internet, it will likely experience a loss of traffic control, compared with MPLS. As a result, enterprises should research available connectivity types and their related real-world performance data in order to choose a primary SD-WAN connectivity type. The majority of providers won't offer real-world ping tests and traceroutes, but it's certainly worth requesting the figures.
Once an enterprise selects its primary connectivity, it can configure the SD-WAN service to perform traffic and application prioritization. If bandwidth is constrained, for example, applications an enterprise classifies as important can gain access to the route .
Further, SD-WAN differentiates itself with the granular level with which it can define prioritization. An enterprise may want only a subset of users to get special treatment during times of network congestion or packet loss, for example, or it may wish for only certain types of traffic and users to gain access.
Use reporting capabilities to define internal SLAs for SD-WAN
With in-depth reporting, an enterprise can create its own internal SLA based on a configuration, rather than a commercial agreement. By using reporting statistics to visualize how the network is being used and by creating a user profile based on more than just an IP address, IT teams can really start to nail network performance.
SD-WAN allows enterprises to craft their own internal SLAs based on required business factors, like mission-critical traffic or applications.
As an enterprise starts to better control its WAN performance through SD-WAN, it can begin to define SLA factors back into the business. This is fundamentally different from generic WAN SLAs, which take time to generate insight about network performance.
Instead of using latency and jitter figures, IT teams can determine which SLA factors best reflect how to meet business demands. They can create internal SLAs based on factors like connectivity origin, type and conditions. SD-WAN also presents the unique opportunity for IT teams to create per application, per department or even per user SLAs. Because SD-WAN can replace various types of connectivity, the internal SLA grows even more powerful, as it has the default capability to span multiple technologies and disaster recovery situations.
In the absence of meaningful data, the original service-provider SLA is the only way to gain basic insight into network performance. Again, it's possible to request real traffic performance figures from potential providers, but whether their sales teams will disclose the information depends on their internal policies.
WAN SLAs aren't going away -- just shifting
It is difficult to define an SLA within a presales environment. This is especially true for global enterprises that work with multiple internet service providers or network-to-network interfaces. While trends like the public cloud help make workflows more efficient, the challenge of delivering predictable traffic performance is also magnified.
This means enterprises need to work with what they have and also focus on asking questions to gain insights into typical network SLA factors. They should then consider how their SD-WAN vendors are positioned to help define their own internal SLAs.
Is the SLA going away? The most basic SLA is barely useful when making SD-WAN buying decisions. But if an enterprise understands its business and network requirements -- and the effect of poor network performance -- it's better able to define its own internal SLA and ask service providers more defined questions to make sure the service meets its needs.
Applying a little pressure by asking the right questions, as well as great network management and reporting, can help your IT team achieve the internal SLA vision with SD-WAN.
