Friday, August 01, 2014

Podcast: Software-defined Networking with Red Hat's Dave Neary


Software-defined compute has been around for a while. Software-defined storage is newer but it's gaining visibility and market presence too. Software-defined networking is next in line. Red Hat's Dave Neary talks about what it is and why it's important for delivering capabilities such as VOIP and for replacing expensive single-function boxes.

Listen to MP3 (0:15:34)
Listen to OGG (0:15:34)

[Transcript:]

Gordon Haff:  Hi everyone. This is Gordon from the floor of OSCON 2014, so if you hear a little bit of a buzz in the background that's all the people here in Portland, Oregon at OSCON.
Today I'm here with my colleague, Dave Neary, who's part of our Open Source and Standards team. His primary responsibility these days is ManageIQ, which is our upstream community for CloudForms, our cloud orchestration and hybrid cloud management software.
As we talked earlier Dave, we're going to be taking things in a different direction for this afternoon. You've been spending a lot of time thinking about networking, which is always the last child, so to speak, to get the shoes when it comes to new types of functionality.
People think about compute, people think about storage, and then people are like, "Well, maybe we ought to do something about that networking thing, whatever that networking thing is, exactly.
You've been spending some time thinking about this, so maybe introduce yourself briefly, and introduce us a little bit to the context of software-defined networking and some of the things you been working on and thinking about there.
Dave Neary:  Having finished the open sourcing ManageIQ, I'm now looking more and more at the network. Which is, as you said, the next place where we need to make some progress.
Software defined networking, that's really interesting, the separation of the control plane from the data plane, the ability to define virtual networks inside and independent of the physical network topology.
I've been concentrating a lot of network function virtualization, which is taking these old, not necessarily old but single‑purpose proprietary boxes and turning them into virtual machines running on standard x86 servers.
Some of the concerns there, some of the constraints that we're working on in network function virtualization is that some of the network functions, things like VoIP services with IMS, or voice, data, video, converged 4G services with services like EPC, those are very, very sensitive to both latency and bandwidth.
Oftentimes, you need to be able to chain these things together. In terms of running them on an infrastructure as a service, a lot of the things we're looking at specifically through Red Hat and the NFV group and OpenStack, we're looking at how to make that possible on top of an infrastructure as a service right now.
Gordon:  Let's back up a moment here, because you've used a lot of acronyms, you've used a lot of terms.
Dave:  Oh, yeah. The telco industry...
Gordon:  I think that's only one of the things. I say this only half‑facetiously, that networking has been slow to permeate compute is because there is a different language.
Dave:  Very much so.
Gordon:  There are historically a very different set of concerns related to the telcos and the like.
Maybe for our listeners who aren't as immersed in this space, I think they probably understand you have compute, software‑defined compute. For our purposes here let's just call it a virtual machine, although obviously things like containers and the like would accompany it as well. Then you have storage. We can think of that as a disk and obviously there's block store and there's object, still fairly simple concepts. Now we need to connect these things to each other and we need to connect these things to the outside world.
Dave:  Right.
Gordon:  What does that software‑defined defining and connecting look like?
Dave:  The primitive in the network is a switch. What characterizes a switch is you have multiple machines that are plugged into the switch in different ports on the switch.
When you create a connection, the first time that you try to communicate between two machines on that same switch, the switch remembers where the packets ended up going.
Then they bypass all of the other ports on that switch, so you don't end up saturating your network. Now, with virtual machines you've got multiple virtual machines in each physical host.
You need to make connections between virtual machines running on one host and a virtual machine running on a different host that's potentially plugged into the same switch or into a different switch.
You have additional problems. You need to route the traffic between those. You need to create virtual switches inside your hypervisor node, so that basically the traffic from multiple virtual machines are handled separately.
All of this adds complexity. It adds complexity in terms of debugging. It adds complexity in terms of configuration. A software‑defined networking controller, an SDN controller, is a layer which in some ways abstracts away some of that complication.
It abstracts away the network hardware, the virtual switches that you're using, and it allows you to define your network topology at a higher level, and then goes away and it programs the switches and it programs the bridges.
It does what it's supposed to do to make sure that, in a multi‑tenant environment, traffic from one group of virtual machines is not seen by traffic from another group of virtual machines ‑‑ that you're separating that data.
That's just a very simple description of the software‑defined networking layer. A network function is a service which is provided on the network or to the network.
Something like, for example, a firewall would be a network function or an intrusion detection system, or, as I said, VoIP services, data services, and broadband access, for example. These are all network services.
Some of these are at the control layer and the control layer is where we define routing on top of your Internet, some of them on top of your network and some of them are on the data layer. In terms of actually individual packets.
Some of them are in the application layer. They're providing higher order functions that are independent of the TCP/IP or even data plane layers of the network stack.
These all have special needs. What you need from platform is you need the platform to provide those special needs and give them away to position themselves in your physical infrastructure on hosts which have the ability to satisfy those needs and the quality of service.
Gordon: Now, you as a system admin, as a system architect, you're interested in OpenStack. You're interested in essentially the software defined functions, moving from this, as we put special functions, single function, proprietary systems into a software defined system running on volume hardware, volume software.
What should I be thinking about now? What should I be getting ready for?
Dave:  I think the first thing you want to do is be conscious of the fact that in a data center the network’s important. I think we're aware of that.
Infrastructure as a service oftentimes is added to an existing data center in an ad hoc manner. You set aside a few machines and you run Open Stack on them and you see how it works, and then you maybe allocate more machines.
Before you know it, there's a problem and that problem is probably going to be somewhere in your network. You're going to have a virtual machine that isn't getting an IP address from the DHCP server which is running on an agent somewhere on another host.
Debugging that problem, if you haven't thought about your network and planned for how do you architect your network and what are you using there? What are the tools that are available to you in the network space?
It's going to be harder to make that transition when you want to you roll out infrastructure as a service into production. I think that's at the very highest level.
In terms of for specific verticals, specifically around telecoms, where network functions are vital that's the core competency of the teleco industry.
We're seeing several initiatives coming through ETSI, which is the European Telecommunications Standards Institute, I believe. The Linux Foundation, and OpenStack, as I mentioned, where we're really creating a world where adding features to the platform, which enable these network functions to be virtualized, which is going to enable the rapid addition of new services in that teleco vertical.
It's going to enable the reduction of costs, simplicity of management in those verticals, it's going to be really a game changer, I think in what's available in terms of telecommunications, VoIP, video streaming, all of these kinds of applications.
We're going to see very, very rapid progress in the coming years because of this move to NFV.
Gordon:  If I can summarize what I've been seeing out there; all this software defined everything is really is incredibly powerful idea both from an economics point of view and just from a flexibility point of view.
At the same time, to be realistic, as you say, there are complexities. We haven't even gotten into some of the complexities of the different types of network configurations you might have to set up there especially in the context of existing legacy data centers.
You can't just come in and throw away all your existing switches overnight someday because all of your applications, data centers are architected around this. So there's certainly a lot of learning and a lot of complexities associated there.
At the same time, you really can't just half way software define things. If you only use software defined compute, or you only use software defined storage, or some combination thereof, and just say we'll keep on doing networking the way we always have, you'll still get some benefit, but you don't get nearly the benefit if you do the whole thing.
Dave:  I think what it comes down to is, why did we move to software defined compute, software defined storage in the first place? And it's because, what were we doing before?
If you wanted to provision a host, if you wanted to provision a computer, it took hours, days, weeks.
The move to automation, the move to scripting, the move to statelessness, the move to defining the process by which you create an environment allowed you to go faster.
It allowed you to innovate faster because you are no longer in the situation where every time you wanted to deploy a new version, you cross your fingers and you tell the team that they're not going home that weekend because they're going to spend three days in the office making sure the thing works.
When you make your deployment cycle shorter, you increase innovation. You allow yourself to adapt faster to market needs.
If you want to add a switch, or if you want to add a host to the network, that's the bottleneck. That's the place for you actually have to pick up a phone and call somebody, and have that done manually. And all of the scripts are custom scripts, and all of the switches are configured in a very particular way.
Automating that is going to bring the same benefits to the network engineers that it brought to operations engineers over the last five years, and which is now becoming a mainstream operation as you want to reduce your deployment cycles to the minimum possible.
You can concentrate on innovating in your development, and concentrate on high quality operations at high availability, high visibility, situational awareness.
We want the same kind of thing in the network, and that's what this moved to software defined network promises.
Gordon:  I think you probably allude to some of the organizational changes that this will require in many cases as well, because I've seen similarities before, for instance with some of the Blades first came into data centers.
It was a naive assumption that these separate groups could just come together in a single, in this case server converged hardware platform, and it would all work happily together.
Of course, that doesn't just automatically happen, so that's something that CIOs and their organizations need to think about in the context of this software defined networking as well.
Dave:  Sure. One of the four legs of the DevOps movement is culture. It's the most important one, and really, if you're trying to develop, if you're a web application developer and you're moving to the web, you're moving to the cloud, there is a cultural change.
There are a number of things that you have to do differently. It's not just an operations problem, it's also a development problem.
In the same way, network operations, by moving to software defined networking is not just the network engineer's problem. It's also going to be part of the development problem, it's also going to require cultural change throughout the organization.
Gordon:  It's not that it's meaning "Oh, we don't need people who understand networks any longer." Anything but, because you can't just say "Well, the networking is Joe's problem, and I don't need to worry about it." Storage, compute and networking become everybody's problem.
Dave:  Right. And in the same way that DevOps has not gotten rid of operations people. Good operations people are more valuable now than they have ever been.
Software defined networking is not going to get rid of good network engineers. Good network engineers are just going to spend all of their time doing value‑add work instead of undifferentiated heavy lifting.
Gordon:  That's probably a good point to leave off on. I think one of the lessons here is, software defined everything really brings everything together in a sense.
Whether we're talking about hybrid cloud management, whether we're talking about organizations and cultures within IT organizations, it's going to be harder as we move forward to treat things like these little islands that don't need to worry about what everyone else is doing.

Even as we talk about things like micro services and so forth, which aim to isolate things to a certain degree, there's still a certain common culture and a common set of responsibilities that people need to think about.

No comments: