Big Switch Networks CTO Rob Sherwood on SDN in 2015: The Time is now

The interview can be seen on my youtube channel, OpenNetworking.TV here, and you can also view the transcript below:

[Art Fewell] Welcome to OpenNetworking TV, this is the CatchUp. I'm your host, Art Fewell. Today we are going to be catching up with another one of the founding fathers of the SDN movement, I hope that's a fitting description, Rob Sherwood of Big Switch Networks. Rob would you mind sharing a little of your background

[Rob Sherwood] Thanks first for having me. I actually have a background as a campus network admin. I was doing network security and network administration back at the University of Maryland 15 years ago. Then I ended up going to graduate school, doing the network research, network security angle for my PhD. I actually ended up at Stanford as part of the Clean Slate program where SDN was really a thing. I was paid by huge telecom, it was also kind of a post-doc for me there. I was just in the group that was doing OpenFlow. I actually joined with Guido Appenzeller, the future founder of Big Switch. He was actually my manager. We were just a couple of grad students and a couple of post-docs doing some funky things with networks. Later, SDN came about, and Big Switch came about, and Nicira came about and all sorts of things happened. I've been involved basically ever since.

[Art] What's your takeaway, what's it been like going through this experience and watching it all mature

[Rob] I've said every year for the last six or seven years, next year is going to be huge for SDN; and actually I've been right. Actually even after seven years of it, it's getting a little bit scary. Practically speaking, there's a bunch of things that I think are really going to be different about 2015. The idea of disaggregated switches, bare metal switches that I as a software vendor can actually write my own software on the switch and then turn that into a wholesale SDN solution, I think is really coming to bear and that's really helping accelerate the industry. I've been talking about this for a couple years now, that there's this inherent problem that A; building a good SDN switch side implementation is both technically hard and the people whose job it is to do that are economically disincentivized to do that. We're asking them to throw away, in some cases 20 years' worth of software investment to implement this OpenFlow thing. That's just, it's just not going to work.

The incentive in the right place for a company like Big Switch, we actually now produce our own switch operating system. We have Switch Light, it's built into all of our products. We can tune the SDN stack the way that we want it to be and actually produce good commercial products for people. We're really starting to see a lot of evidence of that and in I think 2015, it's going exponential so I'm pretty excited.

[Art] We have this challenge in that we're expecting new things to come to us in the way that they kind of always had. Or at least that's what we're used to. A lot of the new things are coming in ways that we don't expect. I think a lot of the ways that people will end up consuming SDN is actually going to be very different from past technologies. Some people will buy and SDN switch and deploy an SDN switch themselves as a typical enterprise customer. I think a lot of the ways where consumers are going to benefit from SDN, it's going to fall in behind the scenes maybe in some cases and be all over the place. I'm curious about your insight on that.

[Rob] Absolutely. I think you would know, Big Switch did a pivot about two years back. It really is exactly to the point that you're talking about. Which is SDN, before the pivot, we were treating it like a product. That is that, if we build the controller, then you the consumer can build applications and do the software integration to make this happen. Basically the experience that we found and I think the rest of the industry is slowly coming around to this is; very few consumers actually want to invest in software engineering and invest in the very difficult integration problem of trying to build up their own SDN solution. That's the domain for the Googles, and Facebooks, and Microsofts of the world but not really for even the vast majority of Fortune 500 customers.

What we're pivoting to and what we did two years ago and we're really starting to execute on this now, and it's exactly what you said. Which is, SDN is a technology where we provide the whole solution. We provide user experience, the application, the controller, and the switch side operating system so that you, the end user, don't have to invest in development teams, trying to figure out how to automate progression tests and a whole bunch of things that enterprises just traditionally aren't interested in doing.

[Art] Everyone wants the benefits of SDN, and I don't think they care exactly how those benefits get implemented. What they really want is an ability to push the easy button I think. It doesn't necessarily have to be all that easy, but I think today we're in this environment where we're looking and saying, "Wow, look at this. Some Google like company just implemented these really cool features I want. Oh, and by the way they're investing hundreds of people and millions of dollars to be able to accomplish that." There really hasn't been a good middle ground. It was like you either go really complex in trying the custom Linux OpenStack type of thing or you're back to commercial off-the-shelf. I think what you're describing sounds like the right fit. A way for people to get these benefits but not have to do their own solutions engineering and figure out every step.

[Rob] That's exactly it. The short, short version of what Big Switch is trying to do is trying to learn from what we call the hyper-scale players, not even the Fortune 100, but the Fortune 5. What is Amazon doing, what is Facebook doing Then trying to figure out. It's almost like treating Big Switch like the company's outsourced development firm. We will be the Google engineering team for you so you don't have to hire them. That means the technical challenge that we solve is actually harder than what these companies are doing. They only have to solve it for one use case or a couple of use cases, but we have to solve it for all of them. The end result is we actually end up with a more robust solution, something that takes account a lot of use cases. It's actually pretty exciting, customers are very responsive too, "I want to do what Amazon does, but I don't want to have to do it the way that Amazon did it." I think that is resonating quite well.

[Art] I don't think that the pace of innovation is going to slow down. To me it seems, the inevitable result is that there's going to be a lot of innovation. If you have a business that their job is making widgets, they make toilet paper rolls, I don't know; that company shouldn't rightfully be focused on engineering the most efficient data center in the world but they should be able to get that performance impact. In the past, it's never really been possible. I think today with engineered solutions, and especially when built on the new web-scale SDN framework; it really starts to introduce that type of possibility.

[Rob] The other side of this, which people aren't talking about as much but I think is really important, which is to say in the Googles, and Facebooks, and Amazons of the world; they are not networking vendors. They're only doing this because they feel like they have to. Which is to say, the incumbent vendors that they would traditionally buy equipment from are not meeting their needs. I think more and more people are finding that.

[Art] Out of all the different open networking summits, there were tons of really big light bulb, ah-ha moments that has happened in all of those. I think possibly the biggest of all those was, I think it was with the first, maybe the second ONS where Google got on stage and was saying, 'Hey, we've asked every single vendor,' all the vendors by the way, who happen to be sitting there in the room, which is just hilarious. 'We asked every single vendor to help us build the type of switch we wanted to build and every single one said no. We had to go build it ourselves and that was really great because we're getting over 90% efficiency on our WAN and we are realizing all these powerful benefits that have been proven since to really be substantive in their strategic differentiation.'

Which is interesting, because networking for so long is plumbing and now you've really in this past year, you've seen some really big articles from Facebook and from Google that have really attested to just how much strategic differentiation that Facebook, and Google, and some of those other companies have been able to get specifically from the network. Which I think is a very fascinating point.

[Rob] What people talk about and when I pitch people the benefits of our software, I actually tell them, "the third most interesting thing is actually the capex", "Well, isn't that what the main point is" "No, no, no." If you talk to most companies, capex is actually one of their lesser problems. One of their bigger problems is the opex cost and their biggest, their number one problem is actually the network is actually holding them back. If you talked to a large bank who makes money by deploying new applications. Some analyst somewhere comes up with some idea that says, "We could do loan refinancing this completely different way. Let's do a web application that has a pop-up. When our users log into our bank account, it'll pop up saying 'Hey, have you thought about refinancing your home loan this way' To build that application takes months and the holdup there is actually their network. The thing that makes the banks money is limited by the network. Yes, capex is important but it's not as important as opex. Even opex isn't as important as doing more of the thing that makes you money.

[Art] I don't want to get too detailed but what is it about SDN in that context We've got a lot of, especially compared to how we did traditional networking, we used to have to stick an access list on a physical switch port somewhere to be able to control policy in a way that was very not connected at all to the application provisioning. That's changing, right That's very different than in a Big Switch network, how does that work

[Rob] There are two big things. One is, in traditional ways people have to do box-by-box provisioning. That is, if you want to set up a new collection of VMs somewhere on this side of the data center and somewhere on this side; you will actually have to log in to every box along the path and update that configuration. You better hope you don't make a subtle mistake because you might have to then log into all of those boxes again to try to figure out what it is. Having the automation to do, to move from box-by-box to an automated setting, that actually is a strict improvement both in terms of speed but also in terms of if you've got a computer actually making these changes for you, it's less likely to make a mistake.

[Art] If you look at what's happening with OpenFlow today, with OpenFlow in the physical hardware. There's a lot of people saying, "Well, what if I just did an API here rather than using OpenFlow, maybe leave the control plane." I think there's one point in there that's very related to the automation but maybe a different level of sophistication. That is, first we need the automation because when you move virtual machines around, and we deploy virtual machines, or other applications we need that policy to automatically follow that and so OpenFlow can facilitate that. I can do that through a number of other means, but I think one of the things about OpenFlow that's really key there is understanding the current exact state of what configuration and what policies are following that virtual machine or that application around at a given time. I think as we get into this app-ifying of networking, having the current state it really becomes critical.

[Rob] Absolutely. I've definitely said publicly a number of times that I think OpenFlow is very valuable but it's also, it's a technical solution to a business problem that we've had. This is to say, if you flashed back 7, 8 years when I started working on this; the idea that you could actually buy a switch and put your own software on it and there was enough hardware documentation and enough open source software to make that happen, it was actually, it just wasn't even on the table. The next best thing that we could hope for was a remote API into the low level forwarding plane on the box. That was how the OpenFlow was designed. Fast forward to today, we have things like, if I could put a small plug-in for my open source project, Open Network Linux.

[Art] Please do, yes. We're big fans.

[Rob] You can grab something like that and either deploy our OpenFlow, or write your own OpenFlow, or write something else. We have people using it creating custom protocols. OpenFlow, the concept is extremely useful, which is let's expose the raw channel memory to an RPC. OpenFlow as a specific protocol, whether it's the ONF OpenFlow or just something else that does that same process, I think as the open source evolves, as things like the Open Network Linux take off, I think that specific detail will be less important.

[Art] There's all this language challenge around SDN. What exactly does SDN mean In some cases it is only OpenFlow, in some cases it's only OpenFlow in the physical hardware, or other people define it as these really broad things. From my perspective, that all started from the first Open Networking Summit when as soon as SDN looked like it might be a hyped term, every vendor out there came back and said, "What we already have today is SDN. That new stuff coming out of those star-eyed visionaries over there in the academic space, that's not really SDN." What I saw is kind of as a result of that, there was a little doubling down on "No, OpenFlow is SDN."

At the same time, from the first ONS it was always very, very clear; SDN is not OpenFlow, OpenFlow is not SDN. What we're really trying to do is change the industry and introduce the opportunity to have all different types of new thought and figure out what works best in OpenFlow will be part of that. I think, from my perspective, that seems to me to be one of the sources behind some of the terminology confusion. I hope today that that's getting a little better. I was just wondering if you saw similar currents over these past few years

[Rob] Absolutely. It's worth going back to the article where the term SDN was first coined. I was actually interviewed for that article.

[Art] Yeah, yeah, the MIT Tech Review. I remember that one.

[Rob] Basically the thinking from the other side was, "Well it's a little bit like software defined radios because you can maybe change some of the networking things so I'll call it software defined networking." I always tell people the term started out imprecise and didn't really get much better from then.

[Art] That's interesting that you mention that because I have been thinking the opposite, right Software defined radio access network - I thought they pulled that term from SDN, fascinating thing to learn.

[Rob] The thing that's a little bit confusing is that networking has always been about hardware and software in combination. If you look at how a router or a switch is made, there's a lot of absolute dedicated hardware there in terms of an ASIC or different types of forwarding memory and what not but there's also a lot of software. If you went to a traditional vendor and said, "Okay, we're now going to make the network software defined." They're like, "Well, we have a huge software team. We actually write a lot of software, what does that mean" The definition that I like and the one that the ONS supports, and the ONS supports it based on that is there's actually a controller involved. There's a remote controller making and receiving calls down to the individual switches. What those RPC calls are, are they OpenFlow, is it OpenFlow like I think that is almost an irrelevant implementation detail. That is the idea of providing some sort of abstracted view of the network via a hierarchy.

[Art] The interesting thing about that definition is, is I just wonder what is the line between management, automation, orchestration platform and a controller

[Rob] There's a critical difference, I apologize if I get too technical. Much of those configuration things will actually say configuration parameters in the individual switches but aren't actually ... Those might indirectly affect forwarding decisions, whereas in my mind a controller actually affects the forwarding decisions directly by actually populating the forwarding memory directory. The analogy that I always make is if you look at a multi-linecard switch, these are the big iron boxes that everybody has. They almost always have a couple of supervisor modules, some linecards, and some fabric backplanes. If you look at the protocol between those supervisor modules and the linecards, there actually is a protocol inside that box for if a new route comes in, how do we program the linecards. I call that protocol closed flow because its just like OpenFlow, the supervisor cards are just like controllers. It's the idea that you could do this in at least a somewhat open way, that's the thing that's fundamentally different. It's not architecturally different, it is just that something that was closed is now open, that's the difference.

[Art] I think that's, especially for the people who are just getting into OpenFlow, or just getting their first hands on experiences with them; that's a really powerful analogy. In networking, we are perhaps the most risk averse of a lot of people who work in IT because everything goes down when the network goes down. No amount of high availability you build into your important app matters when the network is down. We are familiar, though, if you've been in networking with these big chassis switches, we've used them a lot for a lot of years. If you look at like you said in your point how those work, you have the forwarding decisions and essentially the forwarding database managed by the supervisor and it, especially in modern chassis where you're using distributed forwarding it's going to cache essentially the decision engine on each individual line card. That line card goes ahead and makes the forwarding decisions assuming it has an entry.

When you take OpenFlow, it's the same thing minus the chassis, just like you said. I wanted to highlight that point. Anyone who's feeling uncomfortable with the idea of OpenFlow, it really is a very comfortable dynamic. It's a very similar type of ... There's a lot of new things about it, but there's a lot of comfort points and ways that's it's similar to traditional architecture as well for those getting into it. Do you have any other guidance for people who are just getting into OpenFlow to come to wrap their heads around the significance and how it'll impact their operations

[Rob] Another big one that people talk to me about is support. People get a little bit concerned about support with this disaggregated model where you might buy the hardware from one company and the software from another. I tell people, "Talk to your server people. Ask them how they buy their servers." The server people will have the same problem and it's not a problem. That is to say, you can, if you want a single vendor you can to pay for that. If you want to buy both from the channel, you can do that. You want to buy it from a reseller, you can do that. If you want to buy direct from the hardware manufacturer and have them support the software, that also works as well. Everyone is running around saying everything is different, the sky is falling. I actually spend a lot of my time trying to say, actually, this is pretty much the same thing we've been doing already just only networking is a bit different.

You mentioned briefly, everybody is worried, network engineers are very conservative because when the network goes down everything goes down. That is the strictly the function of the extremely tight artificial coupling of how the software is set up. If we actually build networks the way that we build distributed web applications, we wouldn't have that problem. That's a lot of what the Big Switch is trying to do, is actually build these things a little bit more like distributed web applications so that if you lose a piece, it's not that big a deal.

[Art] That's kind of core to the spirit of the architecture. It seemed like for a long time people would try to engineer individual components to never, ever, ever fail no matter what. Somewhere along the ways we got into web-scale and we realized individual components are always going to fail. We have to build an architecture that can tolerate a lot of failure and still keep on running without a hitch.

[Rob] This is exactly the same transition that people went from in moving both from mainframes to PCs, and really from supercomputers to data centers. If you look at the architecture of a modern data center, people are starting to build them effectively exactly like supercomputers. People talk about things like pods, and that would be one supercomputer node. The idea of moving from hardware that can never fail to hardware that we know is going to fail with some probability unless we write better software, it is a tough pill to swallow but it's one the industry has swallowed a couple of times. I have a lot of faith this is going to be reality.

[Art] In 2015, SDN is going to become a lot more accessible to a lot wider range of audience because solutions like Big Switch are becoming more mature, easier to adopt. You've got other things that are finally really becoming within enterprise grasp this year, NSX for example, and other NVO solutions. I think this is going to be a year where a lot of rubber hits the road. I'm curious, what do you expect to see from the fallout of some of that stuff this year

[Rob] I definitely think if you look at things like the traction that NSX is getting, you'll actually see a fairly big tussle in the underlay space. It's actually a use case that Big Switch is looking at fairly closely. We provide essentially a managed physical fabric that you can overlay over the top of us, so we can actually be the underlay to NSX's overlay. That's an interesting space. At the same time, if you look at some of the recent work that they've done, OVN they're calling it, so they're actually seeing a commoditization push that's already happening in the overlay space where you get folks like Midokura, you've got folks like PLUMgrid that are open sourcing and actually really trying to go after NSX in the only way that they can. Which is, let's build it more open.

[Art] OpenStack today largely uses a non-SDN framework. There's Neutron available, a lot of production implementations aren't using that. If you go to look at Neutron, I think there's this thought like, "Hey, I can go get OpenStack and I can deploy open source SDN with that." That's not exactly a reality today particularly with overlays. If you look at what's available from an open source overlay perspective, it's pretty much open vSwitch, which doesn't have much of a framework yet, they're working on that. Then you have some things more comprehensive like NSX and Plum Grid but there hasn't been this open source complete NSX like framework for NVOs. I'm familiar with at least three different products that are going to release NVO and physical OpenFlow as well this year for open source with OpenStack communities. That'll be an interesting inflection point once there are more NSX competitors of similar breadth available open source I think this year.

[Rob] I'm really happy with where Big Switch is from a products and a positioning standpoint because of that. I think the whole NVO market ... Big Switch actually historically, this is pre our pivot, had an NVO product. The joke is, there's an argument about how big that pie is. I am actually convinced it's not as big as people think it is. It's clear that there's going to be a lot more people trying to get a bigger slice of that pie. That's why I'm happy that Big Switch went to the physical fabric side.

[Art] If you look at VMware, what is their biggest strength Their biggest strength is that everybody in enterprise and their dog has vCenter sitting in there waiting to be potentially upgraded. If you're VMware and you're thinking, "I want to sell private cloud technology to all these people that have this stuff." It's not really necessarily in their business interests, per se, to say "Hey, everybody, to buy my next piece of software all of you need to go out and buy an entirely new, and different type of physical network to go underneath." On the one hand, there's a lot of technologists who believe in NVO technology very passionately and I'm not slighting the technology at all but I do think there is something to be said that for certain vendors there definitely is a business interest there where using an overlay SDN versus using an SDN underlay could potentially conflate their motivations.

[Rob] Absolutely. Now at the same time, if you look our typical customer. They're actually, they've got five to ten new projects in the pipe that all require new hardware, like new switches. We're not doing rip and replace anymore, take your legacy stuff, leave it where it is. Our stuff will get slotted into the row next to it and because they've got a Hadoop project, an OpenStack project, maybe they're doing something with VDI or something like that. It's not so much a rip and replace, and honestly, that's just not a reality of modern data centers. Modern data centers the lifetime of years is probably five years. There's so many people who are expanding so quickly, throwing out all their gear that's 3+ or 5+ years old, depending on the company. I actually don't think that deploying new hardware is actually a significant problem. As long as there's interoperability, you can toggle from the old stack to the new stack, everything speaks IP, There's no problems there.

[Art] As open networking takes hold, it looks to me like innovation in servers, innovation in networking, these manufacturers are really wrapping their hands around them now. It's not just, I am a networking manufacturer. I am a server manufacturer. I tend to think if I buy a new server and network combination today to try and get my most efficient private cloud combination that I can; three or four years from now I'm probably just not going to upgrade the server. Due to the pace of that network innovation that's happening, we're doing a 100 gig and soon can do 400 gig and not to mention the other feature capabilities. I tend to think that we're going to see a lot more of this type of architecture where this year I'm going to deploy this private cloud and maybe a few years from now, or as we get into the next paradigm we'll do the same thing again. We'll stack up another new one. Do you see that as an architectural trend

[Rob] Probably so. So much so that we started running with the term we heard from our hyper center friends, which is a core cloud design. The idea that you have a routed core which is your ingress and egress to the data center, that lives through the lifetime of the data center. That might be there for ten years or whatever that number is. Then you have a lot of pods hanging off of it. A pod is, think of it almost like a row, but it's a collection of compute, storage and networking gear that's all certified to work together. The biggest selling point of the architecture is you've got a team whose job it is to constantly be working on the new pod design. They'll have the pod design B5 and while B5 is the latest greatest, every time you need a new project, you'll stamp out another pod of B5.

Then while the team is working on it, they'll figure out, "Okay, what is the next best version of compute, storage and networking that ties this all together What is the next design" Then when B6 comes in, they'll stamp that out every time they need a new project. This is kind of multi-use, multi-purpose architecture so it can have lots and lots of workloads in a pod. The real value is actually in the automation. If you were willy-nilly picking up, every time there's a new rack deployed and you've got new servers, and new storage, and new network then the automation of that is horrible. When you actually have some homogeneity, which is to say I know this is pod B4 then that's much, much less complicated to manage. That's where people are really seeing, both, the value from a purchasing cloud standpoint as well as from an automation standpoint. There's now really a huge shift in how people are building data center.

[Art] Let's say you're an enterprise customer and you're looking at deploying private cloud technology. You want to have things that are automated, and elastic, and what have you. What is your take on physical OpenFlow and physical hardware versus NVO If I'm a customer, do I use both and they interact in some place Do I choose one or the other What would your advice to customers be around that

[Rob] Well, there's two dimensions which is, one is, what is your workload Depending on your workload, you can probably virtualize it but you may actually have some physical hardware as well, for example some database servers and things like that. Most of the customers that we talked to have kind of a 70-30 split, which is to say 70% of their workloads are virtualizable and about 30% are physical only for various reasons. Understanding your workload is the first place to start. Most people end up with some sort of mixed workload or can't know ahead of time. The answer is you would probably need both. The other side of it, it's not really an either/or decision. Which is to say, if you have and NVO solution, the packets don't match what they're getting from one vSwitch to another you need a physical network there. If you're going to need a physical network, the question is, even if the policies are maybe not that complicated, having a single point of control across the 40 switches is still easier, and cheaper, and better.

[Art] I am a fan of NVO technology, don't get me wrong, I don't have too much an opinion on it one way or another. Sometimes I think like, would the world really be that much of a different place if Betamax had won instead of VHS at the end of the day I'm not saying they're the same quality of technology. I was thinking it's probably possible to make either one work if that's what the industry chooses to put its weight behind it. I think what I'm waiting to see is one going to take over from the other. To my point, one thing that seems apparent with OpenFlow in the physical hardware is, yeah, today it hasn't been to full maturity yet and I can't just go out as an average enterprise and go buy a plug and play solution [for all use cases]. That hasn't happened yet but that doesn't mean that OpenFlow technology won't ultimately create that. Once I have OpenFlow technology in my physical hardware, is it that stuff starts to become overhead that you don't need anymore

[Rob] Let me push back a little of what you said. We've been shipping OpenFlow based solutions that really are plug and play for the better part of two years now, particularly our Big Tap product. That really is a drop it in and it goes on the side of your network very safely. It's a very safe and easy thing to do. We're getting a lot of traction with that. If that builds on OpenFlow, we've been deploying that for a couple years now. We've been deploying our big cloud fabric product since September of last year. We're getting a lot of traction with that. Actually our new release, if I can put in a plug for that, is coming out this month and it's going to actually support hardware from Dell so we're really looking forward to that. For 2015 it's going to be very interesting to see now that we've got some real initial customer traction and we've got some real products that will start to just connect all the dots and show the hockey stick curve. It'll be very interesting to see what happens this year.

[Art] The next thing that I wanted to ask is really about Docker. That's one of the big new fairly uncharted territories. Linux containers have been around for a while, the networking capabilities within Docker aren't particularly robust yet [This call was recorded prior to the Socketplane acquisition by Docker]. There's a lot of startups trying to tackle that and I'm certain it's on your guys' radar and you're working on stuff around that. I'm curious, what do you see, how is Docker networking going to hit the market and what evolution needs to happen there

[Rob] What's fascinating to me is, Big Switch has a virtual switch and we'll be shipping it later this year. The virtual switch literally cannot tell the difference between a VM on one side versus a Docker container. The way that the Linux virtual Ethernet works on that type of thing. From a networking perspective, Docker doesn't really change much. You still need something that looks like a vSwitch, with the functionality that a vSwitch has, but better. It actually increases, if you want to think of it in these terms, it's kind of the VM density so you can actually get much higher density with Docker. You can spin them up a little bit faster, it's a little bit lighter so maybe there's a little bit more churn on that side but a lot of the fundamental policies don't' really change. This is to say, most people treat a collection of VMs as an application, Docker just lets you do that faster and cheaper. All the policies and the user experience and the management objects and things like that, all of those things will stay the same.

[Art] Well, that's great. It just seems ... I think that's also really, particularly for the enterprises, if you're at the leading edges of web tech, you're going to see a lot more of the warts of the technology, if you will. I think, particularly for the enterprise, it seems to me that things are getting really streamlined for Docker to where pretty quickly the management and orchestration stuff that surrounds VMs today will probably be equally applicable in most systems for Docker containers tomorrow. Does that sound about right

[Rob] Yeah, absolutely. It's, honestly, I definitely see the benefit of the data center industry converging in terms of storage, compute and networking and all of these things but people are still learning the skill sets. Honestly, I think it's the case that companies are coming in to solve specific problems and are not necessarily aware of the problem from the other side, the facts as it were. Being able to bring the solutions wholesale from the other side of the fence I think will really help accelerate the adoption of these types of technology.

[Art] If you're a business, you need to take part in this internet of things thing, pretty much no matter what product you make you probably fit in that somewhere. You need to be aggressive, you need to be innovative and it seems to me open networking, SDN is really key to that. I'm curious about your thoughts

[Rob] Absolutely. Honestly, that's actually what gets me up in the morning. That's really what motivates me, which is you look at the explosion of applications that happened when all of the sudden people could write apps for smartphones, or even further back when people were moving from mainframes to PCs where people could invent their own programs. You're actually enabling everybody in the world to become an innovator here and it'll be fascinating to see what happens. At the same time with internet of things, there's kind of unprecedented security issues. The idea of having my toaster or my garbage disposal online is a little bit scary.

[Art] If I could interject something there, on that point about the toaster. At the consumer electronics show this year, now the Roombas instead of just being a vacuum, they're remote controllable and have a camera in it. I don't know if it's the Roomba brand, but most of the ones at the show floor that were similar, the robotic vacuums they have a camera and they're meant to be like home security system integrated now. When you're at the office, I can tap into my Roomba, drive around my house, view everything in my house. It starts to really, that's even still a very, very small example but I think it highlights your point about the security implications. Any hacker can now just not get into our personal information, they can come into our house; that's a problem.

[Rob] Absolutely. Security is kind of a big tent but what it translates to into more specifically what we're talking about is more and more complex network policies; who can access that camera during what time of the day, on what networks, and things like that. I think those have become the ... As those security policies compound, that's really what makes network management so complicated and that's what I think really forces us to network automation. I think that's really the only way to produce solutions to this.

[Art] I think it's a great segue to end it there. The thing about this internet of things, this realization that every business no matter who you are, you're going to be part of this and to win in it and to hopefully win these 50 billion new devices and 5 billion people that are going to be coming on the internet over the next few years. There's a lot of opportunity to win in it. I think open networking, software defined, modern web-scale architectures are the only things out there that really give you that flexibility. Big Switch has I think been the, you've been really the first and the main one that really stuck to the core of OpenFlow. I think you have a great solution. Look up Rob, I'll put the links up here to follow him. Thank you, Rob, really great advice for the audience today. It's been a great conversation.

[Rob] You're absolutely too kind, but thank you so much for having me.

(www.networkworld.com)