Understanding the hidden costs of virtual CPE

Listen to post:

One of the interesting adjacent markets of SD-WAN is network functions virtualization (NFV) where it becomes possible to run branch and network services as virtual workloads. There are many benefits to virtualizing network functions such as increased agility, speed of deployment, and centralized management. ZK Research strongly recommends companies look at virtual services as part of their SD-WAN strategy.

As part of that decision, network professionals need to consider how and where these virtual services should reside. One option is to run standalone virtual services as individual virtual CPE (vCPEs) on physical appliances, such as routers or servers. The other option? Run them as shared, multi-tenant, cloud-resident services.

Good and Bad of vCPE

Many engineers have leaned towards vCPE as the on-premises model mostly because it mirrors what is in place today. Routing functions tend to run in, well, routers, firewall functions tend to run in firewalls. Relying on vCPE has that same familiarity.

Replicating the old model provides some value, namely the consolidation of hardware infrastructure. There’s also an obvious cost advantage of using vCPE and not separate hardware appliances.

But there are some hidden costs that buyers should be aware of:

  • Device scaling: Even though the services are virtual, they still need to run on a hardware appliance. Most edge appliances are optimized for cost, which constrains the amount of computing available on the box itself. The virtual services may run fine in a lab and at deployment time. Over time though, the amount of horsepower required to run the services goes up as more network traffic and data is generated. When this happens, the device runs out of juice and IT is left playing a careful balancing act. Upgrade the hardware or start turning services off. This can be particularly damaging to security as turning off some features might leave the organization open to being breached.
  • Maintenance of appliance: If there’s an appliance, it will need maintenance to ensure patches, firmware, operating system, software, and other things are kept up to date. Even in a managed services scenario, where the service provider handles this, the costs are still there but might be hidden from the customer and presented in the form of higher monthly charges. If there’s hardware, there will be maintenance costs and, on average, this runs at about 25 cents per year for every dollar initially spent.
  • Management complexity: The virtual services may be co-resident on the single appliance but in actuality, they are still distinct appliances that require independent management. Each one would have its own management console, updates and configuration changes. Also, since the vCPE are their own domains, the data isn’t integrated at all so gaining insights from the data collected requires manual integration of the data, which can be difficult, if not impossible.

An appliance is still an appliance, no matter what the format. Businesses that choose to go that route do not get any of the cost or elastic benefits afforded by the cloud and the management model remains the same, which is one of the biggest challenges in running a global network.

A Different Approach

The other option is to run virtual services in the cloud. In this scenario, the only equipment needed on premises is a small, appliance for moving traffic into the cloud for processing. From there, the services are optimized and secured in the network removing the burdens of device scaling, appliance maintenance costs, and management complexity from the customer.

Virtual CPE may seem appealing but changing the network without changing the service layer is like upgrading the body of a car and leaving the old engine in place. SD-WANs came into existence because the cloud changed traffic patterns. It makes sense that the service and management layer would move to the cloud to give those services the same level of elasticity, agility, and manageability as the network now has. A good way to think about the relationship between SD-WANs and virtualizing network functions is that the former brings agility to network transport and the latter creates agility at the network and security service layer. Doing one without the other is only solving half the problem.