Virtual networks need a rethink to meet hybrid-, multi-cloud demands
The cloud will change enterprise networking. This article dispels some of the misconceptions surrounding the two technologies and highlights what enterprises can really do with them.
Everyone in tech likely thinks they know what “cloud computing” and “networking” mean, but they’re probably wrong, and their misconceptions about the first topic color their view of the second. Yes, the cloud is dominating computing, but most stuff isn’t “moving to the cloud.” This subtle point is already changing how we think about networking.
I’ve worked with the cloud from the first, and while there was a bit of “move this to the cloud” going on for server consolidation reasons, the overwhelming majority of stuff enterprises run in the cloud today isn’t an entire application at all. It’s the presentation layer of legacy data-center apps.
Corporate transaction processing, data storage and retrieval, and analytics are all things that demand security and reliability. From the first, enterprise executives have been telling me that these activities aren’t going to move to the cloud because they believe that their requirements can’t be met, and the cost would be greater rather than lower. My work with them proves out that view. Despite all the hype about the economy of scale of the cloud providers, the fact is that most enterprises achieve economies close enough to those of the cloud that the difference wouldn’t cover cloud provider profit margins.
Cloud: the presentation front-end of the data center
OK, so why then do we see cloud usage by enterprises growing at 40% or so per year? Because the cloud is being used to do things that were never done in the data center at all, need to be done now, and would be more difficult and/or expensive in the data center than in the cloud. Those things all relate to the way that enterprise core applications interact with customers, partners, and even workers, and so they all involve the internet.
Everyone loves online shopping, even just online-shopping research. Over the last five years, enterprises have been creating “portals” that link a glitzy online experience with the stodgy applications in their data centers. At first, these were aimed at customers, but they quickly expanded to support wholesale and transportation partners. And even before work-from-home, they were increasingly used to support remote workers.
Today, of the roughly 250 companies I know reasonably well, 244 of them rely on these portals, and all of them use the cloud to implement them. The cloud is the presentation front-end to their data centers.
Presentation front-ends are very difficult to build in the data center. Retail interest, from research to shopping, varies enormously from day to day and even hour to hour. Users are intolerant of long delays and poor user interfaces, and trying to create this kind of highly interactive experience from data centers would mean building out to peak volume and letting resources stand idle during slower periods, perhaps most of the time. The cloud, with its scalability, offers a cheaper strategy, and because cloud hosting is usually available in the same geography as each group of users, it’s also likely to perform better.
This cloud presentation front-end isn’t just about avoiding the data center; it’s also avoiding the corporate VPN. The cloud collects the activity of all those dispersed users, cloud networks connect all the front-end pieces, and the cloud network delivers everything through a single fat pipe to the data center. If the cloud’s presentation front-end is also used to support work-from-home, why not use it to support work from the normal branch locations? If you do that, then what’s the need for an expensive MPLS VPN connection to those branches? Why not just use SD-WAN or the same internet-and-cloud combo that supports customers and partners?
The cloud provides network services
We can already see symptoms of the real-time-interactive focus of the presentation mission of the cloud. Microservices, functional computing, and GPUs versus CPUs are all signs of event-driven thinking, and they’re all on the rise. But we can also see signs of the shift being driven in networking. Cloud providers are starting to offer network services within their clouds, something that encourages the internet/cloud partnership with its single off-ramp to the data center.
The impact on networking doesn’t stop there. The cloud is a virtual compute platform. Applications and pieces of applications float around, scale up and down under load, replace themselves if they fail, and are changed dynamically when needed, without changing other applications and pieces. Connecting this swirling complex mess is a job for a virtual network.
A real network addresses network-service access points (NSAP), not people or applications. Your home or office has a range of IP addresses assigned to it, and anything sent to those addresses goes to the NSAP that connects the location. In the data center, the same thing is true; applications have addresses that are the addresses of where they’re hosted.
This breaks down in the cloud, with scaling and redeployments, and so cloud providers have long offered address mapping facilities to allow an application to have a fixed address wherever it happens to be running. That’s fine for a cloud application, but it doesn’t work for applications that are spread across clouds or move between cloud and data center. For that, we need an address-mapping capability that’s not dependent on a single cloud provider. We need a true virtual network.
Virtual networks, which is what SD-WANs really are, ride on traditional IP networks but have their own rules for connectivity. If an application or component in the cloud moves because it’s redeployed or scaled, the virtual address doesn’t have to change. Same if an application/component moves into or out of the data center. Since connection rules are set at the virtual level, some implementations can also support what used to be called closed user groups, where connection rights for a user or application were limited to the boundaries of a defined group.
Virtual networks could be great for people who have multiple devices that they want to use interchangeably. A mobile worker might use a phone when out of the office and a desktop system when inside. With virtual networking, it would be possible to connect to the worker whatever device was being used, and to set up connection rules for the worker that apply whether they’re on the phone or at their desk.
Virtual-network thinking is the biggest lapse in enterprise-network planning. Even where enterprises actually use virtual networks (VPNs, SD-WANs, cloud virtual networks like elastic IP, and data-center switching), they don’t plan for the technology, but for the mission. I know of a half-dozen enterprises that have four different virtual network implementations in place, and that’s a major operational risk. How, after all, do you know whether your virtual networks are connecting or colliding?
You are going to be a bigger and bigger consumer of virtual network technology. Now would be a good time to start demanding all of your virtual-network sources come clean about how they’ll fit in this new world of hybrid and multi-cloud, and move away from those that don’t have a good strategy. The further you get down the virtual network path – and you are going to be taking it – the harder it will be to change.
This article was written by Tom Nolle from NetworkWorld and was legally licensed through the Industry Dive Content Marketplace. Please direct all licensing questions to legal@industrydive.com.
