 Live from Vancouver, Canada, it's The Cube at OpenStack Summit Vancouver 2015. Brought to you by headline sponsors EMC and jointly by Red Hat and Cisco with additional sponsorship by Brocade and HP. And now your host, John Furrier. Lift off. Okay, we're back live here in British Columbia in Vancouver for OpenStack Summit. We're here for three days on our third day of Cube covers. Cube is Silicon Angles flagship program. We go out to the events and extract the signal from noise. Our next guest is Colin Dixon and Tom Nadu from Brocade Distinguished Engineer Engineers. Guys, welcome to The Cube. Thank you. Love The Cube. Great to see you guys again. Obviously Brocade making a big splash here at the event. A lot of things kind of on the horizon. There was talking about modern, the shift. Kind of open daylight has got a lot of, you know, a lot of light on it right now. And the networking stuff is hot. Certainly everyone's here talking about it. Cisco's even here pumping up their stuff. What's going on right now with you guys with OpenStack? I want to get the story out there because there's some history around NFD, super hot, you know, fiber channels, rock in our own. Brocade's in a good position in all this. What's under the hood? What's powering you guys right now? We're up to our eyeballs in OpenStack and open daylight. I mean, you know, part of it is just getting the two things together. And part of it is, you know, adding to the two parts and making it better. And we were just talking about this. A lot of what's driving that is NFV these days. NFV, service function chaining, all of that stuff. And, you know, getting OpenStack and Open Daylight to work together, which does work. Making that stuff happen is kind of what we spend a lot of time doing. All right, just talk about the integration. Why is it relevant right now? Why is it so hot? I mean, Open Daylight's been around for a while. You guys have been doing a lot of work there. Open source is booming. OpenStack is booming. What's the integration points? Why is it important right now? So there's the classic reason why it's important, which is that, like, you know, frankly speaking, getting the network to host virtualized workloads is probably the hardest single piece, right? You know, virtualization of compute and storage, that's been pretty easy. I mean, so there's sort of that story, which is just, hey, we need something to actually control the infrastructure and get us virtual networks. But I think the really more interesting thing is sort of inverting that, which is, everybody thinks about OpenStack on top and Open Daylight underneath, right, networking services. I think NFV is changing that story and saying, actually, Open Daylight or a networking control platform is going to sit on top and you're going to be using OpenStack actually as a resource provisioning layer for your network, not as the network servicing OpenStack. And that's where it is that I think Brocade has a lot more talent and a lot more investment. We have people working on Tacker, which is basically the particular subset of OpenStack that's going to be deploying those service VMs. We have people that are making this work and we're learning a lot from getting it running in production with major customers. And so- That's a great point. Let's talk about that inverting concept is what that brings up a kind of mindset shift in the mind of the architects out there right now. So, one of the things that's come up here at OpenStack is this notion of layers, infrastructure as a service, platform as a service, software as a service, which is a nice, lightweight way to framework to look at the market. But that's not how people or customers are talking. They don't say, I need a platform as a service. No. It's a service architecture. So what's going on is that each customer will have a different view of how they want to plug into services, whether it's microservices or whatnot. So that kind of flips things upside down. If you're thinking about that way, then it's a complete broad landscape of services. So explain more about what that means from an architect standpoint, because that's where the action is this year. It's architecture. Well, like at a top level, I call it plumbing as a service, right? I mean, it's really, it's connecting, like Colin was saying, connecting the compute things, which actually are now containers and that whole thing that are running various kinds of workloads, but workloads are services ultimately that you're stringing together. And the trick is stringing them together in a way that is operationally efficient, makes sense and works. And is maintainable. I mean, the reason we layer things isn't because we like rigidity. It's because we like, it's because it may, it constrains the problem to be able to think about it, maintain it and service it. But the idea that there is one canonical layering that's going to work for all your customers is just crazy. We're seeing that, you know, the telcos are going to want to layer networking at the top because that's what they do and everything is in service of networking. And that's not the way Google is going to do it because Google is not a networking company. They're going to put, you know, virtualization and services at the top that are compute services. And the ability to take these open source solutions, remix them and move the layers around and sort of make sense of this broad swath of services and to turn them into individual layers for use cases, that's where I think the majority of the value and the money is going to come in. That's the service, it's architecture view. You're looking at it. That's how customers are talking. You know, they look at their workloads and they'll design it around that, right? That's what you're saying. Yeah, exactly. All right, so talking about a concept we were talking about earlier in theCUBE around, you know, people stringing stuff together, you mentioned that, cobbling things together. Whatever people want to call it, you know, there's been a tinkering model of OpenStack where it's evolving real-time, hardening a bit, you're seeing all the results. But people have been cobbling together in open source for a while, whether it's Memcache and MySQL, all this stuff, Lamstack stuff. So what happens from that is brittle networks or infrastructure becomes brittle. So making it more microservices has been a big trend. Can you guys share your vision on that notion of, okay, you can cobble stuff together, get things up and running, but to build a hard and scalable network and app workload environment, you got to make it less brittle. And how do you make it more cohesive? Well, part of that is what we spend most of our time doing is building a commercial distro of open daylight, right? I mean, that is harder than it looks. That's not just the repackaging of some upstream things. And most of the hard problems aren't in what you think of as open daylight. The hard part is not getting open flow or net conf to work, right? That pretty much works. The hard part is getting it to deploy consistently in a way that's flexible across the operating system you're deploying in, whether you're deploying it on bare metal, whether you're deploying it into VM, whether you're deploying it in order to manage a row of a single row in a designer or deploy it to manage five servers, deploy it with open stack underneath it, with open stack on top of it. And so figuring out what the deployment models are, writing the glue code around it that is actually flexible enough, and stable, right? I mean, that's really what I spend a lot of my time. I think that's where Brookings spends all our time. Talk about the vision with open daylight and the technical direction you guys are seeing in open stack. What is your vision for the technical direction within open stack? Given the work you guys have done to get stuff, because the demand curve right now is way past POCs. It's on the path to maturity with open stack. There's a lot of kind of in between the toes details that are really unique and small, but big. But big, yeah. So talk about that. Cool. I mean, seeing the people here, you know, Walmart was here talking about this, Comcast, they think of the last one, it's talking about, I mean, using open stack on a very large scale. I mean, I think we're past the point where people don't believe this thing will work on a big scale. Now it's a matter of refining it and doing things. So the direction I see things going in is kind of where we're focusing a lot of our efforts, which is around, again, combining the two together and making the whole better. Making cool things that can come out of those two things. So for example, like Colin was saying earlier, different ways of orchestrating different services, microservices, service chaining, and riffing on what's there today and remixing the things a little bit. And I mean, even yesterday when I was on stage with Kyle Mestri, who's the Ptl of Neutron, Kyle was talking about he wants to, basically he would like to kick out the reference implementation from the mainstream thing and turn it into just an API, because frankly speaking, there are enough real implementations of that that take networking more seriously than what's currently there and actually deliver the value that people are looking for. And so I think that that's, it's been exciting to see open stack realize that there's a huge amount of value here, but it's not in sort of the deep domain expertise in networking. It's- Well the service providers are pushing the heart on this. This is, they want product now, so they want some delivery. So what have you guys learned? What's the magnified learnings you guys have taken out of open daylight and vis-a-vis where open stack is? And talk about what's, what you've learned and what's the hottest spot right now for where the action is. Stability, so we have this initiative in open daylight called S3P, which is security, stability, scalability, and performance. And trying to figure out how to drive that agenda in a bottom up way where the developers rule. And basically, and it's not, because if you worked for, if it was brocade doing it internally, we would just yell at people and they would do it. And I'm the chair of the technical steering committee in open daylight, which means I'm essentially the CTO of 100 Person Startup where nobody listens to what I say. All right, they listen, but they don't have to do it. Herding cats is a term we always say. I call them head cat herder. And so no, so a bunch of what we've been doing and this is something- This is important though, because you have a lot of money on the table, a lot of consequences that we've had decision making, so you've got to be mindful of the different agendas. And that actually adds an interesting element of, like what this guy's job is every day, is to deal with those different influences. But one of the things we're really doing is, basically my current thesis, and I have no idea if I'm going to be right or wrong, but I'm pretty sure it's going to work out better than we are right now, is to basically, let's just get visibility. So we're starting in the brilliant, we're doing brilliant release planning. Lithium's about to come out, we're thinking towards brilliant, which is the next release of Open Daylight. And we're talking about how do you actually try and get this S3P thing to work. And so we're talking about, well, you need to have, getting the testing framework up, testing things that they're clusterable, that they're going to work with HA, that they're going to, you can at least pick a performance target, a scale target, and a longevity target, and just start getting public data out there. And I'm not going to tell you how to fix it, but I'm just going to require that you tell me how bad it is. And it turns out when you require people to tell you how bad it is, you have no problem getting volunteers to give you data. Yeah, yeah. And so the trick is you have to go get the data, but no, the testing is hard. I mean, this is, I mean, we, Stu Miniman is all over this stuff. He loves this stuff. And he always says to me, getting the customer inputs key. So in the open source project, you have constituencies in the community, but also you have to, in real time, get the customer data, because now we're seeing production workloads going out there. So, and the service provider is banging on that after he's doored. Well, that's really where we've talked about this a lot this week. I mean, that's really where the difference between the sort of upstream open source, sort of motivations differ with the production distro kind of motivations, right? I mean, upstream is more like a developer's kind of environment, developer friendly environment. And the commercial distro, everybody that's building a commercial distro will tell you, there's a lot of like maybe not so sexy stuff you have to do around building a distro. Installers, testing, scale, all that stuff. And then if you overshoot the market and that distro doesn't develop, we've seen other markets where pure play distros is not a viable business model. You could be on your butt big time. And that's the big question that we always have is, is there a distro business model? Yeah, I mean, we have a sort of a hybrid model of, we have a distro and we fully support all the stuff that you would do with a normal commercial distro, but we build that, we deliver that as a platform that then we build applications on, we have partners that build apps on that. And other people that are not even associated with us are allowed to build stuff on that platform, too. And we're focusing, I mean, one of the things that we, I've heard a couple of times is education. I mean, we should say that learning this stuff is really hard, it's something Cisco really nailed and I think it's a big reason why it is that they stayed so relevant for so long. And so we've been heavily investing in education and the certs aren't there yet and I'm not convinced the cert model is going to be appropriate, but certainly education is key. And we do that better than almost anybody else, both in terms of sort of commercial stuff but also in the open source space. We're who people come to. I can tell you about half of the people that have bought our distro now have listed that as probably one of the top two or three reasons why. The stability thing you mentioned, the three S's or whatever, was pretty solid. I mean, you got to take in a lot of that stuff. Well, there's that and then there's training. I mean, it's very hard if you're not a developer, you know, a hardcore black magic, modern software engineer developer these days to pick up open daylight, just like with OpenStack. Bring it down, build it, make it work. And then there's the other thing, which is if you want to extend it, I mean, we have a lot of customers, they're not buying it because it works out of the box for exactly what they want to do. They're buying it because it's a platform which they can then bake into the rest of what they're going to do. And so in order to be there, they actually will come and ask us questions about, so I'm thinking about doing this. Am I crazy or is this the right way of doing it? And we can say, whoa, there are dragons in that use case and you should, and here's what you need to be worried about. Or we can say, yeah, that makes total sense. And figuring out that yourself, I mean, is literally it's taken us hiring some of the best talent in the industry and about a year of working on this to make it work. To make it simplified too, you got to make it deployable. You don't create a longer lag on. Well, that's it. I mean, like one of the first things that our team did when we finally got to the point where we were building our distro was we built what I call the one button installer. I mean, if you try to install Open Daylight without our installer, have a good time, right? And it's going to take you a while. Yeah, yeah, well, and getting everything, like getting HTTPS configured so that way when you're making your rest calls, it's working correctly, getting the certs working, getting the point which you have SSL down to open flow that you're using, NetCon for SSH, and securing that, combine it. There's just sort of all of these details. Like in between the toes, you're talking about like, like blows up complexity. And even just employing enough people to have thought about that for long enough is hard and customer, I mean, most customers are not going to do that. And we have, and that's really the value proposition we're offering. Well, you've got to give them a rant is critic. And they're business model been poo pooed by a lot of people, but they've proven that customers want out of the box solution. Yeah, they want, yeah, stable out of the box. So that brings up the next level of questions, which is, as this market, we call it a moving train. There's a lot of stuff going on. We just talked about Kubernetes and containers and all the rage going on. So we still haven't seen that as cloud apps fully developed yet to take advantage of containers. So containers are kind of hanging around. Now you got a Kubernetes kind of model. You know, what is, what is that? What, how do you, with the moving train of OpenStack, how does Open Daylight stay up to date? And, and can you guys talk about that dynamic? And what's changed with Open Daylight over the past just three years as we've been talking to you guys about it? Well, I mean. It's hard to say what hasn't. It's been a roller coaster. It's easier to enumerate what hasn't changed. What hasn't changed. I mean, I mean, so, so one thing is that we're, I mean, the OpenStack community and the Open Daylight community are really, they're the same community, right? I mean, you just look at the logos and the people. I mean, it's not, they're not two different things. So, you know, we're following the same trends we're in the same ways. But I mean, like, I mean, Open Daylight has moved from, hey, is it going to be a big switch for Cisco to, hey, is it going to be the MD cell or the AD cell? To, okay, this MD cell thing actually is kind of cool and you're getting a lot of automated features out of it. Let's try and make that work too. Let's simplify things and, and, and moving to craft in order to build sort of dynamic distributions. You can pick and choose the features you want to, you know, changing the way the whole web user interface worked. I mean, the thing is moving very, very quickly. In fact, actually the hardest part is trying to carve out enough stability in order to productize it and ship it. Which is, but, you know, we are not, I mean, we have changed more in the past three years than I would argue almost any other open source project has. It's been, it's been crazy. There's always political agendas too, different approaches. Obviously you're, you're a vendor in Brocade, but you've done a ton of code contributions these guys do to OpenStack. So, I mean, people may or may not know that. You guys do a great job, and, you know, we've been following all your work, so congratulations on that. But at the same time, but at the same time, but we are in an era where it's, you know, being in, you know, software guys since the 80s myself, it's like it used to be the best marketing or best competitive strategy could win the day, but now with open source, ultimately software rules, right? The best software actually does actually win out in the end if you have a consensus environment like, well, and you can see that software. That's also, well, but how do you define best? I mean, this is, this is what we're seeing is that best used to be, you know, that, you know, you had a vertical, that where you carved anything out. Best these days is Walmart and people are showing is really it's about building an agile stack where each component can be understood, and you don't have to understand it, but if you want to understand it, because you think there's value to be derived and understanding it and fixing it and tweaking it and replacing it, you can. Yeah, and exactly, that's exactly my point, and that's a great thing to highlight. It's not the monolithic software that aligns a code could be like, you know, we were talking about work days of HR apps, just picking them out as a random example. They're not going to solve every, and they're not going to solve every use case in HR. You know, we're seeing companies like ServiceNow developers building out the most kick-ass expense report app or the leave of absence app, these little weird apps that might not make it on the updates, so back to agile, it comes down to functionality, right? It comes down to, this is software, stable, it's scalable, it works for this use case, and it's decoupled, less brittle. And it's back to Dave's Meyer, it's not what you build, it's how you build it that matters, and basically what, and that's something which we've really taken to heart internally, and the way that's manifesting exactly what you're talking about is that Brocade is a company which now, in the open stack space, in the open daylight space, we have the expertise to be able to turn around and churn out the next feature quickly. We're shipping drops of open daylight every six weeks, which means releases aren't even a thing. Like, they just sort of happen. And they're even more granular than that now too. We don't have a monolithic release, we release little chunks, and you know, you have to train up as you go. Well, I think over the past five years, Brocade has really had been revitalized with open source, and with open stack, it shines the light, if you will, pun intended, on value, right? So Brocade might not have the big marketing muscle that the big companies might have, but you got great talent and technology, but when you bring it out in the open, shine the light on it, you have an open daylight-like situation. But it has legs, so the good stuff wins in that kind of environment. Even in the last year, I mean, I joined Brocade a year and two weeks ago. And when I did that, when I did that, people thought I was crazy. And I have to say, I've hired a bunch of those people since then, so they're, you know. It's currently, it really put a pump of juice into the veins of Brocade as a company, because the market was shifting significantly, and it has made some good bets a decade ago, I think. I'll tell you, I mean, when I started building the team, I mean, I took Dave's philosophy to heart. You know, worry more about how you're building things and what you're building. What that means though, is that you need to spend a lot of time worrying about how you're building things. And our team process evolves about as much as our releases evolve. Every six weeks, there's, you know, people get together, they say, well, look, let's adjust like this, let's adjust like that. And that's totally part of the plan. I mean, case in point, we started off with one flat structure, and that worked really well until we got about 20 or 25 developers. Now we have different teams, and we're talking about, okay, well, there's HR report two structures, but there's also a structure of delivering features. And the thing is, there's nothing as sacred. We're willing to basically, and we Blow it up at any time, move it around, and we can figure based on what the market's going on. And then that's true, that's true down to personnel, not just tech in terms of how we run our development organization shifts on a six week basis. People move around, work on different stuff. The idea is the stacks are changing. So what Amazon has proven, in my opinion, is that you can actually do some integrated stack work and not get so dogmatic around infrastructure as a service, platform as a service, and try to get into a box by some analyst definition, whether it's a gardener or whatnot. The bottom line is that customers don't talk like that. Customers talk about services, right? Yeah, I mean, the other thing I say is it's whatever is a service. It's whatever I need as a service. And it's a, if you can be agile enough and you can have a stable enough platform to build on that, then you are free to adjust as you need, not just us internally, but customers, right? Guys, talk about, let's roll the clock back for the folks out there. A lot of young guns coming in. I want you guys to share your computer science and technology backgrounds. Back in the 80s and 90s, systems programming was all the rage, right? And that was, you know, got to see a client server who drove that. Obviously networking came in, you had network topology distributed, computing kicks in and the cloud comes in. But now, essentially with, essentially people, you know, the younger coders, they've never loaded Linux. They've actually never actually loaded it. It's always been loaded. It's always there. Hatches are always auto-updating. So those new generation of engineers are coming in. What is the mode of operation right now from a developer standpoint? Is it more systems? I mean, certainly this show here is very architect driven this year, hearing a lot of conversations around architecture. What skills? Skills, what's the ideal mindset? What's in demand? What's hot? What's needed? Where should people try to figure out, if people are trying to figure out their careers? What teams to join? Asynchronous distributed event-oriented programming. And so, Scala, the reason why it is that we don't write more of our stuff in Scala is because you can't hire them because Twitter and Facebook are paying them astronomical amounts of money. So Scala is less the technology, that's not the language, but the thing is embedded in Scala. The skill sets. The skill sets embedded, which are understanding that everything is distributed, that you have to be able to pass events around. It's asynchronous. It's not writing a one, two, three, four, five, six steps. And that's a skill set, which is just crazily difficult to hire for really annoying to teach. And something which I picked up in my education has done me really huge amounts of good. I think that's sort of- Crayat that's worth having under your belt, basically. Yeah, I think that's the biggest shift in the last 10 years has been that, which is it's really distributed computing, distributed systems. Well, we talked with Kubernetes guys about Go, Google, that's a little easier to teach, back to the getting a computer science grad, teaching them Go is very easy. Well, the key, though, is still understanding the fundamentals, right? We were talking about this earlier today, right? I mean, I still think, you know, a fundamental understanding of algorithms is important, of basic networking principles is important, basic distributed systems principles. Is there a certain game they have to play as a call of duty? Is it, you know, what's wrong? Whoa, is there a certain team? You have to understand what you're doing. It's generalists. It's staying a generalist. I mean, actually, if you ask me right now, the worst thing you can do is list a bunch of skills on your resume. And because if it looks like you've got coasted through the thing, picking up skill after skill after skill after skill, it means that you're, it's a bad sign. What I'm looking for is people that, and what I hire and the people that work out the best with people that basically are whatever, Java, Scala, PHP, I don't care. It's all basically the same thing. They can adjust to the tooling, basically. That's what I'm gonna say. So when we hire in our team, and we've been doing this from day one, the number one thing on the board is awesome problem solver. Well, there's not an asshole. Well, there's not an asshole, so. That's the zero. That's a baseline. No, no, that actually is. I mean, there's really two principles when we hire, but you know. Keeping it, sweeping it on top of it. But I mean, that is a good point though. I mean, you know, there are certain sort of company environments. You want some swagger, but you don't want an asshole. Is it interesting to have some swagger? Well, no, no, no, no, no, no, no, no, no, no, no. Actually, this stuff matters. The way you build, is how you build things is more than what you build. Actually, the interpersonal dynamics, no single person, I don't care how badass they are, is going to deliver our product enough in order for them, for them to ignore their interpersonal dynamics. And so the team which we built, the ability to incorporate networking people, software people, test people, dev people, C people, Java people, Python people, into one organization that actually interacts, works and moves, is to a large extent, brocade secret sauce right now. Yeah, it's a group of heavy duty problem solvers. Right, and it's. Well, it's going to be fun too, because you have a lot of interrelated services and personalities. And working with bad personalities does not make it fun, which makes people want to leave. Yeah, yeah. That's really at the heart of what we're doing. All right, so what's the most fun you guys have had programming and developing and brocade? Give us some highlights. Fun things you've done on code, off code. Oh, well, so I mean, so we have an engineer who's Devon Avery, and if you ever get a chance to talk to him, you should call him out. He's just an all-star engineer all around. He's a madman. He's just really, really phenomenally good. And we've gone from basically pushing every single test we run against our product, from not quite being able to do it in four hours, to doing it in about six minutes. Six minutes, yeah. And so we basically just getting this whole Jenkins, deploying parallel jobs, testing the whole thing. Testing and integration is really, that is where it's about. I mean, I joked that the tests matter more than the code, but I'm not screwing around. That is honestly true. And getting that working, and watching how somebody takes that and just turns it into the amazing system that it is, is really stunning. Well, this is a great example too of what we've been talking about, right? I mean, this is, you know, writing testing scripts and stuff is not necessarily viewed as the sexiest thing in the world. You know? But it's the most important thing. But it's the most important thing. And you know, you can, you know, like. Migration is a big topic here at this show with OpenStack. You've got to be moving stuff around. I mean, that's all about it. And on the level of skill, the set of number of skills that require is, you know, a single person can do. So we actually deploy and we test against about seven different hardware platforms, not just the OS. So we test against Ubuntu and REL, and we test against our, the Vyada V router. We test events, our open flow hardware. Other people's open flow hardware. Other people's hardware. We test, and so, and so, and the number we test against NetConf, we test OpenFlow, we test, we test amazing numbers of stuff. I can't even numerator all of it. But the result is, like, that's fundamentally required us getting a dev environment, a QA environment, and getting those people to come together and talk to each other to build it. And that's where, I mean, if you go listen to Facebook, listen to Google, that's what they're doing. That's what they do. They build, so that's the analogy, right? When we started off, it kept saying, well, we're going to build the airplane, as we take off. We said, no, no, no. You're building the airplane, and the runway, and the airport, and the city, and all that. And the city next to the airport, and all the comms, everything, all at once. And it's a moving plane at this point, yeah. But you have to do that to really. Yeah, I mean, if you're moving at the cutting edge, if you don't have, you can't pull in the right person to answer the question quickly, you're just dead. All right, guys, we're up on time. I'll give you guys the final word. What's next with Open Daylight and Brocade? What's around the corner? Share some insight around what's, show some leg on what's coming around the corner. Lithium, beryllium? Lithium, beryllium? I know, I mean, the big thing that's coming, I think, is proving this works in production at a scale. And so we're deploying in some really, really cool places, and I don't think I can say it out loud here. Not yet. But you would be, but like, but like. But big. Tier one big. Tier one, tier one big, you know, genuine grade A customers, and we're getting it in production, and we're starting to do the hard things, which is not just get the first instance out there, but getting it deployed, where there are seven different copies of it running, you're dealing with disaster recovery, you're dealing with migrating from one version to the next. R.O.I. and all this testing. And that's, yeah, exactly. We had a call. So that's the thing. Hurry up, test that out of the use case. So I think that's the big next thing, is proving this thing works, and it does all of the things that, you know, you have to make it a real product, working in production at scale. Yeah, yeah, I think my hope is that next year, when I come here at, you know, at this event, and you ask me the same question, we can name these guys, just like, you know, Walmart, Comcast, everybody is sort of. Well, we follow you guys pretty closely. We'll see you at DockerCon, when it's to you guys at a bunch of other events. Certainly EMC World's great. Guys, thanks for coming on, Colin. Appreciate it, Tom, appreciate it. This is Brocade inside the Cube. Laying it out, going under the hood, talking about skills, open daylight, all the stuff going on in the OpenStack community. We'll be right back with more coverage after this short break. Thank you.