Where does SDN make sense? We ask Fidelity’s Director of Global Network Architecture

carlos matos

Carlos Matos, Director of Global Network Architecture at Fidelity Investments

Credit: Fidelity Investments

Carlos Matos has been following Software Defined Networking from the get-go as one of the earliest members of the Open Networking Users Group (ONUG). We recently caught up with Matos, the Director of Global Network Architecture at Fidelity Investments, to get his view on how and where companies are likely to benefit from SDN.

Where do you think SDN offers the most potential?

I like to talk about use cases because it is the approach we use to evaluate all emerging or disruptive technologies. Sometimes you try to grasp too much, so putting things into perspective with potential use cases can help you make sense out of the opportunities. Once you start getting some wins then you go on to the next use case. A lot of companies end up doing three or four or five different use cases at the same time, and I think that’s a really good approach.

I think SD-WAN is still one of the top use cases out there for Software Defined Networking. It’s gaining a lot of traction. Many people have similar problems with wide area networks and remote and branch offices, where we need better manageability, better performance, and better quality of service control to those branch offices. It’s a common challenge for banks and other financials organizations, but it applies to any enterprise that has many remote offices. There are other hot use cases, of course, but SD-WAN is one of the hottest right now.

When you’re trying to implement SDN over a wide area network, can you do it with your own equipment or do you need an SDN service from a service provider?

When this SD-WAN concept first came out you saw a lot of companies say you could use their equipment or equipment the ISP would give you.   So that initial model raised questions about how to integrate your existing equipment. Now you see service providers looking to do that integration themselves. They’re offering policy-based routing, differentiation of services, application steering concepts and the redundancy of multiple paths into your branch. They’re trying to bring it all to you as fully managed services.

In those cases, does the service provider maintain an SDN controller or does the customer have one as well and they get federated in some fashion?

It depends on the model and the vendor. In some cases they offer just the connection to the branch and on top of that offer a specific flavor of SD-WAN as a controller that will manage the whole solution. In other cases they do an integration with your gear. But you can also just have a circuit brought into your branch and take care of it yourself.

Both VMware and Cisco executives trot out security as being one of the first and foremost things that SDN can help with. What’s your take?

It’s becoming more mainstream as a use case by itself. In the Open Networking Users Group (ONUG) we define a number of security use cases, including a new one for network fabrics security. For example, there’s a use case for SDN network monitoring that not only lets you monitor traffic, but also send that traffic to security solutions to attack vulnerabilities.

And there is another use case for multi-tenancy, where the big theme is really isolation and segmentation of the network. So part of the objective is security: separate your tenants within the network, create boundaries, create rules, create firewalls, service chains, create policies and policy enforcement points. So security has been addressed from day one in many different ways, but now we’re really focusing on it more as a use case itself.

How many use cases has ONUG identified at this point?

Initially there were seven or ten and we add several more every six months, in addition to user groups validating and testing several of those use cases and proposing recommendations and requirements to the industry.

What are the other ones that interest you most?

I mentioned network monitoring, and the reason that is so interesting is there are two or three use cases that go over that, but the one that is really hot and gaining a lot of traction is bare metal switching, or bare metal anything.

The initial bare metal use case was about using generic/commodity switches that you can load up with any OS to avoid vendor lock-in.   But that idea lead to a bunch of other ramifications, with people exploring ways to completely disaggregate networking, which is the most disruptive thing out there.

And on top of that you see things within the Open Compute Project creating more and more programmatic capabilities, like the Switch Abstraction Interface (SAI), and the open NSL and P4 projects. What they’re looking at is creating more programmatic capabilities so you can create ASIC-type controls, and the ability to update on bare metal to extend the livelihood of your investments.

Is the appeal of bare metal strictly a CapEx thing?

It’s CapEx, it’s OpEx and at the same time operational easiness. The price and margins have gotten much lower so there isn’t a big difference between what a Tier 1 or Tier 2 vendor can offer versus a bare metal switch. The big difference is in operational support, all the things surrounding automation, the orchestration and provisioning, that’s where you have a big impact.

You have a switch that you don’t need to touch to provision. You just plug it in and it will know what IP address it needs to go to find the OS it needs, and then it goes and finds the configuration needed, etc. You save man hours and avoid mistakes like configuration errors caused by typos. So it’s not the old CapEx picture, it’s more about the efficiencies you gain in the process.

And if you can load up different functions on those bare metal boxes, it also changes the whole licensing ecosystem because. If in the past you needed a centralized load balancer, a centralized firewall somewhere, now you can distribute that everywhere and

have fewer choke points in the network. You can push those functions to the top of the rack and have it functioning there. You have options.

So it’s not only about CAPex and OPex, it’s about opportunities for new efficiencies.

The network monitoring use case has been talked about for a while, but has something changed on that front that excites you now?

It’s the flexibility you gain. These new packet broker solutions represent a cost-effective solution for monitoring your entire network. So, instead of needing all these big physical devices out there, you can have distributed packet brokers and use them to bring traffic up to a consolidated point where you can send the traffic to virtualized appliances and tools, which can reduce cost for archiving and analysis.

And if you’re capturing the traffic right there at your packet broker, why not start sending that out to a big data island where you have Hadoop and other elements that interpret that data for you, finding correlations, finding events, alarms, etc. It is one of the areas that is going to get hotter because of the capabilities it enables.

In terms of standards and openness, are you guys a supporter of OpenDaylight?

I’ll tell you the concept of integrating a number of controlling functions within one controller is really attractive. We have tested and piloted it. I wish there were more applications on top of it, which are still missing. We are all about trying to find solutions out there that are truly open. I hope they stay open in that fashion.

Anything else we didn’t hit on that you think is important regarding where we stand with SDN these days?

One thing that gets overlooked is the social aspect of this movement. In the past everything was strictly confidential and we would not talk or share with others, but now we are collaborating and exchanging ideas with all these open groups and communities and that is truly powerful. If companies are not yet participating in these communities they are losing out on the momentum. The SDN hype is calming down but we’re seeing a lot of traction in these use cases. I think it is fair to say SDN is here to stay.

In addition, the big shift in the network industry towards automation and orchestration is truly exciting. We are now adopting and embracing methodologies like Agility and Devops that were initially exclusive to the developers domain. Now we use them in our day-to-day operations and in all aspects of project and change management in order to become more efficient.

So SDN is here to stay but how much longer is it going to take before it shows up everywhere? Any way to characterize where we are on the march to SDN?

Some organizations are slower than others to adopt. Look at cloud. It took some time to get where we are, changing how we view the model, changing the mentality. Now things are getting going. So the level of adoption is going to be much faster than it was before because you don’t need to come up with a way to put a rocket on the moon. Now it’s all standardized and you can use open cloud management systems instead of building one for yourself, so I predict a much faster time to market.

The same thing with SDN and Network Function Virtualization. People are just going to start consuming it because it is going to be much easier and much more cost effective to consume as the old licensing models change or cease to exist. I don’t have a crystal ball, but I’m going to say in the next two years it is going to really accelerate. It’s been a little bit slow in coming, but the moment people start consuming these standards and open solutions and start realizing the benefits of orchestration and software defined everything, I’ll tell you, it’s going to go really, really fast.

This story, "Where does SDN make sense? We ask Fidelity’s Director of Global Network Architecture" was originally published by Network World.