Jon Hudson has over 20 years industry experience across multiple roles including network engineer, UNIX sysadmin, SAN engineer, production operations architect and director of systems engineering within financial, online gaming and manufacturing industries. In 2009, Jon joined Brocade from Juniper Networks and is responsible for new emerging technology, as well as standards development within the office of the CTO. Jon recently sat down with SDxCentral to discuss the current state of software defined networking (SDN), network functions virtualization (NFV), and DevOps and where he sees the industry as a whole heading.
SDxCentral: How big is the SDN Revolution?
The software router doesn’t look any different from a hardware router. It interfaces and how you instantiate interfaces and protocols it looks like a real router. The fact that you are in a giant machine is somewhat obscured. This means that NFV is exploding because it’s easy to consume.
SDN on the other hand is a collection of ideas, the abstraction of data and control planes on separate physical devices being one. It provides a very robust easy-to-digest application programming interface (API). Growth in SDN apps has not been as shiny. It looks better when you consider that NFV instances can become one of those applications. Automate options like turning a server into an NFV router for peak load; do you want to scale up to 1,000 interfaces, or is it to build 100 servers with 10 interfaces?
The Brocade CEO, Lloyd Carney, last week talked about how specialized hardware in data center has seen its day. A lot of people are wrapping themselves around the security blanket of network processors. That is perhaps too gentle, kind of like bumper rails in bowling. What we’re talking about is standard x86 servers becoming full-scale routers and switches, normalizing that hardware layer. You’re entire data center is x86 servers that act like a router, but they don’t need to be routed tomorrow, or even an hour from now.
This whole idea may take a couple years. We’re not talking about moving from custom application-specific integrated circuits (ASIC) to just go to merchant silicon network processors. We’re talking about moving to all of those x86 processors.
When it comes to the movement and how we are progressing, I’ll be honest, it’s not progressing as fast as I’d hoped. I thought we would see a larger variety of applications and a larger market for them by now.
So what’s the holdup?
Hudson: One place I think everybody is struggling is that we had SDN being the controller, with a separated data plane and APIs, which is a DevOps thing. This was being pushed toward the enterprise markets. Then you had NFV being pushed toward the service provider markets. This was backwards.
Not only do very few enterprise IT groups have coders or developers, but I’ve even had some tell me that they don’t want coders. They want Legos, and they want really small Lego pieces. So this means the enterprise market is dependent on an app community providing those apps, which leads to our problem.
Think about it like this: If you go to the enterprise and say here is a controller, and there aren’t a bunch of apps, it’s akin to if Apple had launched the iPhone without an app store. Then your customer asks, “Why do I want a controller?” and you say, “For the amazing apps,” and they ask, “Who writes the apps?” and you say, “You do, Mr. Customer, good luck!”
This resulted in everybody running around with controllers, starting to build cool apps, but building that community up takes a long time. If you don’t have the existing community, there is much less support for new developers. And let’s face it — for many, writing apps is a scary thing.
Then on the other side in the carrier space, you had NFV being pushed. They are the ones with coders that could really take advantage of the controller. The equally mismatched carrier and cloud providers are used to writing their own software. They understand writing apps and could more easily benefit from the controller SDN model, which to them is what they need to do to scale. The platform nature of the controller then becomes a bigger opportunity, but a longer-term investment. You are selling a development environment.
What has slowed things down, as an industry, is that we have directed the wrong meal to the wrong person. If enterprise groups saw a bigger focus on NFV and carrier/SP types saw more focus on SDN apps, then we will see greater adoption.
So how do we get these exciting new applications?
Hudson: We’ve seen a lot of movement in the last year, more companies coming up with apps, but we still aren’t anywhere near the mobile phone market. Let’s face it: There were a lot of iOS apps and Android apps before we ended up with 20 really good ones. For a lot of us, the SDN Controller is evolving a little slower than we would like, but it’s probably because we weren’t being realistic about how long it takes for those apps to really get going.
What companies like Brocade have to do is build the controllers and developer environments and help customers write applications.
How important is the DevOps movement?
Hudson: It’s huge. It’s a long time coming. However there are some challenges that are not helping the movement along very well. The core of that discussion is that this whole DevOps momentum is being treated as rather black and white, or boolean, and there are more shades of grey. As network engineers, we went to school, we learned to code, and then we decided not to code. To say to us now, “Let’s code,” it’s not a rosy sounding proposition for many of us.
A lot of us can code, but I’ve never considered myself a developer. I’ve never worked on a large team with development style schedules. The reality of the DevOps movement is that it’s not as boolean as everybody thinks. Many people will continue to use the CLI, but will start coding for 20 percent of their job. Another person may automate 50 percent of operating procedures, but do the other 50 percent with GUI in the very visible NOC command center. So I would not be saying things like, “The CLI is dead,” or “You must all become developers or die.” And don’t confused scripters and coders with developers. Developers write applications. Hopefully we do get one win out of it, and that is that doesn’t mean that no one ever does anything again by hand in production. Ever.
Can you give examples of DevOps and how it works?
Hudson: If you distill it down, it’s incredibly powerful. The idea is: If you do anything in production by hand again, I’ll push you off a cliff. Things done in production should not be done in a manual way. It would be done in a repeatable, shrink-wrapped way.
When I was a sysadmin (system administrator), you came up with an idea, you did it once, you tried it, and then you wrote a script to replicate. Why would you want to do anything more than three times by hand? If you know something works, you automate it. You containerize it. You wrap it up in a bow. That’s a brilliant message. That’s something that networking absolutely needs to absorb. That doesn’t mean you can package and easy button everything, but many things.
We’re not going to turn all network engineers into full-scale developers that write code all day. How much code do they want to write? There are some things that you could automate, but it’s not always worth it.
The definition of “enterprise networking” and “service provider networking” seem to be changing and these two technology verticals are merging. What do you think?
Hudson: It’s changing a lot, how much really depending on what people want and what markets people want to break into it. I think it’s a trend you see repeat because collapsing products can really help.
Think about the way we used to define telecom equipment with different characteristics. For example, it ran on DC power and it was compliant with certain standards like network equipment building systems (NEBs). Producing different products for every group is difficult.
You have old examples where companies like Sun might be producing one kind of server, then had to reprocess it for the telecom customer, which added complexity. But those deltas fade over time and things blur together, so now for the most part, a server is just a server. As layers of the data center normalize and commoditize, new opportunities rise for companies to stretch into new areas.
Even some software services have lost their “on the mountain top” status. I remember a time when company email was seen as a crown jewel. The local IT team running email became a core part of the business. Times change, and the reality is, running email kind of sucks. You only get attention when it doesn’t work. So attitudes change and IT departments now might outsource an application, even one as previously valuable as email, just because it’s so easy.
Many carriers or larger providers are looking for new ways to sell additional services. For many the promise of “building it big enough” and eventually making a ton of money doesn’t always work out. So often then the ones that invested in infrastructure need to diversify themselves and launch new products, which means they have to get closer to the customer and provide more applications and become a cloud provider.
We have had this battle between cloud and content providers and bandwidth providers, which is embodied with the politics of net neutrality. It seems like it’s easier for the cloud companies to build pipes than for the pipe providers to build cloud services, isn’t it?
Hudson: I completely agree. That’s a tell for how the hand is going to go. My personal opinion is that the company that is closest to the customer wins. The more you know about the customer, the better you are at adapting to that customer.
Look at iTunes, iCloud, Microsoft Azure, or Amazon. They’ve been right in front of the customers, they’ve gotten bumps and bruises, they’ve gotten really familiar with the customer. To build those big pipes is a lighter lift. The carrier guys haven’t dealt with the end users, they deal with cloud providers. The companies operating closer to the customer have a significant advantage.
Where we see into industry in five years?
Hudson: We will see a normalization of hardware. As soon as you can see it in software, people are going to do it. We saw it with Sun. Normalizing the hardware, even if you get less advanced hardware, provides more agility. I can remember one weekend spending 26 hours rebuilding the OS of a Sun box because this version of Oracle had to run on this one specific Sun box. Specifics matched to specifics. Things have changed. We are moving to a world where I can migrate that instance to another server and not worry about hardware dependencies. The data center has seen a massive benefit. Even if it means you need 100 servers to replace a router, you can run other applications on those servers. You get Legos that you can rearrange almost any way you want.
Southwest Airlines runs the same plane everywhere. They only have to source one plane. It means they know that plane better than anyone else. They don’t have to worry about the details of all those planes. Southwest standardized their hardware, which is good, but not the best. It’s no 787, however this allows Southwest to focus on other things, like customer service. In many ways, Southwest is the airline equivalent of NFV.
Adding value through software and specialization is going to be a significant factor. Just look at an Apple laptop versus a windows-based laptop. They are the exact same hardware, but two very different experiences. I love my Mac. The only difference is software. Take that into the networking world. So, clearly if we can provide that same level of differentiation into the networking world running on commonly available x86 hardware with stellar performance we win. The networking world needs software that looks so good, you just want to lick it.