Why enterprise networks need to move to an as-a-service model [Q&A]

For years, the enterprise has built bespoke networks to connect all company resources. These networks were slow to build, but once built did not change much.

That’s changing as networks become more complex and dynamic. Workers are highly distributed, edge computing has grown, most enterprises now connect to multiple clouds, and connecting to partners and customers is increasingly common.

Building networks by hand has become too slow, error-prone and time consuming. Networking needs to follow the lead of computing, storage and software, which are increasingly being deployed on an as-a-service basis. The result is that enterprises can build networks in minutes as opposed to months.

We spoke to Khalid Raza, CEO and founder of Graphiant and a former part of the team at Cisco, which designed, built, and delivered MPLS, to find out why he believes Networks-as-a-Service are the future.

BN: Why has networking been slow to move to a different model?

KR: The simple reason is that Network-as-a-Service (NaaS) hasn’t been an option. So, the real question is why hasn’t anyone built a viable NaaS until now? That’s where it gets interesting!

It boils down to a couple of key problems. First, we cannot continue to use the public Internet as our enterprise underlay network. It is a security and reliability nightmare. Packets flow over a vast digital wilderness over which we have neither visibility nor control.

SD-WAN uses tunnels to address these challenges, but in today’s massive, complex, dynamic networks, nobody can keep up with the workload of configuring and reconfiguring that many tunnels!

Which is why MPLS — nearly a quarter century old this year — is still being used. MPLS’s secret is that it is a private network. That provides the security, performance, and reliability the enterprise needs. The idea was prefect in the context of single service provider and merging of voice and data networks. We need to use the best of technologies and evolve them further. We need to remove the routing state from every PE router. Use SDN principles to separate the control plane from the data plane, remove per PE provisioning and run the control plane in the cloud so even and slow provisioning problems go away.

So, to build a new NaaS with the performance, reliability, and security of MPLS, but the agility the enterprise needs, we first had to build a private network based on today’s modern architectures to deliver a less expensive and agile networks.

But that wasn’t enough. We also had to innovate and make modern cloud style modifications to routing stack so we had the agility, resilience and flexibility today’s modern networks require.

BN: What features and capabilities are vital to a NaaS solution?

KR: It is all the things that make Cloud so desirable for the enterprise:

• Agile. You need a simple cloud-based portal to provision the network. No hardware, no complex licensing, no complex provisioning, no set-up — just click and go.

Click and minutes, not months and months.

• Scalable. Who knows precisely how much bandwidth they needed when they first build a new network? Nobody! The NaaS needs to make scaling up, and down, trivial. In fact, the NaaS should allow apps to request these changes programmatically.

Scalability needs to be effortless and painless.

• Consumption based. Enterprises are used to investing huge capital expenses (maybe millions) before the first packets flow. They are used to it, but they don’t like it. The NaaS needs to be a true consumption-based model. No up-front costs – just pay-as-you-go.

This allows the enterprise to match expenses to revenue. It is one of those core cloud attributes the enterprise is looking for.

BN: How can you ensure the network remains secure?

KR: It’s all about state — by removing unnecessary routing state from every core and PE routers we can make it more secure. The forwarding routers just understands how to move packet forward without any return path information by being stateless. To explain, let’s discuss how the Internet was originally designed. ARPAnet (the forerunner of the modern Internet) was designed to survive a nuclear strike. Packets were not routed using predetermined routes. Instead, the packets contained everything necessary for each router down the line to understand where the packet came from and where it was going, so that the router could send the packet down the line in an intelligent manner.

That way, if an entire swatch of the ARPAnet was destroyed in an attack, the surviving routers just routed packets around the outage.

Let’s stop for a minute and admire the elegant nature of this. At the time of ARPAnet’s design, no computers had yet been networked. So, this was an amazing design for a version 1.0 product.

But that was nearly sixty years ago. The problem today is that all that state information is a treasure trove for bad actors. The threat has morphed from nuclear first strikes to criminal (and state-sponsored) hacks.

We designed Graphiant to be stateless. As packets come into the Graphiant Stateless Core, we encrypt the payload (including all the customer state information) and put a metadata on the packet. The metadata provides everything the network needs to route but no sensitive information. As the packet exits the Graphiant Stateless Core, we strip the label of the packet and decrypt it.

One of the benefits of this approach is that we never have to decrypt traffic inside our network. NEVER even if we tried we don’t have the related keys so we simple can’t decrypt the data.. That’s a huge improvement over today’s networks.

The result is rock-solid security.

BN: What are the challenges of implementing NaaS?

KR: The challenges are not in how enterprises implement NaaS — the challenges are (as we’ve discussed) in building the NaaS. The whole point of building a NaaS is to remove implementation challenges.

You connect to our cloud portal, set up your network using a cool, simple graphical tool, and that’s it. You’re up. It takes minutes, not months.

What’s eliminated are complex licenses, capital purchases, time-consuming infrastructure provisioning, and all that configuration and setting-up countless tunnels. Just click and consume.

Image credit: Wayne Williams