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.
