The Network s Cloud-like Future: SD- WAN to Networks as a Service SD-WAN will prepare the enterprise to consume networks as a service

Transcription

1 Winter 18 The Network s Cloud-like Future: SD- WAN to Networks as a Service SD-WAN will prepare the enterprise to consume networks as a service By abstracting away many of the details of resource provisioning, SD-WAN puts WAN planning into a service-delivery frame of reference. SD-WAN forces the enterprise to think less about speeds and feeds and more about the balancing of application portfolio demands overall via application-based policies and performance SLAs. SD-WAN can t hide the details of dealing with last-mile connectivity providers, though, making managed SD-WAN a valuable option, and a springboard to a full-on Network as a Service model. Compass Direction Points! SD-WAN reduces troubleshooting burden. Early adopters saw a 95% reduction in site outages, 92% reduction in troubleshooting time.! Most Enterprises Keeping MPLS in SD-WAN. In fact, more than half won t even change their MPLS beyond wrapping SD- WAN around it.! SD-WAN increases last-mile provider pools. Enterprises are boosting bandwidth to sites sevenfold, in part by bringing in additional broadband or 4G providers. By John Burke Principal Research Analyst & CIO Nemertes Research Nemertes Research Group Inc

2 Table of Contents COMPASS DIRECTION POINTS 1 TABLE OF FIGURES 2 EXECUTIVE SUMMARY 3 THE ISSUE: NETWORKS NOT ACTING LIKE CLOUD SERVICES YET 5 OBSTACLES TO NAAS: LEGACY WAN MANAGEMENT FOCUSES ON COMPONENTS AND CONNECTIONS 6 MEANINGFUL SLAS 6 EVERY ROUTER A ROSE NURTURED AS A UNIQUE INDIVIDUAL 6 EVERY CONNECTION UNIQUE 7 SD-WAN SAYS: MANAGE WAN SERVICES TO MEET APPLICATION NEEDS 7 POOLING CONNECTIVITY, BALANCING CONSTANTLY 8 PLOUGHING UNDER ROSES, PLANTING CORN: MANAGING THE WHOLE WAN 9 CENTRALIZED POLICY FOCUSES ON APPLICATION NEEDS, BUSINESS VALUE 9 FROM SD-WAN TO NETWORK AS A SERVICE 10 THE EXPLODING PROVIDER POOL EXPLODES RELATIONSHIP MANAGEMENT 10 ELASTIC WAN 11 NAAS PROVIDERS COMPLETE THE TRANSFORMATION 11 CONCLUSION AND RECOMMENDATIONS 12 Table of Figures FIGURE 1: SD-WAN STATE OF ADOPTION... 8 FIGURE 2: ENTERPRISES MOSTLY KEEPING MPLS AS PART OF SD-WAN Nemertes Research 2018! ! DN6671 2

3 Executive Summary IT and the enterprise need the network to be delivered like a service and managed accordingly to create a Network as a Service (NaaS) model. This means having some kind of clear Service Level Agreement (SLA) to define what services will be delivered and how delivery will be measured. Yet, many organizations have no useful SLA on the network, especially the wide-area network, nor the ability to define and manage to one. The biggest obstacle to meaningful SLAs and to a NaaS model broadly is the way most legacy WAN management focuses on the wrong things. Where they exist, network SLAs are usually about device uptime and link performance. It s no surprise they focus on the low-level details in this way: network engineers tend to work manually, site by site and component by component, rather than holistically. SD-WAN addresses these shortcomings. In addition to sharply reducing the number of outages in WAN sites, and reducing the cost of expanded capacity, they provide highly automated, centralized management for both links and devices, and simplify creation and tracking of real, business-meaningful SLAs. That s a huge step towards delivering NaaS, but it is only part of the picture: XaaS implies getting capacity on demand, and abstraction of supplier relationship details. SD-WAN doesn t solve these problems. In fact, SD-WAN can increase the burden of relationship management! With SD-WAN, IT has means and incentive to use more and more lastmile providers, forcing the organization to monitor and manage that many more contracts and bills, and to develop and maintain a working support relationship with each. And, to manage elasticity on its own, the enterprise must negotiate shortterm/open-ended contracts, get the links provisioned quickly, and integrate links into the WAN transparently. SD-WAN technology only helps with that last part. For NaaS to be a reality, then, someone else has to handle the details of those provider-facing relationships, both ongoing and transient, with SD-WAN as one part of the delivery infrastructure. IT leaders, WAN architects and engineers should: Evaluate SD-WAN technologies immediately, looking for: o cost savings vs continuing on as they are o how much downtime they might avoid using it o how much IT staff time could be freed up by using it o how much more quickly they could add new services to the network Calculate the cost of managing a WAN vendor relationship Consider the desired state for the WAN in terms of path- and providerdiversity and site resilience, how many vendors will be required to achieve it, and the associated costs Evaluate using managed SD-WAN as a stepping stone to NaaS in the future Nemertes Research 2018! ! DN3661 3

4 Begin planning for a truly dynamic NaaS-based future as service provider offerings mature, and 5G rolls out. Nemertes Research 2018! ! DN6671 4

5 The Issue: Networks Not Acting Like Cloud Services Yet IT and the enterprise need the network to be delivered like a service and managed accordingly. This means having some kind of clear service level agreement to define what IT will deliver and how delivery will be measured. Yet, many if not most organizations have no useful SLA on the network, especially the wide-area network, nor the ability to define and manage to one. Enterprises are shifting broadly to a service-consumption model in IT, both for external purposes, as evidenced by the steady rise in cloud services usage, and for internal purposes, with the business lines as customers to IT as a service provider. The service-provider model for IT focuses on IT making and meeting SLAs with the business, usually around specific applications (e.g. the CRM) or user-visible services (e.g. telephony). Business-line-facing application SLAs basically assume the WAN is going to be available 100% of the time and performing optimally, often without consideration of actual outage and performance data. These SLAs must invisibly absorb any network outages in their allowable downtime, and network-driven performance problems will be lumped in with those from any other causes, again invisibly. (And of course, any network manager will tell you everybody blames the network first, and that they always have to prove the problem isn t the network. Yes, it s an exaggeration, but not a huge one!) A key aspect of SLAs is that they are meant to hide from the customer the details of how the provider is delivering the service. Consider Software as a Service (SaaS): the SaaS provider promises an application will be available 99.9% of the time, but doesn t lay before the customer the detailed uptime SLAs on the servers, storage, power and cooling, data center network, and the WAN that might go into meeting that target. As IT continues to shift to a service-provider model, it needs the network to fit into the picture the way software and infrastructure now do, thanks to SaaS and IaaS. To get to an analogous Network as a Service (NaaS) model, IT will need to be able to make meaningful SLAs against its own network services, and to get user-relevant SLAs from its external network service providers. To truly fit the aas model, it will also need the SLAs to abstract away all infrastructure and operational details behind them, and to provide for on-demand, elastic resource consumption. Being able to work with networks under a true NaaS model will let the enterprise consume network services the same way it does other services, making it more flexible and agile in pursuit of its goals. Nemertes Research 2018! ! DN3661 5

6 Obstacles to NaaS: Legacy WAN Management Focuses on Components and Connections The biggest obstacle to a NaaS model in most organizations is the way legacy WAN management focuses on the wrong things. SLAs, to be business useful, need to focus on business-relevant things for IT, user-facing applications and user-visible services. Network SLAs, where they exist at all, usually don t. To get to the point where it can define and deliver on meaningful network SLAs (and get closer to delivering NaaS), IT will need to manage WANs in a new, automated way. Network staff still manage WAN infrastructure manually, to a shocking degree. Manual operations slow IT s responses, hindering agility; increase overhead; and create a higher risk of a misconfiguration or a piece out-of-date software causing performance and security problems. Meaningful SLAs Like most of the rest of IT management up until fairly recently, network management has been focused on the components of the infrastructure rather than with services being delivered. Network SLAs don t say we will deliver this set of applications with 99.99% availability and good enough performance to make the application usable. Where they exist they tend to be about device uptime and link performance: The router will be available % of the time or the link will be passing packets with average latency X and % uptime. Consequently, it s hard to make a high-level SLA between IT and the rest of the company, since major aspects of service delivery are not themselves governed by SLAs. Every Router a Rose Nurtured as a Unique Individual It s no surprise that network engineers tend to manage manually and think component by component given that they have to manage an infrastructure composed of unique individuals. Every router has a unique configuration (even though they often share some core golden config ). Because each is unique, automated software pushes are minimal in many organizations; after all, such pushes are only really useful when exceptions are few. On many legacy WANs, most routers are an exception on some level. Once the percentage of exceptions climbs too high, attempting automated pushes may only add to the management burden rather than reducing it. Consequently, IT rarely upgrades routers, or patches them, for fear of breaking things. Routers may be years behind the current release of their code base, and so be cut off from new features and from up-to-date security. Nemertes Research 2018! ! DN6671 6

7 Every Connection Unique As with the routers, so too with the links connecting routers to the world: IT manages each to some extent as a unique individual, and handles modifications to link usage manually. This contributes to outages and performance problems as well. Most enterprise branches really have two links, of course, but only one active at any given time. The secondary link comes into service when the first one fails. Unfortunately, that failover is not fast. It can take several seconds to more than a minute even when automated. Of course, many organizations still require manual intervention to allow the failover to happen, a policy usually resulting from bitter experience with immature or poorly configured auto-failover in the past having resulted in traffic getting moved from link to link even when the primary was doing well; or never moving at all, even when the primary was useless. Slow failover among links interrupts application network sessions under way at the time, generally killing any real-time communications like VoIP or video calling or conferencing, or VDI sessions, and potentially knocking any other sessions out as well. In fact, slow failover knocks things down twice! Once when the primary link fails and connectivity slides onto the secondary link, and a second time when the primary takes back over and traffic has to move back to it. Fail-back is even less likely to be automated than initial failover, since IT often wants to do it after business hours if possible. (Better for customer service, but tough on IT.) Where multiple links are active (though usually only two, still), traffic is nearly always split among them according to a small and unchanging set of rules. The failure of a link will still result in failover for the traffic, but it can still be so slow as to kill anything working across it at that moment. SD-WAN Says: Manage WAN Services to Meet Application Needs SD-WAN technologies were created to address the shortcomings of traditional WANs by bringing the principles of software defined networking to bear. SD-WAN separates control of WAN behavior from the devices moving the packets, providing a means of highly automated, centralized management for both links and devices. Automation at multiple levels helps eliminate link-related down time, makes it easy to keep software up to date and properly configured, and simplifies creation and tracking of real, business-meaningful SLAs. Nemertes Research 2018! ! DN3661 7

8 Already more than 21% of enterprises are deploying SD-WAN in at least some locations, both to get more network capacity at lower cost and to improve network resilience. Early adopters report a 95% reduction in the number of service outages at their SD-WAN sites. Figure 1: SD-WAN State of Adoption Pooling Connectivity, Balancing Constantly SD-WAN virtualizes a site s connectivity, in two directions. It makes all links (using any medium) active, and virtualizes from the bottom up by combining all that bandwidth into a single pool of capacity to be allocated (by policy) to the applications using the WAN. An SD-WAN platform also virtualizes from the top downward, by superimposing a dynamic array of virtual WANs across that virtualized pool of connectivity. It distributes and dynamically balances traffic across all available links according to application-centric policies. Adjustments are fast subsecond, and usually fast enough to not interrupt services. Because the SD-WAN controls traffic flows in real-time based on actual link health, applications get the performance they need more often and with less chance of interruption or performance degradation. When a link is failing, or even just temporarily performing poorly, the SD-WAN alerts administrators if monitoring thresholds are passed, and adjusts usage by routing traffic partly or fully around the problem until it abates or is resolved. Nemertes Research 2018! ! DN6671 8

9 Moreover, virtualizing WANs allows different virtual WANs to have different topologies. That is, by policy, some applications will be able to speak directly, location to location, using a virtual WAN that is a full mesh, while others might be required to route traffic through central locations like data centers (say for compliance-related archiving) or through cloud utilities (say, through a cloud-based firewall), hub-and-spoke style. All these virtual WANs and topologies are overlaid on the same pool of connectivity. Ploughing Under Roses, Planting Corn: Managing the Whole WAN SD-WAN separates control of the network from actual packet handling. This layer of abstraction, coupled with the focus on virtual WANs defined by policy centrally, gets network managers out of the dead-end of managing links and ports and uniquely configured devices and sites. Instead, they focus on managing the policies defined to provide the performance they need to deliver, and on adding new services to the mix. That is, they leave the management of any site- and link-specific variations to the SD-WAN solution, which uses automation to control everything. This kind of automation dramatically lowers the likelihood of manual error leading to misconfigurations, which are the main cause of performance and security problems on WANs. It also finally makes real the promise of fully automated software pushes on the WAN, in turn making it easier to keep up to date on both security patching and platform upgrades. Early adopters receive 92% fewer WAN trouble tickets for SD-WAN sites. Centralized Policy Focuses on Application Needs, Business Value Holistic WAN management by centralized policy elevates IT s focus from network components and links to IT s delivery of applications and services. SD-WAN solutions build policies around services and applications and their specific needs around reliability, performance, and security. These tools therefore offer a direct means of closing the gap between IT s delivery of WAN services and its ability to set a meaningful WAN performance SLA for a service or an application. They also provide the means to monitor and report on performance against that SLA. Given such a tool, IT has a clear and simple path to mapping WAN performance and availability SLAs to business relevance and importance. Policies for mission critical applications can push the highest level of continuity through load-balancing traffic across multiple links. Policies for performance-sensitive applications that matter to the business (e.g. IP telephony) can push prioritization, and the use of methods like multipathing (replicating traffic on multiple links and using whichever copy of a packet arrives first) to guarantee performance. Nemertes Research 2018! ! DN3661 9

10 From SD-WAN to Network as a Service By shifting the focus of network management from components to services and empowering IT to make meaningful SLAs for the WAN, SD-WAN pushes IT a huge step towards delivering NaaS, from the perspective of business users. But it is only part of the picture, as it doesn t address either provider relationship management or elastic consumption directly. The Exploding Provider Pool Explodes Relationship Management SD-WAN makes it easy to stop thinking about the WAN gear in any given site, or about the health or performance or capacity of any individual link. But, it does not eliminate the need to establish relationships with connectivity providers and can increase the burden of that activity. In fact, because SD-WAN lets any given site use whatever mix of media and providers as will best serve that site s needs, it can dramatically increase the provider pool. When any given site might have its traditional MPLS connection, plus metro Ethernet and/or broadband Internet and/or LTE and/or satellite connectivity, that site might have several providers involved in delivering services. The same set of providers may cover some other sites, but likely won t cover all; the more sites an enterprise has, across different geographies, the larger the number of providers likely to join the party. Even a midsized company may have 40 or 50 lastmile connectivity providers if the company is far-flung geographically. Figure 2: Enterprises Mostly Keeping MPLS As Part of SD-WAN Managing multiple providers is more than just taking a connection from them. Each relationship involves ongoing management at the business level and at the technical Nemertes Research 2018! ! DN

11 and operational levels. At the business level, the enterprise has to monitor and manage billing for all sites, including identification and resolution of any associated disputed charges, as well as make sure SLA failures are properly recompensed, and contracts are reviewed and renegotiated or terminated as they expire. At the operational level, IT has to develop and maintain a working relationship with the support organizations and processes for each provider. Knowing how to work with each is important to having the ability to quickly resolve technical problems with services when they arise. It s important to note, some of the providers may not have typical enterprise-level support a large organization might be used to. For example, if one of the connections in a site comes via consumer broadband, there may not be a 24/7 help desk at all, or an SLA on resolution of problems. Elastic WAN A key conceptual difference between aas offerings and traditional hosted or managed services is the idea of capacity on demand: that the enterprise can get more when it needs it, for as long as it needs it. There have been tentative steps in this direction on the WAN in the past, with burstable consumption of capacity on over-provisioned media. A truly elastic WAN would take this one step further, with the ability to bring in new capacity on demand (although not necessarily instantly) not just by expanding use on a link but by adding links and even providers to a site for as long as they are needed. New satellite networks, expanding LTE, and emerging 5G offerings and technologies may make this substantially easier in the future. For an enterprise to manage elasticity on its own is a tall order. It would involve negotiating short-term/open-ended contracts, getting the providers to provision links quickly, and integrating them into the environment transparently. SD-WAN technology really only helps with that last point; the rest is on IT. NaaS Providers Complete the Transformation For NaaS to be a reality, someone has to handle the details of those provider-facing relationships, both ongoing and transient. From the business user s perspective, IT can look like a NaaS provider IT handles all that detail. But for IT to be a consumer of NaaS instead of a provider, it needs an external entity (or entities) to take over that whole last layer of both business and technical operational detail, and to manage elasticity. NaaS providers will manage differently than traditional managed WAN providers, in that they will be aiming for elastic scaling and on-demand services, and focused on SLAs for applications and services, not links or devices. They will almost certainly build their offerings around a managed SD-WAN implementation, since SD-WAN Nemertes Research 2018! ! DN

12 provides the ideal platform for delivering NaaS. They will simply extend the virtualization and abstraction upwards further, allowing IT to focus on service delivery rather than operational details, and outwards as well, making the pool of providers involved in delivering those services dynamic and elastic without increasing the burden on IT. Conclusion and Recommendations SD-WAN provides the essential technological stepping stone to lift IT out of traditional WAN management and into an SLA-driven world focused on meeting the needs of the business. It is a crucial tool, and IT can use SD-WAN to function as a NaaS provider to the rest of the business. However, it does not help IT consume networks as a service. For that, the enterprise needs an external NaaS provider. IT leaders, WAN architects and engineers should: Evaluate SD-WAN technologies immediately, looking for o cost savings vs continuing on as they are o how much downtime they might avoid using it o how much IT staff time could be freed up by using it o how much more quickly they could add new services to the network, making IT more agile Calculate the cost of managing a WAN vendor, both the business relationship and the technical/operational relationship Consider the desired state for the WAN in terms of o path- and provider-diversity and site resilience o how many vendors will be required to achieve it o the associated costs Evaluate using managed SD-WAN rather than DIY, as a stepping stone to NaaS in the future Begin planning for a truly dynamic NaaS-based future as service provider offerings mature, and 5G rolls out. About Nemertes Research: Nemertes Research is a global research-advisory and consulting firm that specializes in analyzing and quantifying the business value of emerging technologies. You can learn more about Nemertes Research at our Website, or contact us directly at research@nemertes.com. Nemertes Research 2018! ! DN