Networking for remote work puts the emphasis on people, not sites

Many companies had to support work-from-home (WFH) during COVID, and most looked forward to having their staff back in the office. Most now tell me that some or all of the staff isn’t coming back, and that remote work is a given for at least some positions, likely for a very long time. That’s opened major questions about how these now-forever-roaming workers are connected to information resources and to each other.

Didn’t we solve this already, with Zoom and Teams? Sort of. Collaborative video applications provide a reasonable substitute for meetings, but you still have the challenge of application access and information delivery. A bit over 80% of enterprises I’ve talked with say they need to make a remote worker look like they’re at their desk, and they need to be able to work as though they were as well.

During lockdown, most companies said they relied on sending files and documents to workers. A few used SD-WAN technology to connect workers’ homes to the company VPN. The former strategy is very limiting and inefficient; you can’t replace checking account status online by sending around documents. The latter is a reasonable approach for some workers, but it’s expensive to give everybody an SD-WAN appliance to take home, and it’s also difficult to support. But you can run many SD-WAN clients as cloud software. Why not use the cloud?

One big enterprise I talked to thought about that, and then had another idea. When they explored that question, they realized they were already using the cloud as a front-end to facilitate customer marketing, sales, and support. A cloud application provided a front-end to their legacy product, order, and account management, making those systems look like they were designed for customer use. Why not use the cloud to provide workers with broader access? Customer applications were restricted depending on which parts of the core business applications they could access; worker applications would have fewer restrictions.

Hey, great idea. They divided up their application APIs. Those on “the right” are the web portals designed for customers, and these can generate only a limited number of transaction types, with limited data access/update capability. Those on “the left” are designed for workers, and they offer broader capabilities. Both sets of APIs use the Internet and the cloud, and you can access them anywhere.

Even in the office, it turns out. When this company started working through their cloud-API support plan for their remote workers, they realized that most workers weren’t remote all the time, they came back to the office. Once there, they used the “local” GUI for their applications, and they didn’t like that. It was different and required different instructions, and workers liked the web/cloud interface better. So they gave the workers access to that same set of “left-hand” APIs while in-office.

Then somebody looked at traffic reports, and they saw that traffic on their VPN was down sharply. Why? Because worker access to applications wasn’t coming through the VPN because even branch-resident staff were now using the Internet/cloud connection to get to the data center. The company realized that they could downsize most branch locations from MPLS VPNs to SD-WAN and save a boatload of money. In some locations, they could eliminate any VPN connection because there was nothing going on in the office that required a VPN at all. Where there were servers, special devices like you’d find in banking, they still needed SD-WAN VPNs, and some big offices with a lot of traffic could still justify MPLS, but most could use the Internet/cloud connection directly.

As the company expanded the trial on this new approach, they realized that it wasn’t without challenges. Internet service reliability varied considerably, and while a hinky connection to a single worker’s home might be tolerable, you couldn’t support an entire remote office with something you couldn’t count on. The solution was to have a backup connection – either a different ISP or a mobile backup option. This raised the costs, but they were still far below the levels of an MPLS VPN, and the workers still had a consistent interface whether they were in or out of the office.

The initial approach, using SD-WAN technology, is also being reviewed. SD-WAN is really a subset of the general technology of virtual networking. Most of the SD-WAN vendors also offer broad virtual-network tools, and these almost always include device clients for personal computers, tablets, and even smartphones. Using a virtual network that can extend right to the user’s device improves security significantly. Since the company’s outside sales and support people were already using VPN clients and the Internet, they understood how to set this up and keep it secure.

Another issue that came up is the termination of the VPN connections in the data center, where those core business applications and databases were located. It turns out that the overhead for this task can be considerable, and it varies depending on just what virtual network or SD-WAN solution is used. Testing of different implementations is now a part of the project pilot, and a final decision is expected in 2023.

Then there was the internal audit group. The compliance people initially went berserk over the idea of having all this critical traffic on (gasp!) the Internet, where all manner of evil doers were lurking. Management pointed out that customer sales and support was already being done using the Internet and the cloud, and assured the auditors that SSE, SASE, and proper API design could secure the new application approach just as easily as it was already securing the customer (right-hand side, for those who need the reference) APIs.

The company still plans to use online collaboration (Teams, in their case) for virtual meetings, but of course Teams operates over the Internet so that doesn’t change their networking needs. They found that where their pilot test of the approach was running, remote workers who were in the office still liked to use video collaboration, and that their document-sharing dropped as real-time application access became available, making the meetings easier to organize.

There’s a lesson here, and that lesson is that remote work is just another force that’s making enterprises realize that it’s networking people that matters, not networking sites. And networking people means linking them to the application/information resources they need. For decades, we’ve ignored the role of applications in building networks. Now remote work and the cloud are teaching us that by tuning application strategies, you can tune your network over a much wider range of options, and pick better ones, than you could if you hunkered down on pure site-connectivity goals, as was the past practice. Hey, remote work may have taught us more than just how to keep our pajamas off camera.