I recently had the chance to sit down with Rob Sherwood, CTO of Big Switch Networks to get his insight on whats hot with SDN for 2015.
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.