 Live from Vancouver, Canada, it's The Cube at OpenStack Summit, Vancouver, 2015. Brought to you by headline sponsors EMC and Joypling by Red Hat and Cisco with additional sponsorship by Brocade and HP. And now your hosts, John Furrier and Stu Miniman. Okay, welcome back, everyone. We are live in Vancouver, British Columbia. This is OpenStack Summit. This is The Cube, our flagship program from SiliconANGLE Media. We go out to the events and extract the signal from noise. I'm John Furrier, the founder of SiliconANGLE. Join my co-host, Stu Miniman, lead analyst at wikibon.com. And our next guest, we've got David Ward, CTO of Engineering, chief architect at Cisco and Chris Wright, chief technologist at Red Hat. Welcome to The Cube, guys. Thanks. A lot of Red Hat, Cisco loved this week. You guys have been on The Cube multiple times. It's been great. Give them a hug, you know, things are going great. You guys are technologists. Get down to the under the hood. What's going on? I mean, what's happening in the relationship? What's the big story? I mean, what's under the hood? What's the technology you guys are talking about today? Well, obviously the big part of it is OpenStack. What are we doing to bring OpenStack to the next level? We're working on improving all the infrastructure pieces so that we can solve problems for a new class of users. I think a big area that Dave and I have been focused on is bringing OpenStack to the service provider. So that's looking at service provider, telecom service provider, carrier grade type requirements and how can we make OpenStack a carrier grade infrastructure? Dave, I want to get your comments on this because we were talking at dinner last night amongst the crew here, you know, a lot of the plumbing has to be stable networking, if you will, be stable and solid as a foundational element to be creative on top of it. And people are being creative, you know, certainly service providers and software engineers out there now are building great apps. So how are you guys keeping that together? Certainly from a service provider perspective and enterprise, they got to have scalable infrastructure to enable that creativity on top of a MAK DevOps. Tell, what's this magic going on here and what are you guys offering in that capacity? So a couple of things. So first, we've been in the game for a while, right? And trying to build not only NFV solutions for service providers, build out an OpenStack platform, but after years of work of integrating these pieces together, as well as experimenting, researching, incubating, et cetera. And this might sound obvious after I say it, but it really came to the conclusion that it's not just a niche of does OpenStack work? Can you make it work? It's not just a niche of can you get a couple of virtual appliances to work. You actually have to look at the entire stack, a whole stack, even as a networking engineer, or as a system administrator, or as a service engineer, if you want to think of it that way. And so what I'm trying to say is that, yes, there is the hardware resources underneath, there's the physical underlay that people talk about, there's a virtual overlay, but really the whole point of doing NFV and OpenStack is, and what I've been working on in NFV is to deliver a service. And it's just that the workloads are IO intensive, so there's a physical underlay, the virtual overlay, the service overlay, and then a policy plane of how you want to be able to deploy these things and build it out as a service. So what we've done together with Chris is not only build out our inner cloud offering, which some folks might have heard about, which is Cisco cloud services, we've also built OpenStack distro that goes on UCS's with Red Hat, so we partnered extremely tightly on this, and now towards the NFV piece and making this with service providers, we are using OpenStack and this whole stack approach to be able to deploy it, and it was through a whole lot of work to get it done. So Dave, can you give us a little insight? How does OpenSource software really change the way that Cisco is building and consuming products at Cisco? So the way, I guess the way I want to explain this is that one of the major challenges that I face is I can't go any faster than my customers. So as we're in the middle of this huge industry transition and transformation towards not only virtualizing and everything, but making compute and data centers and cloud part of the network and the network part of compute data center and clouds, I can't go any faster than my customers, so therefore the old way of, hey, let's produce a standard, let's crank out a great piece of paper and say, right, let's go implement that after years and years of standards, bodies, battles. Dude, that's just a CF in the making in this day and age. And so to fix that, you got to work in a co-development model and actually be able to do this stuff together to do a co-development model and learn this page directly from Chris and Red Hat, use open source. Open source does become the industry de facto standard. If you want to uncluster a situation, do it together, do it in the open and make it better and make it better top to bottom. So using open source like open stack, bringing in open daylight, creating midstream projects like OPNFV, getting a number of these building blocks that are required for a whole stack out there in open source is where things are and where things are going. So it's enabling our customers to go faster and doing it with them. So Chris, you know, Red Hat obviously has long history working in the open source space. Tell us, you know, what kind of rhymes this time and what's different that makes the whole open stack piece different than what the Linux overworld was. Probably the most exciting part for what's different is we're not out there selling every day the idea that open source is an improved, better, faster, better, cheaper way to build technology. You think people get the idea now? People are sort of sold on the idea and now it's about how can we collaborate on solving these new problems? And so I think Dave got it right. One of the beauties of open source is it's not just purely developer focused. It's about the whole community and the community includes users and users are coming to join us to help move the industry forward and the speed that we can do that is fundamentally different when you're not talking about establishing the piece of paper, creating the standards, building five or 10 different implementations of that same standard focused around interoperability. Here interoperability is while we're all using the same code, so it's interoperability with itself. It's a different question. I mean, everyone, I mean, at the end of the day it comes down to SLAs and search level agreements. You guys have a great track record. I mean, we always were saying, joking about Red Hat saying, you know, tier one citizen now, you know, before, you guys were disrupting, you earned tier one status in the enterprise. At the end of the day though, they want bulletproof enterprise grade and reliability. You guys have a 10 year kind of view of that. I mean, that's hard to do in open source, but let's get that out there. Given that, SLAs, what people care about, certainly service providers, how does that play into when you start weaving into, you know, auto provisioning, new scale, these horizontally scalable concepts that are being deployed out there, how do you guys enable in that SLA and can you guys share any insight into what it's like in a customer environment, taking the open source and running at scale with SLAs, I mean, take us through what that, what's that like? I think one of the things we have to focus on is the SLA often is about, we're talking about availability and often you focus on the platform level availability, where really we're talking about service level availability. So how can we continue to improve the infrastructure, move the infrastructure forward without disrupting services? That's really the question. So we've spent a lot of time, Red Hat has spent a lot of time focused in the how do we help update an open stack from one version to the next? Because if you can't do that, you're sort of dead right there. You've got this major outage waiting to happen in order to do your migration to the next version. So how can we improve that? Well, internal details of making sure APIs are compatible, making sure we understand how to migrate the database schema from one spot to the next and also have a method for rolling an upgrade across your infrastructure and holding a service on a particular node, waiting until it's done and flipping over to a new service on a new node once you've guaranteed to yourself that it's actually functional. And this is some serious engineering involves, not like you just throwing some code around. I mean, this is complicated, there's orchestration involved, you have automation. What are some of those things? What are some of the cool things that are being automated? Because what you just said sounds easy, but there's a lot of details involved, right? And it's hard. But automation's becoming a big part of it. Certainly in the networking side with policy-based, Cisco's doing that for a long time. You have now policy-based networking and self-defined networking. You've got automation. Where's the excitement? Where's the action in this automation game? Well, I think a key piece for us, a big focus for us has been in that how do we actually deploy and then manage, maintain and manage an OpenStack cloud? So it's about giving insight into the infrastructure. So we use all the automation pieces that we might use to deploy a scale-out application on top of OpenStack to actually build up the infrastructure of OpenStack itself. And then through a standard kind of elk stack, do monitoring and really get insight into how this thing is operating. Because it's a big, complex system. We're not talking about just a couple of services. It's a big, large distributed systems are non-trivial to operate. Actually, I want to disagree with you for a second, John, that automation is necessary, but not sufficient to guarantee a service. And we kind of hear that, hey, SDN's all about automation. And again, I'm not trying to pick on this one particular word because it's not about the word, but it's overused a lot. It's way overused. And like I said, it's necessary, but not sufficient. The reason why it's not sufficient is that if we just automated what we did today, but now did it via OpenStack or SDN or via any of these mechanisms, we've got the same internet. And that's kind of the fundamental problem. The goal here isn't just to continue to treat virtual appliances or workloads as endpoints running on a server and treat the network as a bunch of discrete endpoints that you need to manage all the same way. Yeah, you can automate them simplistically, give them names, give them addresses, et cetera, et cetera. But really where the action is actually is above all that infrastructure. And so what we're working on together is being able to build a platform out, an orchestration platform, looks at services, looks at policy, looks at services, looks at the virtual overlay, looks at the underlay, et cetera, and matches up placement, geo-redundancy, federated clouds, because you use the term enterprise class, but when you're talking about in service writers and there's 911 calls and there's emergency services all developed through this. There's critical mission, critical stuff happening. That shit can't fail. And bad things, really bad things happen. And so towards that end, all of these pieces have to come into it. Again, the cloud is part of the network, the network is part of the cloud and all of those tools have to come together. The action is being able to do this in real time, being able to react in real time, to be able to move workload, to move the services. So I understand what you're saying, which is kind of what your play is. Automating for automating's sake can lull you to sleep into a kind of a dumb cul-de-sac of nothing. Dude, it's boring. I mean, it's great, but it's boring. The action is the intelligence. So I think what you're getting at is to get more real time, dynamic, intelligent, versus just automating sake, stuff for the sake of automating. That's what I think that should be saying. The automation part is take the mundane task of an IT professional off their plate and let them go work on more interesting stuff. So, yes, it's got to be done, but the more interesting stuff is- Yeah, the action, if you will. Yeah, I mean, this isn't just about load balancers and gnats, right? I mean, even as from a networking point of view, total hoe home. Critical, yes, important, et cetera, but really the action- Check the box, get it done, move on. Yeah, move on to the action where, look, and it's not just about NFV. We can virtualize and cloudify a lot of these workloads that have been sitting in hardware appliances and make them at the size, scale, performance, and reliability that can be used for multiple segments across the industry. And that's exciting. That's actually what I find to be really exciting. I think the, realize you're talking to Cisco. The end part of NFV, the network part, we've got to get beyond that because that is going to allow the services on top. Again, it could be in media, it could be in transcoding, it could be packaging, ingest, could be the cloud DVR pieces. All of those require networking, but I want to get to all of these really fast. This is a really great point. I mean, I've been living in California for 15 years and I know a lot of people work at Cisco. It's always the same smart people, but they always say, and they're network guys, right? But then there's a debate internally at Cisco, move up the stack, right? Can Cisco move up the stack? So what does that mean? That means it's where the action is. So what does that mean to you guys as moving up the stack because the network certainly is fundamental, right? It's very mission-critical, but you have some opportunities there. You mentioned some automation here and there. But where's the action up the stack at Cisco? Where you guys go, how far up do you go? Where do you hand off? Where do you align with Red Hat and whatnot? Can you share some insight? It's always been an ongoing debate. Sure, so the thing about moving up the stack, from our perspective, and believe me, it's been a challenge, built a ton of networking kit and I can describe to you all the nitty-gritty bits-and-bite flag alignment of all the protocol packets and you would be snoozing in the corner. As sexy as I find it, I'm not talking to people in bars about it anymore. It used to be a great line, not so much anymore. But- It's great in the 90s. But what is working out in moving up the stack? Look, we needed immediate open-stack experience when we picked up MetaCloud, who it's a SaaS-offered distro to be able to provide IaaS instantaneously both out of the cloud and hosted. No company, no industry is going to be able to transform without picking up that knowledge base and having working fundamental systems. This is also why we partnered with Red Hat. We are major, major users of Linux, users of Linux. It's throughout our entire portfolio, but that doesn't, that's not a stack. The whole stack approach is really understanding to be able to deploy the entire service either out of the cloud in a private data center or enable the new emerging provider cloud such that everybody has a choice of the service level they want to pay for and the ease that they want to be able to run their workloads or deliver services is where the action is. Yeah, so Chris, I'm wondering if you've got, you guys talked to a lot of customers helping them put together these new offerings. Got some success stories or specific areas where jointly Red Hat and Cisco are helping the service providers offer these new applications, the NFE services and the like. Well, one of the focus areas that we have is bringing together managed services. And so part of that is the OpenStack infrastructure and that's what we're really focused on is building up that platform so that we can enable, I like what you said about it's not just automation, but it's about bringing services to this, bringing agile services is really how I usually put it to this environment. And in that sense, it's not just the application, but so we have this application as an appliance sitting in OpenStack. It's really, we've only solved the boring part of the problem and the next part is how do we make it a scale out kind of cloud scale application. And this is what we're building together. We're building a platform plus Cisco's network functions to enable scale out services so that people can consume on demand as they need it, what they're looking for. We're talking direct network access to your home. Potentially that could look like paying for a quality of service that's from your home to your service provider. It's specific, interesting services that the service provider can hopefully dream up and this is an area which I think will be interesting to see how quickly can the service providers compete with what the web scale cloud companies are doing across their infrastructure. And this is really kind of what I see as the industry shift here where we've got this great infrastructure, we've got a new set of players that found a way to kind of introduce services and monetize some of that infrastructure and we have service providers really eager to grab a hold of the value that they have. We have direct connection with customers consuming their networks. How can they provide an additional value to those customers? So agile from the cloud enables them big time. So directly with Red Hat, our Cisco cloud service offering which a lot of folks know is InterCloud is that segment that we're going after is creating that provider cloud both to run NFV workloads as well as enterprise workloads in a network tendency. If you want to think of that inside the cloud, we're partnering with Red Hat on that. And that is one main way that we're trying to enable providers together. Now, what's interesting and towards this end, you think about the platform we're trying to build. Networking is probably the largest high tech industry that doesn't have an ISV community associated with it or a clearly defined ISV community. When you ask me, when we're going and targeting up the stack, remember that enabling that ISV community, enabling a developer community that can easily turn on and easily utilize without having to have incredibly deep understanding and knowledge of every feature knob and flag that we have in our operating systems or can take advantage of and be able to turnkey this with ease is the platform that will enable developers, entrepreneurs and ISVs to be able to build out on top of any cloud system with the networking compute capabilities that are underneath. Yeah, so Dave, I mean, one of the challenges with Cisco's been so dominant in networking, maybe it hasn't fostered that ISV community. Why is it going to change now? I'm going to put it this way. So the reason why it hasn't happened in the past is that there wasn't a platform for people to code to without a doubt. SDN hadn't been invented yet. The operating systems hadn't had APIs. The protocols hadn't been invented yet. There was a no notion of controllers. There was no notion of, frankly, an open source stack that could be used like open stack that enables that platform. A lot of work has had to go into this to be able to get to the point where there's a proper level of abstraction away from just straight up networking, straight up storage, straight up compute and can orchestrate those applications. That's a great point. I think that's a great point. And you've seen the proof today. More productions being deployed. The use cases are more diverse. Got film to enterprise and get service providers and people doing live demos. So to your point, open stack is out there. People are using it and have quality system software to deploy it. So, okay, that's a platform. So you're saying, what's next? What happens with the ISVs from here? That's what your question is, right? What's next? Get the platform. Okay, so a couple of things that I see happening in the industry that I would like to try and enable with this platform. So if we've recently placed eight billion things on the internet, basically known as your mobile phones and over the last five years or so, the next 10 billion with the whole internet of things transition that's happening is going to add 10 billion more, probably in about three years, you know? Everyone should always be careful with claiming numbers when it comes to internet trajectory and history, but that being aside, there's going to be a metric shitload of things attached to the internet, right? Towards that end, they need to be managed, they need to be named, they need to be orchestrated, they need to be secure. They're producing data, they're sending data into a cloud that hasn't been invented yet. You want to know the platform target that I would like to go after is not only the NFV pieces, not only the enterprise workloads, but being able to orchestrate the services information that are being produced by those 10 billion things rounded to the nearest number of things that are going to be attached to the internet extremely rapidly. And so that, in addition to, if you think about traditional partners, solution partners, channel partners and the rest of it, there are entirely new opportunities for them to build their businesses. And if you're from California, you've noticed Silicon Valley is on fire in the most positive way the amount of venture capital that's available to folks. I think both of us would like to see entrepreneurs building their new businesses on top of our technology because it's so stable, so pervasive and so easy to use. Man, I really think you got a great opportunity. I think Cisco and the Red Hat combination is really interesting, both, you know, been bulletproof, hardened, tested, and now poised for this next generation and you mentioned internet of things. I mean, Cisco, I know they also talk about the edge of the network and to end, you guys know end to end networks like nobody's business. So I think with internet of things, it now opens up the whole stack. So I think you guys have a really poised opportunity. Congratulations. A couple of things that need to be, continue to be invented because I appreciate the, you know, the accolades and things like that, but it hasn't been built yet, right? We need to invent all this stuff. But the core competencies there, that's the thing. That's the whole point, that's moving up the stack. You guys are poised and this is, I think the automation comments hit home with me because if you focus on the wrong thing and take your eye off the action, which is the creativity, that's where the news solutions that haven't been invented yet, you got compute available, you got cloud, you got networking expanding and you got software. So I love this market. I think, you know, it's that mindset of connectedness. I think that's going to be interesting. The edge computing and the top, just like we talked about tying the network into data centers, tying compute into the edge of networking and bringing that into branches, bringing into corporate environments, bringing it into the edge of service provider, COs and pops, allows us to use open stack to orchestrate NFV, allows us to bring workloads in there that actually can process that data. It just enables us to do so much more, plus bring all of virtualization into a networking environment and compute environment inside enterprises that hasn't been seen before because usually they're just doing it to run their workloads. Now we can run, you know, their entire environment if this all works out. Guys, great insight. Thanks for sharing it on theCUBE. We really appreciate it. We'll be right back. We're getting the hook here, going a little bit over, getting geeky and going to the hood. Dave and Chris here, Red Hat and Cisco doing some great stuff here at OpenStack. We'll be right back after this short break.