The Future of NAAS (Networking as a Service)

Author
Peter Welcher
Architect, Operations Technical Advisor

Sometimes, things just come together. This happened to me recently while finalizing my prior blog, NAAS Taxonomy (NAAS = Network As A Service).

The focus of the prior NAAS blog was that many vendors are jumping into the Network as a Service space. While that was on my mind, some work NetCraftsmen/BlueAlly was doing with a vendor, revisiting my Graphiant blogs (see Links below), and some other things got me thinking about the future of NAAS. Oh, and ONUG had a theme about automating multi-cloud (Spring 2023).

To get your attention, the role of SD-WAN may be shifting. Or NOT, of course.

What Are NAAS Vendors Up To?

NAAS vendors are innovating rapidly, expanding into adjacent offerings and markets. This is arguably like AWS’ massive rapid innovation with virtual networking, server, and security offerings. And the similar growth in offerings at its competition, of course. Agile competition. But some are more ready to compete than others. Either they can move faster or have advantages of scale.

Each WAN / NAAS vendor category has adjacencies: things it can easily connect you to (like its other sites) gaps, things it doesn’t want to or has difficulty connecting.

As an example of a gap, how easy is it for AWS to automate connections to Azure, GCP, etc.? People do this via third-party links and virtual routers in each CSP. Ok, I just saw that GCP is now doing that as well.

Most of the big players seem to have strong global high-bandwidth links and will likely try to leverage that. E.g. CSP to CDN, CSP to CoLo (and vice versa).

Gaps I think I see (everybody’s got gaps):

  • Cloud Providers: connecting to competition, not really in the last mile connectivity business – that’s your problem
  • CoLo Providers: ditto
  • CDN Providers: ditto
  • Last mile/circuit providers: may have local scale and know the access market, fiber providers, etc., but generally slow about ordering and provisioning, web presence and back-end automation of customer provisioning may be weak. L1-L2 centric approaches also a possible hindrance. I suspect they’re a good bit thinner on staffing resources, so will be slower to add new functionality.
  • MPLS and carriers: generally, really, really slow (months or significant parts of a year, not days or hours), costly, more complex hand-off of routing?

Why think about this? Identifying where the challenges and gaps are suggests where vendors will need to put energy to compete going forward. And how likely they are to do so.

What Does the Customer Want?

Well, “want” may be a bit strong. This section will look at factors in customer buying decisions.

Ultimately, customers need to connect the locations important to their business.

In addition to basic connectivity, what else might the customer be looking for?

  • SLAs and better speed, and latency: those are considerations that may encourage use of private links rather than VPN / Internet. So SLAs and actually achieving them is one area NAAS providers can compete on, especially if the extra cost is not too large.
  • Cost and speed of provisioning: factors favoring VPN / Internet. To the extent that NAAS can do fast provisioning and modest cost with SLAs, it may have a mild edge competing. For many, the Internet is good enough, at least until it demonstrates that it isn’t.
  • Speed and ease of standing up or terminating a service: We’re all too busy. Wouldn’t it be nice if “friction” (hassle) were minimized?
  • Simple self-service ordering, GUI deployment, good documentation, rapid automation (I hear that Azure is a bit challenged there), and simple but strong management / reporting / logging capability are all aspects of that. Good documentation and support are contributing factors to this as well.
  • One Stop Shopping. If you can buy, provision, and support with one vendor, that’s a distinct advantage. Hopefully faster, less work on the customer’s part, and less finger-pointing when it doesn’t work.
  • Customer Experience: Hassle-free, competent support, consistent deployment, etc. all play a role as well.

From the previous section, the connectivity gaps, the things the potential providers don’t do, those are the barriers to One Stop Shopping.

Speculative thought: is this where Equinix or AWS etc. partnering with one or more last mile providers and tying them in to online ordering and provisioning might create an edge for them? Do CDN providers have a strong play in this?

For new / lower tech / smaller companies buying WAN services, sales and tutorial / tech support may also be an important factor, for getting them on board and up to speed.

Impact of This

My crystal ball is cloudy (maybe I need a new one?) but here are some tentative predictions …

SD-WAN’s role may evolve. Leveraging SD-WAN managed segmentation and VPN for last mile access is a strong niche for it. Connecting to the cloud/CDN/SaaS is maybe something it is weaker at (harder to do, performance of cloud-based virtual routers, etc.) So, decouple the two?

That is, what may be evolving here seems like it could also lead to a two-tier WAN strategy, either from the provider side, or from the practical customer side. Here’s how that might work:

  • SD-WAN would be used to carry traffic to nearby CoLo, CSP, or CDN locations (“C Locations”). Ubiquity of the C Location provider’s presence may be a competitive factor. Performance of virtual or bare metal SD-WAN device/router at the C location might be another factor.
  • As Edge goes forward, could Edge POPs be significant as last mile connection points?
  • Last mile dedicated connections might be used instead of SD-WAN for some cases. If last mile becomes fast and easy enough, does that reduce the role of SD-WAN? (Not holding my breath. Plus with some L2 or other last mile providers, one might still want encryption for security.) Using VLANs and VRFs or other router-centric macro-segmentation seem like something done better with SD-WAN aka SASE.
  • Cloud Routers would then connect between the CoLo, CSP, and CDNs a given organization needs to connect privately to. Basically, the WAN backbone.
  • If I’m right, CoLo and CDN providers may have a better play for organizations that need to connect to more than one CSP. If more than one CDN provider is in use by the customer, then CoLo providers may have an edge.

I don’t anticipate SaaS providers participating in this but I could be wrong. I have no idea what their connectivity and local presence looks like. One would expect at least dual connections from them into nearby Internet Exchange and/or CoLo locations.

There are probably many variations on this theme, but there always are.

I’m considering revisiting this from a design point of view in a future blog. How do you best add security to this? Especially in the path from users to on-prem or cloud-based servers? What about firewalling between segments, where do you do that? E.g., sites might have VRFs or VLANs segmenting employees, guests, IOT/OT devices, PCI, and other uses. How do you plumb those across your SD-WAN with security?

Yes, But

The above somewhat ignores NAAS in the form of SD-WAN-aaS. If you have a managed SD-WAN, you may not care to much HOW the connectivity is provided. Cost, performance, uptime, etc. likely matter more.

I’m also somewhat ignoring Graphiant. Which could be described as a variant of managed SD-WAN with solid ease of automation of the transport. Or revitalized/super-charged MPLS? I happen to think they may have some solid potential cost and speed advantages. How fast and well they grow will impact uptake. Savvy experienced management team a plus!

The other thing I don’t see anyone really talking about routing (usually BGP) complexity, especially if you are trying to do VRF-like segmentation with selective forwarding of traffic between VRFs, preferably through firewalls. Or route leaking plus access lists, which I consider somewhat like using a power tool to dig yourself into a deeper pit while tying your hands behind your back simultaneously.

Your choice is segmentation on one WAN infrastructure or for clarity, maintaining separate infrastructures (e.g., business partner and/or SaaS WAN separate from “internal” WAN, etc.).

If your SD-WAN (or SD-WANs plural?) extends to 10 different business partners, 10 more SaaS providers (rather than over the Internet, to have SLAs), etc., how do you secure that?

And what’s the interplay between routing and security as WAN connectivity increases (i.e., to include SAAS and business partners…)

Conclusions

Despite my waffling in some of the above (crystal ball cloudy),  this is good news. There should be increasing choices going forward. One can hope the result will be some mix of faster easier deployment, better SLAs and service, and lower costs. Being open to restructuring and leveraging new offerings may provide significant value to companies consuming WAN / NAAS services.

Links

 

 

Let’s start a conversation! Contact us to see how NetCraftsmen experts can help with your complex challenges.

 

 

Disclosure statement