NaaS (Network as a Service) Taxonomy

For various reasons, NetCraftsmen staff and I have been applying a critical eye to various forms of Network as a Service, or NaaS. I’ve found it useful to mentally place them into different “buckets” of NaaS. This blog will describe the buckets or groupings I perceive and mention possible pros/cons as we go.

I’m a bit amused that I seem to be channeling the Network World editors/authors a bit lately. As I was drafting this, the Network World article in the Links section got posted. So, we’ll start with their categories and then I’ve got a couple to add to the list.

Another useful item, if you’re thinking about this space, is a podcast involving Khalid Raza, founder of Graphiant. He’s got some interesting thoughts about how this space is evolving.

The NaaS Marketplace

What’s playing out in the marketplace is different offerings that start providing value in different parts of the network and then expand into others. They also have differing pros and cons.

The end game here seems to be waving a wand (ok, waving a finger on a touchpad) and “instantly” ordering up connections between CoLo sites, Cloud Provider sites, company major WAN sites, SaaS providers, and B2B partners.

Most offerings aren’t there yet. They’re coming from a “home base” or comfort zone of connectivity and then expanding their coverage. This is evident in sales and documentation gaps, manual steps in provisioning done by the vendor’s support team, etc.

There are likely some barriers. For instance, how likely is it that AWS will offer connections to Azure or vice versa? The impediment is the vendors have tendencies towards “walled gardens” and NOT offering connectivity to competitors. Or not making it easy.

So at present, the offerings have various partial WAN core capabilities and provide different values of “instantly” or “velocity”. Convenience and velocity are relatively important to the customers. Clunky / kludged UI or a process full of delays, talking to non-technical salespeople, etc. = losing points, losing business.

Other factors in play:

Virtualized network devices: spin up a virtual router, firewall, etc. in the Cloud or CoLo, and maybe it’s pre-staged hardware, e.g., Equinix’s bare metal offerings (ahem, “Platform as a Service”?).
Virtualized links: securely leveraging a portion of the bandwidth on very high-speed fiber links or a virtualized fabric cross-connect within a CoLo and between CoLos (e.g., Equinix, Megaport, PacketFabric). Who owns fiber, where, and what partnering agreements do they have?

One more general observation …

I think this tech area is exhibiting something we’ve seen previously in other tech areas: overlapping waves of innovation coming faster and faster. My mental image here is that something new comes along, then a new, improved version comes, then somebody innovates on top of that, and that comes along even faster, etc.

The customer reality is that it is extremely costly to “change horses in mid-stream,” so depending on when an organization buys into a new technology, they then are locked into what rapidly becomes an older technology until they amortize the hardware, deployment, and other costs. Buy in too soon, and you’re stuck with a less capable product. Wait too long, and you miss the benefits.

So, for this NaaS tech area, what are the waves I speak of?

Wave 1: WAN circuits, slow provisioning, long contracts.
Wave 2: MPLS WAN. Access provisioning slow, core faster, still long contracts. Changes not agile, little/no self-service.
Wave 3: L2 fabrics, with or without SLAs, typically in metro regions, often based on the dominant metro fiber provider. They’re already in your building and can connect you locally quickly, or sort of quickly, depending on their degree of automation (some are not, and are more error-prone). MPLS cores may have the edge for L2 fabrics. I’m not sure I’d trust an L2 provider using Spanning Tree at any scale.
Wave 3.5: “Fabric services”. For a few years now, Equinix and Megaport have been offering a “fabric service” based on CoLos. Get physically patched from your cage or presence to one of their edge boxes, and then you can use their GUI to logically connect (VLAN based) to the same or other CoLos where you have similar connectivity, also to major CSPs. Also useful for B2B connections to other organizations that are connected to the fabric. I think of the fabric here as in effect, a global logical patch panel for quick connections to sites where the fabric service provider is present. Once you’ve got that initial physical connection, the GUI part is rather quick, sometimes limited by the CSP provisioning process. (I have experienced and keep hearing that Azure provisioning is other than fast.)
Wave 4: SD-WAN. Leverage VPN to address the slowness of getting access circuits, can still do circuits/fiber if SLAs are a problem (ISP not good enough). Faster connectivity at a larger scale, which leads to challenges in designing and managing it? VPN overhead eats CPU for breakfast, so higher speeds get costly? At scale, just managing all the VPN tunnels gets fugly.
Wave 5a: Some newer NaaS services seem to focus on “Cloud Router” services providing distributed routing between CSPs, sites, etc. Well, some may backhaul to a physical or virtual router, but that’s sub-optimal (latency). I have the impression this service is primarily routing/connectivity. If you want to encrypt on top of that, that’s your choice. SASE adds security functionality to the mix.
Wave 5b: Graphiant is positioning itself as a replacement for SD-WAN, with several apparent cost and efficiency optimizations and providing SLAs. I risk being a fanboy, but a good part of their pitch makes sense to me as well. They are partnered with Equinix for their core routing platforms and have choices as far as partnering for core and edge connectivity.

I must note that some of this evolution reflects changes in the marketplace. For instance, MPLS pre-dates most of the Cloud era.

Khalid Raza of Graphiant talks about a coming evolution towards a B2B services marketplace that is edge-based, what I’d call Data as a Service, less of a consumer orientation. How does that affect the above? Not something I’m prepared to answer here! And do note my prior blog about DevOps Networking and Cloud.

Taxonomy

NaaS can also be considered from the perspective of who provides the NaaS service and what is their core competency. The following describes the current forms of NaaS from that perspective, along with the pros and cons. Velocity, or speed of provisioning/adding new connectivity is one key factor. Obviously, the cost is another.

Public and hybrid cloud service providers. For me, this started with AWS offering a transit gateway to efficiently interconnect your AWS locations, and extend that to your CoLo/data centers as well. It then turned into a WAN play. Other CSPs? Maybe not so much? (I lack data on this.)
- Managed service
- Fast setup
- May require VPN to CoLo or data center or other sites
- May have traffic exit costs (perhaps hidden in the gateway/router pricing?)
- Possible limitations, e.g., connectivity to another CSP. Tying in “Cloud Routers” below, from a third party may address that.
Telecom providers. Basically, WAN plus NOC. Could be circuit, fiber, or MPLS-based, but do we care as long as it is robust and secure?
- Managed service
- Have telcos gotten faster, or are they still slow to deploy circuits, WAN routing, as in 60 days or longer? I vote “very slow.”
- Are they playing catchup to remain relevant? Ok, that’s not quite fair, we’re going to need access connectivity (sites to CoLo) for a while if we want SLAs and not just VPN over Internet.
- No self-service as far as I know (but I don’t order circuits).
- VRFs generally hard/not available.
Enterprise OEM managed services
- g. Cisco is talking up their SD-WAN (Cisco or Meraki) as a service with them or a Cisco partner managing said service. Let’s treat this as a special case of the next category.
SD-WAN (and VPN) managed services
- Can DIY but there may be a trend to outsourced management of SD-WAN (and NetCraftsmen does that for some global firms)
- Complexity (VPN, multiple providers, circuits, etc.)? Encryption overhead?
- Heavy use of VPN typically, so SLAs might be problematic unless you use telecom services for access
- Possibly multiple encrypt/decrypt cycles if you want hierarchical routing or hops with intermediate security enforcement.
- Setup lead time if you want SLAs: getting circuits or fiber connections to your locations
- Complexity scaling challenges as the number of sites, B2B partners, etc. increases.
Non-CSP Cloud-Based and/or Colo-Based Virtual Routers, Cloud Routers
- g. Alkira, PacketFabric (“CloudRouter”) for Cloud-Cloud, can also connect to CoLo sites etc. I don’t think they offer “CoLo fabric services,” but I may be missing something (from a quick scan of their websites).
- g. Equinix, Megaport for CoLo-homed “fabric” services that also connect to the CSPs. This started as just “plumbing” (VLANs as circuits) but is evolving quickly now with the onset of Cloud Router offerings.
- PacketFabric is primarily CoLo to CoLo and Cloud as I understand it, less of an intra-CoLo fabric provider.
- One question mark (for me, anyway) is cloud exit traffic costs. And are such costs incurred in getting your traffic from your cloud location to the cloud router’s location or local cloud connection point? The point being that the cloud router or firewall may connect to the NaaS provider’s leased WAN fiber connectivity with no traffic costs, but getting your traffic forwarded to that lower-cost connection might still incur CSP costs. (I haven’t shopped the providers to see what they say re this, time-to-blog too high. I’m bringing it up as something for you to verify when shopping for such services. Potentially subtle costs that aren’t obvious?)
- Another is latency. If the “cloud router” is an actual physical or virtual router in one cloud or CoLo location, latency should be a concern: backhauling all traffic through that one location. So, is the Cloud Router distributed with effectively fully meshed between connections to it? Are there noteworthy “detours” in the CloudRouter provider’s backbone that add latency? (One recent test reached Ashburn via Chicago, for instance.)
- May well support VRFs. (Another shopping question to ask!)
- CDNs (Content Delivery Network providers) and others with lots of fat pipes and well-connected to CoLo/Cloud may also show up in this space as they add pipes and physical locations. (Cf. Network World link below.)
Integrated NaaS. Ok, I made this name up because I don’t know where else to place Graphiant. They’ve re-thought and cleverly redefined the technology stack used.
- “NG-SD-WAN?”
- Their core network appears to be primarily MPLS technology, leveraging physical or virtual routers in Equinix CoLo and various Cloud locations. They presumably have a central provisioning tool similar to an MPLS controller.
- Engineered to reduce costs:
  - Low provider router CPU etc. impact because payload encryption is end-to-end between customer edge (“CE”) devices, and only header authentication used from edge to core – Core routers just forward, no decrypt/re-encrypt cycle
  - That approach distributes any encryption burden to the CE devices
  - Core forwarding is label/tag-based, highly efficient
- Fast deployment similar to SD-WAN (start with VPN, then, where desired, shift to an edge circuit)
- Managed deployment of edge devices by partners
- SLA support
- Supports VRFs readily
- Cloud egress costs???

Cloud Routers

Cloud Routers is a current hot topic. I expect fresh announcements and growing capabilities in that space. Naming of these and similar offerings has the potential to get confusing, particularly as different vendors jump on board with different capabilities in their offerings.

Attention vendors! It is probably a bit late already, but might we hope that everyone uses the same terminology, to minimize confusion?

Quality of documentation will likely be one vendor differentiator.

Ease, speed, and accuracy of sales process another.

And of course, ease of GUI use is another aspect, but unless you do a pilot with a couple of vendors, may not be a clear differentiator as compared to sales, web pages, documentation.

Security?

How do you provide security with these NaaS services? That’s getting a bit beyond my intended scope, but I’ll attempt to cover the topic briefly.

I presume “Security” in this context means firewalls rather than router access lists, or endpoint agent-based.

So how do I do that? It seems like the answer is VRFs (or VLANs if you have a L2 service). With SD-WAN, you can tie tunnel interfaces to VRFs to segregate traffic that you feed into a firewall, centralized or at sites, etc.

With Graphiant, VRFs are easily part of the service, so you can segregate different types of traffic cleanly across the WAN.

With the other forms of NaaS above, it seems like you can’t really do VRFs. E.g. internal connections (and CSPs as internal?) versus B2B, that sort of thing. So you end up with multiple different sets of connections as the alternative to VRFs. Extra complexity, provisioning, and support hassle, etc.

Conclusion

I’ve done my best to describe the NaaS space as I see it. It’s a big space so I may well have missed some things some vendors are doing well, or poorly. I tried to stay fairly vendor-neutral in listing pros and cons, apologies if you disagree. My main goal was to give you some things to think about the next time you’re evaluating vendors/solutions in this space.

Links

https://www.networkworld.com/article/3687138/can-network-as-a-service-naas-have-multiple-definitions.html

Another Network World article that came after I’d written this blog, but similar theme: https://www.networkworld.com/article/3694508/who-is-selling-naas-and-what-do-you-get.html

For some of the points above, more about Graphiant, and his vision of where the NaaS industry and networking in general are headed, I highly recommend the following: https://blog.telegeography.com/a-brief-history-of-networking-as-a-service

Others may want to play in this space: https://www.networkworld.com/article/3687990/akamai-targets-cloud-computings-middle-ground-with-connected-cloud.html

This blog was written and put in our publication queue in February. In late May, Network World published the following article, which has a similar theme: https://www.networkworld.com/article/3694508/who-is-selling-naas-and-what-do-you-get.html

Some prior somewhat relevant prior blogs I wrote:

Note that any vendor bias in these primarily reflects what I’m familiar with.

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