Going Cloud-First to Accelerate WAN Transformation

For network architects and engineers, the WAN experience is typically seen through the eyes of telco carrier relationships. In many cases, this experience isn’t necessarily a positive one. The process of working with a telco carrier to design an enterprise WAN requires negotiating contracts and rates, provisioning and installing new circuits, addressing performance issues and outages, and managing service-level agreements (SLAs) on an ongoing basis. This can all be challenging to say the least. When you include the complex peering relationships that carriers must maintain to deliver global connectivity and the fact that the term “agile” doesn’t immediately come to mind when describing the telco industry, you may conclude that the overall experience is not a good one.

Cloud-first WAN architecture
Unlike the telco carrier relationship defined above, a cloud-first WAN experience changes this paradigm. And we’re not just talking about public clouds. It’s an overall experience that is predicated on business agility, operational simplicity and consistent multi-cloud deployments. It does all of this while leveraging the cloud consumption model.

Think about it like this: computing has evolved from a model in which the enterprise owned, operated, and maintained its applications and infrastructure in an on-premises data center to a cloud consumption model. Similarly, the cloud-first WAN experience evolves the legacy networking model to a network consumption model in which the enterprise and the network provider share responsibility for the WAN applications and infrastructure.

Fig 1: Taking a platform approach with a cloud-first WAN

What’s more, the consumption model simplifies service delivery, transforming it from a manual process that requires a lot of training to an automated process that many call “intent-driven.”

A cloud-first WAN experience should deliver predictable end-to-end performance consumed “as-a-service,” which should result in a superior user and application experience.

Cloud-first WANs should improve business agility. In an era where time-to-market is measured in minutes, hours and days, organizations need a WAN that uses a cloud consumption model, specifically an OPEX-based offering that features flexible billing and ease of service integration. It is this new network consumption model that drives agility, which permits IT and infrastructure teams to quickly adapt to the needs of the business. This includes quickly changing business priorities, integrated supply chains and globalization demands. Cloud-first WANs should offer operational simplicity that features a best-of-breed managed service enabling enterprises to greatly simplify complexity. The cloud-first WAN presents a take on the WAN consumption model by delivering the technology (SD-WAN) and the managed service. Really, it’s like having the best of both worlds.

Cloud-first WANs should offer a multi-cloud-ready architecture, which offers choices to bring any application to any cloud by connecting public cloud providers, software-as-a-service (SaaS) providers, and partner clouds—and doing all this while delivering a consistent user experience. It is this capability that is the linchpin of a cloud-first service offering. It is an offering that has the extensibility to connect to any infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS) or SaaS provider in any region with little effort. Using this approach, IT should have the flexibility to deploy any application, anywhere, accessible by any employee in any location and at any time.

In short, your WAN should provide the same user experience as those connected to the LAN.

Advantages over DIY SD-WAN
In a post-multiprotocol label switching (MPLS) world, IT planners can ordinarily choose between building or consuming their WAN.

Enterprises that want to do everything themselves typically source technology from a box vendor and then tack on security, cloud, optimization and orchestration components.

This do-it-yourself approach isn’t as simple as it sounds, especially in an era where we’re seeing big gaps in expertise. As a result, enterprises often reach the end of the road due to cost, complexity or timing. In fact, up to 20 percent of DIY deployments end in failure or underperformance.

A few challenges that are associated with the do-it-yourself approach to SD-WAN include:

Forklift upgrades
Do-it-yourself SD-WAN rollouts usually involve hardware changes, inventory management, version control, patching issues and more. Even when SD-WAN is being done as a software upgrade, the performance of legacy hardware deteriorates when additional SD-WAN features are thrown in the mix, which can lead to technical debt, stranded assets and the need to acquire upgraded hardware.

Security
Implementing consistent security across the edge and cloud (for example, providing the ability to encrypt all traffic) can be difficult because of all the moving parts.

SLAs
SLAs are only as good as they are defined, understood and enforced. Most vendors cannot guarantee an end-to-end SLA because they don’t own enough components in the service delivery value chain. Because of this, traditional SD-WAN box vendors cannot guarantee network SLAs. It can get even more complicated for global deployments or when last-mile circuits are involved. Most vendors offer convoluted SLAs and, because they don’t control them end-to-end, are really unable to offer service uptime. As a result, they offer backend credits with complex calculations, which don’t adequately reflect the business impact of a failed SLA.

Cloud agility
Digital enterprises require an agile environment. Bringing in new cloud applications, kicking out or migrating from legacy applications, and opening and closing branch and satellite offices require changes to the WAN.

Time-to-deployment

Equipment lead times, configuration, testing and contract modifications with multiple last- and middle-mile service providers can significantly delay a rollout.

Slow application performance
The lack of direct on-ramps to cloud service providers can significantly reduce cloud application performance. Fluctuating latency and data loss can affect real-time, low latency applications such as UCaaS. A lack of built-in WAN optimization or application acceleration technology can also degrade the user experience.

Overlay issues
There are always issues when a functioning configuration of the underlay (MPLS) before SD-WAN has to be reconfigured to accommodate the overlay created by some SD-WANs. This results in broken QoS, routing, and other related issues.

What’s more, there is diminished end-to-end control of SLAs across a do-it-yourself global backbone because of the separate visibility of the overlay and underlay. Because of this, it’s more difficult to correlate faults and provide minimal to no correlation between the overlay and underlay.

Complex operations and multiple proofs of concept (POCs)
Building a WAN requires contracts with multiple original equipment manufacturers (OEMs) and service providers. This can result in increased complexity. Problem resolution usually involves multiple POCs and separate contact lists for first- and middle-mile connectivity. This approach does not align with the cloud consumption model that CIOs prefer for their applications.

Advantages over a service provider
Aside from the do-it-yourself approach to WANs, some people choose to consume the WAN from a service provider. The provider then sources the technology from a box vendor. Unfortunately, this doesn’t bring about a truly seamless experience because of all the moving parts between the service provider and the technology vendor. Problems can arise between the provider’s underlay network and the SD-WAN technology vendor’s overlay. The challenges with taking the service provider approach include:

Last mile lock-in
Carriers like to lock customers into their last-mile solution rather than let them select the best option on the market. Last-mile service has the potential to create a poor overall user experience and defeats the agility of an SD-WAN approach.

Slow rollout
Delays can occur with equipment lead times, configuration, testing, and modifications in contracts with OEMs.

Poor cloud colocation
Carriers are not always colocated with cloud service providers, such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud. This makes it challenging to ensure cloud application performance and optimized regional connectivity.

Not agile
As we mentioned earlier, digital enterprises operate in an environment that requires agility. Events that require changes to the WAN include bringing out new cloud applications and taking down or migrating from legacy applications and opening and closing branch and remote locations. Legacy WANs are not able to keep pace with rapid changes.

Security
The provider may not be working with the security vendor preferred by the enterprise. The provider may also not have firsthand experience and deep support with a given security vendor.

Inconsistent SLAs

Carriers operate within specific service areas, like a single country or region. For international connectivity, peering arrangements with multiple service providers are made, which makes it hard to guarantee end-to-end SLAs. Because of this, the service provided will only be as good as the least common denominator among the patchwork of providers.

Inflexible pricing
Carrier networks often involve agreements among multiple service providers. This leads to a pricing model that is designed to compensate everyone in the value chain, which makes them inflexible and expensive.

Low Net Promoter Score (NPS)
Surveys generally rate carriers poorly in NPS surveys. Their low scores are due to numerous challenges: being consumers rather than creators of technology; dependence on various OEMs; the need for complex inter-carrier agreements; the mandate to protect legacy investments in MPLS; and the tendency to lock customers into first- and last-mile offerings, among others.

Creators versus consumers
SD-WAN is not a single-box plug-and-play solution. Comprehensive SD-WAN solutions require interworking among various elements. Because they’re consumers rather than creators of the technology, carriers are limited in their ability to offer best-in-class service.

Fig. 2: Comparing DIY SD-WAN, MSPs/Telcos, and Cloud-First WAN Approaches

Evaluating a platform approach
To review, traditional SD-WAN vendors take a box-centric view that has little accountability for an end-to-end global experience, while traditional service providers merely cobble together technology offerings from multiple vendors and, as a result, end up compromising on their ability to deliver a seamless experience.

The most logical path forward is to evaluate a platform approach that is able to leverage a unified service architecture that is extensible and reaches end-to-end. The platform needs to offer the service sophistication that enables the suite of connectivity, cloud, security and optimization services. Specifically, these are services that are deployed in a SaaS model to all customers and that can be readily enhanced.

Whether deployed regionally or globally, taking a platform approach should also leverage an orchestration engine that offers visibility and control into the end-to-end deployment, or the first, middle, and last miles. You can have the best hardware in the world, and it will still be ineffective if the SD-WAN offering results in a piecemeal operational model.

In summary, end-to-end accountability eliminates issues both associated with DIY as well as working with carriers who do not control their own, end-to-end WAN technologies.

This article was originally published on pipelinepub.com