Author’s Note: There’s a lot of talk and plenty of noise related to NFV in the telecom industry. It’s a time of market transformation with many executives and marketers making claims for how their companies are doing NFV better than others, or how they are ahead of the competition in one or more ways. I think we are missing an important voice: The CTOs. I am talking with my peers from service providers and suppliers to get a sense of what is real. I am sharing these conversations in this series called The Real CTOs of NFV. The title is fun but the intent is serious. Following is my Real CTO conversation with David Hughes of Silver Peak.

Prayson: David, thanks for joining us today. Please talk a little bit about your company and its role in the NFV transformation.

David: What's interesting about Silver Peak is that we come to the service provider market with an enterprise networking perspective. On the enterprise side, we were very early in driving the adoption of a software delivery model in networking, replacing a hardware model.

A lot of the lessons we learned through that journey are very applicable in NFV. I started Silver Peak in 2004 and we developed WAN optimization software running on Intel hardware and a Linux environment. Like everybody else at the time, we shipped our software using an appliance delivery model with our software running on hardware that we sourced and then shipped to the customer.

Starting around 2010 we realized that virtualization had made great strides with things like Virtualization Technology support in the processors, and the performance was there to seriously consider using virtualization as the base to deliver software as a virtual appliance.

We decided to double down on our efforts and launch a full range of virtual appliances spanning from megabit levels up to gigabit performance levels. Within three years we went from shipping 100 percent using the hardware delivery model to getting to the point where 60 percent of what we shipped was virtual appliances, and it has continued to grow since.

In going through that transition, we augmented the competency we had in WAN routing and WAN optimization with a new competency in virtualization and its support for all the various hypervisors, and for the different management environments. And, we began to learn a lot about what was going on with SDN both in the enterprise with technology from VMware as well as on the service provider open source side with OpenStack.

As time went by we had more and more service providers asking about our WAN optimization and more recently about our SD-WAN technology and how they could use that technology as VNFs in the NFV environment. We’ve committed to a service provider go-to-market strategy to complement our enterprise go-to-market and we are about a year into our engagement with service providers around the world.

Prayson: Your software has been running on standard hardware for a long time, but now you have moved from being appliance-based to being fully virtualized. What obstacles did you have to overcome to achieve that, and were they primarily related to performance or other areas?

David: I think that initially we were concerned about performance, but most of the performance concerns took care of themselves. Right from the beginning we designed our software for performance on an Intel processor. So we had implemented a zero-copy infrastructure, we made sure we utilized 64-bit support and so on from the outset. All those kinds of things meant that we had the performance that we needed.

I think there was a lot to learn in terms of support for all the different hypervisors and management frameworks, but also we needed to learn about the bigger picture of how virtualization impacts not just the compute environment but also networking and storage.

From an industry perspective, another key obstacle for NFV is the challenge when you have a great new technology, a great new architecture like NFV, but you're just trying to do this like-for-like exchange. You're taking the functionality that you were doing before in custom hardware, let’s say cellular/wireless and now moving it over to software, and you definitely get some benefits.

But to me, we should be looking at how to leverage that environment to offer new services and grow revenue as well as streamline operations, and that is what we are doing with SD-WAN.

Prayson: You mentioned that your company's background is in enterprise but now you're starting to do work with service providers. Do you feel that these NFV-based virtualized solutions are ready for carrier-class networks?

David: I think we're absolutely ready. One of the great things about NFV and the VNF environment is that you can focus on doing one thing and doing it really well. And for us, that's traditionally been WAN optimization and more recently SD-WAN.

We have 100 percent focus as a company on providing best-in-class VNFs for those functions, and we have them deployed across thousands of customers. The underlying technology is solid and proven and completely ready for deployment.

One of the things that virtualization provides is the ability to do multi-tenancy without having to necessarily implement every single function as multi-tenant inside one piece of software. That approach tends to complicate things. It tends to impact performance and it really makes the enterprise development and service provider development different.

If you can take advantage of the hypervisor layer to keep your tenants separate and reuse your software, the same software you’re delivering to enterprise can be used in the carrier environment. You can then get the benefits of that maturity and focus. I think that's a big advantage of the VNFs that we provide.

Prayson: You mentioned the need for multi-tenancy when working in an operator deployment. Another aspect is that the NFV infrastructure including the server and the virtualization layer could potentially be shared among a number of functions, not only yours but perhaps some other virtual network function provided by the operator.

Do you believe that the current virtualization layers, whether KVM or VMware, have the needed support to isolate the various functions and assure that each is operating properly and is isolated from the others?

David: Yes. I think to the first order they do. There's always more tweaking you can do if you want to drive out the last drop of performance. Things like managing CPU affinity and managing the way the cache is used. Even through processors have multiple cores, the processors include many shared resources, like cache, memory bandwidth and thermal management. It is not realistic to expect the exact same performance from a VNF running alone on a dedicated processor, as compared to the same VNF running one processor while running other VNFs in parallel. The real test is whether the VNF provides sufficient performance for the end user and application.

I think that people have to weigh whether they want to squeeze out those last drops of performance so they can fit more VNFs on a given piece of hardware. Or do they want to focus on the ease of management, ease of moving things around, where they're not so focused on trying to get the absolute maximum out of each and every single VM but rather on just being able to easily manage many VMs?

There’s an interesting question there of how far you try and optimize things versus using the defaults. From the enterprise, what we've seen is that the defaults work pretty well. We try to make sure that our VNFs would work well in almost anyone's given enterprise without having to tweak things.

Obviously, that means leaving a little bit of performance on the table, but it makes it really easy for people to deploy. In service provider environments maybe people are willing to spend a bit more time on the tuning. But I still think there's a trade-off there on time-to-market and resiliency and ease of operations versus squeezing out those last drops of performance.

Prayson: That's a very interesting point. If you talk to operators and ask them about what they're hoping to accomplish with NFV, one answer you get is things like CapEx and OpEx reduction, which would tend to argue for more optimization and tweaking.

But the growing consensus is that the real value of NFV is in service agility. The point that you made about making services dynamic, making them easily deployable and going fast outweighs the benefit of getting those last few points of performance.

I think we're going to see more and more people realizing that the real value is the innovation, the agility and going fast as opposed to getting that last drop of performance.

David: I tend to agree. If I had to make a bet, I think that's the best side to be on.

Prayson: As you moved from an appliance-based deployment into NFV, what was the one thing that was most surprising or unexpected?

David: One thing that surprised me was performance. This goes back to when we first looked at virtualizing our clients, which was four or five years ago. We spent a lot of time optimizing performance on our systems by tying certain tasks to certain processes and so on.

When we first considered virtualizing everything, we were actually concerned about performance. We were concerned about how we would ensure that we were delivering the same type of consistency that we had when it was running on dedicated hardware.

I think the biggest surprise for me was that as we deployed and rolled our stuff out into thousands of customers now in the enterprise, we found that the number of support calls we got around hypervisor performance and hypervisor tuning was tiny compared to what we expected. The number of times that performance tuning comes up is relatively small.

Prayson: That's good news for operators who are looking at these technologies but are concerned about performance. You also mentioned that you're starting to get more inquiries from service providers. Right now, SD-WAN is a red hot topic for those providers. They see it as a threat because the way that some of these SD-WAN solutions are being positioned is to replace existing VPN services.

However, the operators also see this is an opportunity to create their own over-the-top services. How do you see the role of SD-WAN both for end users and service providers, and are they mutually exclusive?

David: I don't think they're mutually exclusive. I think SD-WAN is good for both. I don't think there's so much debate about if it's a good thing for users. It's really what they've been crying for. They want more flexibility in terms of the type of connectivity they are able to use when adding new branches or new locations. They want connectivity to be automated.

They want to get out of the business of managing elements and think about describing services. And they want it to be application-centric. They want visibility at the application level. They want control at the application level.

SD-WAN is all about solving those problems, whether or not it's a do-it-yourself implementation by an enterprise where they’re buying SD-WAN appliances and building their own network, or if they're getting it from a service provider.

For the carrier there's a couple of opposite perspectives. First, if you come at it from the point of view of the CEO or CTO or people in charge of strategy: they're always looking at how to add value and how to become more embedded in the customer and the enterprise's value chain. They want to figure out how to move up the stack so that instead of selling point-to-point connectivity or relatively undifferentiated IP VPN capability, they can be providing more and more value to the customer.

If you boil down SD-WAN, it's all about connecting users with apps. It's not really about packets. It's about users and apps and everything is described in terms of users and apps. That shift in focus from a packet level to an application service user level is something that I think can let carriers move up the value chain and deepen the relationship they have with the customer, by adding more value and providing end-to-end application level SLAs no matter what transport the packets are flowing over.

That is really a big opportunity for service providers who are willing to move and figure out how to leverage this technology as a managed service.

On the flip side there may be a product manager who is focused on MPLS, who's looking at SD-WAN and seeing that it may erode the MPLS business in the short term. However, I think that most customers are looking at SD-WAN as a way of augmenting their MPLS service.

I do think that in the longer term MPLS will be impacted, just like in transitions from TDM to frame relay or frame relay to MPLS. Those transitions are driven by broad IT trends that are inevitable. It doesn't really matter what any company or any individual does. These transitions are going to happen. It's really important that carriers focus on the opportunity rather than obsessing around the threat.

Prayson: You made a great point about frame relay. That was designed as a way to get rid of dedicated leased lines. Rather than being a threat to things like T1s, it wound up being a driver for demand because suddenly it became much easier to create these private networks.

Likewise, it could be the case that operator-supplied SD-WAN could drive the need for the inherent reliability of today's service provider VPNs. In particular you mentioned the application-driven nature of SD-WAN, moving from a focus on packets to things like intent and policy.

Do you see those types of functionality rolling into managed VPN services directly, or is that going to be more of an overlay using SD-WAN technology?

David: I think SD-WAN provides a great platform for the next generation of VPN service. And I think that it's really interesting in an NFV environment when you couple it in with what's happening with universal CPE.

The idea of having standard x86 hardware out in the customer location where a NID would be and running SD-WAN software out there is the killer app. It allows them to roll out this next-generation VPN service.

SD-WAN enables coupling a new service with new revenue opportunity with a new architecture, NFV, and a new way of doing things. In some ways I think that NFV has been about deploying apps that would have been done in hardware in the past or functions that would have been done with hardware in the past as software.

You're replacing like with like. What's interesting about SD-WAN is that you can get a twofer. You can roll out a brand new service, a potentially brand new revenue stream, and move to a software infrastructure at the same time.

This is a really exciting aspect of SD-WAN. It's a great way of proving in this new architecture and at the same time doing more than just replacing something you have already with an equivalent. Instead, you're actually rolling out something that's new and better.

Prayson: There's a certain amount of fear and misunderstanding of NFV on the part of operators. You said that SD-WAN is a good way to get started. Do you think that service providers see SD-WAN as a way to get over the hump of initial deployments of NFV?

David: We're talking to a lot of service providers, and every service provider has different opinions. But I think almost all service providers are really interested in looking at how SD-WAN can be leveraged to build a new service.

It almost always is coupled in with their NFV initiative and looking at universal CPE. I think most carriers are putting those two things together and exploring what can be done there.

Prayson: What do you tell operators about how they can get to new services? Do you have anything concrete you say back to them when they ask?

David: Yes. The demand that we are seeing from enterprises for SD-WAN service is completely unprecedented. This market is totally exploding. We are looking at demand that's doubling quarter over quarter and it's starting from a number that was 10 times higher than what we had planned. It's growing really fast.

We meet enterprise customers every day who are very interested in buying this as a service. They want the benefits but they don't want to be managing it or deploying it themselves.

There's an element of SD-WAN that's about saving money but there's a big element of SD-WAN that is about shifting the terms of the service from transport to actually delivering an application to a user. I think that's something that every service provider has to look at.

I think it's particularly exciting for carriers that want to be able to offer services that extend beyond their physical footprint. But even for those that want to operate within their physical footprint, there are some interesting opportunities for them.

Prayson: That’s amazing! That sounds like a great opportunity for service providers.

David: Absolutely.

Prayson: That’s all we have time for today. Thank you for sharing your views.

David: Thank you for having me.