What the H*** does “Cloud Networking” mean?

Is there any such thing as “cloud networking”? On one level that seems like a dumb question, but if you look deeper into it, you see that we have a whole range of vague and often contradictory definitions. That’s too bad, because it’s clear that the cloud is transforming computing and applications, and because the cloud is inherently distributed, it’s transforming networks too. We just don’t quite have the range of the transformation yet.

It’s not that cloud architectures are, in diagrammatic terms at least, major changes over past models. In batch applications, we had the classic input-process-output flow, and as parallel computing models emerged, what tended to happen was that the front two elements were made into separate, parallel/scalable, components. The “output” piece, representing the actual database activity, was largely serial. In cloud computing, what’s happened is that those two front elements were pushed out into public cloud hosting and the back-end piece stayed largely in the data center.

Because cloud computing utilizes fully distributable components running on a global resource pool, it presents a bunch of different potential on-ramps for work, the “input” piece of the picture. As applications have transformed to optimally use cloud resources, some of the “process” pieces have also migrated to the cloud, and often these pieces run in a smaller set of cloud locations, proximate to the point where the data center is connected. This means that application workflows mimic a kind of “tree-in-the-wind” model, with the edge branches shaking around over a wide area, feeding bigger and less-mobile branches, and finally a largely stable trunk. That model is why the real “cloud networking” exists.

Networks, meaning specifically wide-area networks, have historically connected facilities. In the cloud-tree workflow model, there is no real facility to connect. That means that a corporate WAN can’t be built to connect these now-virtual places. The edge pieces are moving around in response to changes in workloads, failures, and so forth. If we assume (as I believe we should) that not only customer and partner access but also employee access to applications shifts to the cloud, you can see that the original notion of a VPN goes out the window for the simple reason that the traffic is moving increasingly within the cloud.

One striking impact of this is the growth of interest in SASE. The value of SASE is that it’s a virtual, secure, service termination that presumes it will be deployed in the cloud, which is where the access edge components of applications are now hosted. Just as other real application components can be shifted to match conditions, so SASE can be shifted, scaled, redeployed, and so forth. If it includes encryption capability, it can secure traffic within the cloud and onward to the data center. If it can support multiple cloud applications in and a single one out, creating a “node”, it can build an almost-traditional network model in the virtual world.

Another impact of the tree-cloud-network model is that all those tiny branches waving around translate to a need for connectivity not only in very small offices where traditional business network technology is too expensive or even unavailable, but also in the homes of workers, and maybe even casual locations like hotel rooms or airport lounges. The closest thing to universal broadband access that we have on the planet is broadband Internet, and so we can assume that more and more applications will be accessed via broadband Internet connections to cloud front-end elements. Where MPLS VPNs already exist, they might feed the cloud front-ends too, but the transition to Internet on-ramps for applications seems both clearly underway and inevitably complete. Thus, SD-WAN concepts become the model for creating a separate and secure address space for both application components and workers.

If we assumed that all corporate computers were concentrated in a single data center, what we’d end up with here is an Internet/cloud federation of services that then connected cloud-to-data-center in a massive (likely redundant) trunk. In the real world where there are often multiple data centers, either distributed for availability management or regionally to reflect local needs, what happens instead is the creation of a data-center-interconnect (DCI) grid that then connects to the cloud. This structure then supports the SD-WAN-modeled VPN.

I think that this picture describes what’s actually happening in the “cloud-network” space, but as I’m sure you realize, this picture isn’t really being presented by vendors. Each element of the picture is presented as an almost-independent product, in the name of avoiding the classic sales blunder of “boiling the ocean” and expanding the scope of the project to the point where near-term revenues can’t be realized. The challenge for enterprise planners is that the big picture is actually what’s driving the bus here, and not recognizing what’s happening makes it hard to judge technologies and products correctly.

One example of this is Graphiant’s launch. According to an article in Fierce Telecom, Graphiant is a NaaS product (whatever that is in today’s world of fuzzy definitions) based on a “stateless core”. If you read the article, it’s difficult to understand just what Graphiant is doing or even why it’s interesting. In fact, some of the stuff it a bit frightening; “At the heart of Graphiant’s pitch is its so-called “stateless core,” which acts as the hub to which each endpoint is connected and through which all traffic is routed.” Does this mean that each endpoint is homed to a single hub? That would be a disaster for a global cloud-network.

Graphiant is really providing a kind of super-SD-WAN-as-a-Service model, meaning that it’s a network provider rather than a product provider. The model is most similar to SD-WAN provider Cato Networks in that it isn’t a set of SD-WAN products acquired by a managed service provider (MSP) and then used to create a service for sale. However, the capabilities Graphiant offers are very similar to those that could be created by an MSP with the proper SD-WAN technology on which to base their services, and that’s the key point.

If a cloud network is inevitable, there are two ways to get there. One is to acquire the technical elements and build the thing, but that requires that broad understanding of where things are heading and what’s needed to get to the right destination. The other is to acquire a cloud network service that gets you to where you want/need to be without having to understand the details and build them into your own network.

The downside of this approach, other than the fact that there’s almost surely a higher cost associated with it, is that without understanding the way cloud networking is evolving and the way that your MSP is addressing that evolution, how would you know that the network you’re getting is really what you want in the long term?

You need to have SASE/SD-WAN edge features in a cloud network. Your SD-WAN implementation needs to be fully resilient as any cloud application would be, which means that workflows originating at any user point have to be secured on entry and put onto a VPN, which must then be able to route to the string of cloud components needed to process the work, and onward to the data center, without loss of connectivity if intermediate nodes scale or redeploy (this is what I think a “stateless core” means). Some SD-WAN implementations don’t allow for cloud hosting of nodes, or require stateful behavior of nodes to complete routes, so it’s important to know whether that’s the case in any SD-WAN plans you undertake. When you build a cloud network, or buy a cloud network service, you’re still building/buying a network.

The reality here is that a cloud network is a virtual network that is likely created using a combination of SD-WAN technology and the broader virtual-network technologies used for things like data center segmentation. The future of application networking, as I’ve said, is virtual, and every enterprise should be asking vendors how to build and maintain a virtual network that has the attributes needed to network that tree-cloud I’ve described here. Every vendor should expect that they’ll need to answer that question, too.