 Live from San Francisco, it's theCUBE. Covering Red Hat Summit 2016. Brought to you by Red Hat. Now, here are your hosts, Stu Miniman and Brian Gracely. Welcome back. We're just off the afternoon keynotes here at Red Hat Summit 2016. Where before one of the most unique things I've ever seen at tech conference, a wedding that was performed up on stage. Dave Ward gave a keynote from Francisco. Dave's the SVP and CTO of Engineering and Chief Architect with Cisco. Dave, thanks for joining us again. Thank you. All right, we've also got Chris Wright joining us again, VP and Chief Technologist from the Office of Technology with Red Hat. Chris, always great to catch up with you. Likewise. So Dave, what's it like to be the warm-up back for a wedding? It's pretty tough, so it's interesting. I'm not sure what the hashtag is. If it's hashtag marriage as a service or hashtag open marriage, but you know, by the way, it's really quite interesting having a wedding at an open source conference. Yeah, absolutely, I think Paul Cormier was like something about hybrid clouds and the merging of families and like, so it was definitely hashtag geek fun. Exactly. From that standpoint. People at the show really love their technology and you went through a bunch of technology, Dave. Why don't you give our audience just kind of the thumbnail of kind of no stack discussion that you gave in the keynote. Well, really the, even before that, the key story that I was trying to tell is that the networking and infrastructure industry has undergone a massive change in the last four to six years. And it did start off with the SDN movement, but really when you take a look at services orchestration, the network, collecting analytics coming out of that to enable a service broker or PAS layer where an application developer can basically write their application and command the infrastructure to do what I need it to do. That really becomes a key piece. And what I wanted to describe or what I tried to describe is that the traditional way that we've had at a lot of conferences over those last four to six years of talking about virtual, sorry, physical underlays and virtual overlays and service overlays and how SDN fits all this is really complex. And that complexity cannot be exposed to application developers or they're not writing applications. And drawing out that piece, there's been a lot of talk in trade rags about the whole stack developer where to be a great application developer, you need to know how the stack is working and how these orchestration pieces work. But really that is absolutely not my goal. The goal that we're trying to hit is one in which somebody who's building their application or their business objective or designing the service that they want or their end customer can be a no stack developer and that all of those layers underneath can just go away and that all the infrastructure will do their intent. And so that's really the whole key premise of the no stack developer, which you don't need to have an awareness understanding of each and every piece. Not to mention, as Chris and I have worked over the years, lots of those pieces are moving really rapidly and this is not the time nor would it ever be palatable that here is the architecture. That is the architecture set and stolen for some number of years. That's just not the way the world's working anymore. So Chris, you work on lots of the cool, what we call the disruptive or emerging technologies and key story we hear from your top executives is that Red Hat is really baking this out for enterprise use. So bring us up to feed, what are the top things you're working on, what's getting you excited these days? Well I think this actually resonates with something Dave was just saying, which is we're really focused on applications. Red Hat's had a whole history of helping build up infrastructure from the low level platform enablement all the way through up to application layers and run times. All of that is there to run applications and so as we're trying to make things accessible to the app developer, it's not about exposing the complexity underneath, it's about enabling automation and operationalizing all of that core infrastructure really in pursuit of helping businesses meet their business objectives and that's about application development. So we're looking at it from points of view like containers, container run time as a key mechanism for helping application developers focus on their core logic separated out from the underlying infrastructure and I think this is a good time for us to look at how do we work together and bring together networking which is a key component for building bridges between these services in your app tier, how can we deliver that together without drowning the app developers with complexity? But Chris, we're not bridging. It's all at IP now, we're routing, sorry. It's all on IP, I could be. I could be. Of course. The other thing I wanted to mention is that the industry's finally evolved past having a notion of static workflows. Containers just proves this point directly where dynamic workflows, how things can go from either bare metal to hypervisors to swarms and hives of containers and create these really hybrid workflows is where certainly we're working together to move the industry to incorporate all of those pieces together and so again, in a talk I gave earlier today which was around what service providers are trying to do with N of V and other huge hot topic in the industry right now, we're still at the point in the industry where lift and shift is the name of the day. Take what was running on bare metal or in appliances and run it in hypervisors and have really static workflows of maybe business services or whatever the case might be. But there's not much time left in that architecture before the economic viability as well as the agility that's necessary for what the end customer wants to consume from a provider is going to last. It's going to move to a very, very dynamic workflow and so we've got to get all of that work done and working on lots of orchestration infrastructure isn't particularly sexy, but nonetheless, if the goal is build a service, build an application, let the infrastructure be driven via intent and then get the analytics out of how it actually performed or how it can be optimized. Right now that's the single focus that I'm working on for sure. Yeah, you're a networking guy. I mean, you're in that domain. If I'm an application developer listening to what you have to say, what should I expect to know about the network? What should I expect to have to think about services? I'm seeing these things like serverless which say I don't have to worry about any of that stuff. What should I expect? What would you expect that application developer to care about at this point? Well, without getting too excited because the network is something that is extremely cool and where all the cool kids hang out, you knew I was going to say that. Really, I kind of realized that I need to start small because a lot of the virtualized applications and containers and stuff right now don't have the ability to even interact with a network at all. So you can dial up CPU, you can dial up RAM, you can dial up storage, but even the most fundamental variable of the network, I need to consume or I'm going to produce this much bandwidth. Look, I'm just trying to add one dial to that overall mixing board, I guess, of all the things that you want to be able to orchestrate. Believe me, I could start off with a 64,000 other features I'd love to have people care about and be able to work towards, but instead got to be pragmatic that in fact, look, if I've got a very specific, tightly constrained workflow, we know how to automatically set QS variables, filters, blah, blah, blah, blah and all those different pieces and orchestrate this automatically, but just to get the one variable of, I'm going to consume or produce this much bandwidth as those workflows are really just part of the overall network that an enterprise or service provider has, I want to get to that point. And then what I'd like to do on the other 50% of the other half of this is, as somebody's trying to do a hybrid deployment across multiple clouds or in a distributed data center, even within one data center, basically report out of all that infrastructure and all that communication that was going on between that swarm or hybrid containers, here's how it actually performed. And right now that's just beyond the state of the art of pass layers and service broker systems to be able to have one the dial in, here's how much I need and dial two, what happened when I ran that? And so I'm focusing on those two pillars. I didn't even take it one step simpler, which is, we're talking a distributed system, you're building up a collection of services that work together as an aggregate to form an application, basic connectivity and connectivity that has isolation so that we understand that these components are allowed to talk to each other and these other components shouldn't and certainly where public access is the right of way path for packets to come into the application. Those are really the basic primitives and then we add the additional functionality of QLS and you start to talk about a few key features of the network that are critical for applications to function. And a bunch of stuff happens underneath the hood but we're not trying to expose all that to, yeah. So I love it because Chris basically pulled pin, dropped grenade because that's like the biggest topic in container networking today. Because again, the swarms and hives are being spun up and torn down so rapidly that whether you're trying to have just basic communication between these or treat them as collections of containers that are working in a workload, these are challenging problems. And in particular, because in container networking it's so patient on how it's working, getting the performance of the overall system and the stack to respond to the needs, desires and pace at which the applications are firing up. It's the conversation going on in the networking industry right now and as we interact together. It's a very different discussion than we had with virtualization. I mean we spent the last decade trying to fix what it broke on both the storage and the networking side with a virtualization layer. You can talk about how, I mean, just the different architectures or application, how you're trying to make sure that it's not going to take us another 10 years to fix things once we move to these new architectures. So, okay. We have open source, right? And I'm only half joking. We've got a new development community and a mechanism for collaboration that virtualization was largely driven by commercial proprietary solutions and we have virtualization solutions that have come out as part of the open source world. But today, all of this development in the container space is being driven by open source development and that innovation pace is staggering and I think that's one key differentiator for why we'll move faster here. Another one is we're leveraging 10 years of experience. So, you know, that initial application that Dave described is moving from physical appliance to a virtual appliance. I call it kind of a naive first start towards cloudifying. Yeah, lift and shift and we really are trying to move towards cloud native applications and this is the movement that we're seeing now and that movement is being completely driven by open source development and innovation. So, I agree with Chris and the interesting piece is that as an industry, there's many projects that are actually going and trying to tackle this particular problem and neither Red Hat nor Cisco are picking a winner now and saying this is the way that we're going to do that. It's far too early to do that. In fact, containerized networking is, frankly, a couple of years behind where virtual, sorry, hypervisor or virtualized networking is, but nonetheless, that gap is really, really slimming down and it's slimming down because all of the discussions are being done in code, not in documents and not necessarily talking heads on stages or anything like that, but being done in the code so we can afford to have as many different experiments and functionality, scaling performance and how the overall system's going to work and I think that's good news. Yeah, I think so too. And one of the things that is interesting when we combine the application development and this sort of network re-architecture, network functions virtualization is something Dave mentioned earlier and I think there's an interesting movement there which is initially we focused on the virtualization part of NFE. For me, the long-term there is actually going to play out with containerization of a lot of this network functionality and it's that that will help us drive understanding application requirements from a network point of view where the network is connecting containers and network functionality is actually running inside containers and I think that's a way where these two industries are coming together, the app world and the networking world to really help accelerate the state of the art. But what's interesting is it's not in the, sorry guys, it's not in the same segments of the industry where the NFV movement started. It's not necessarily the cloud native nature in business services and firewalls and security and load balancers. The fastest moving part of the industry actually is in media where Codex ingest transcoders because the internet is 80 plus percent video being transported so whether you're producing content or you're playing it out, segment recorders for VOD gone cloud native, CDNs gone cloud native, encoders at the edge for JIT or just in time transcode in gone cloud native and so those pieces where the app, the overall app functionality wasn't set in stone and required effectively a re-architecture and redesign at that time enabled that to go first and we're going to see how fast the rest of the network, virtualized networking industry can keep pace. If I'm a network engineer, you know, back in the day you had a CCIE, you could look at what was going on in the ITF and you saw where the standards were being developed and now you've got open daylight, you've got neutron and open stack, you've got NFV going on, you've got Kubernetes, it's got no, where do I go look to figure out what's going on, where's the place that is that centralized intersection or is it become distributed in terms of figuring out where the network discussions are even happening? It is distributed for sure. I mean, each of these are independent communities and they're trying to solve problems in ways that might be unique to their problem domain. There's still activities that are centralized and the ITF is still important. There's definitely sanitization efforts that are at least trying to make sense of all of the innovation that's happening in the open source world. But if you're looking at container orchestration, you know, obviously we're really all in on Kubernetes so we would focus our efforts there. If you're looking at controlling networks from a combined view of the application side plus the underlying fabric, a project like open daylight is a great place to look. So I think it's going to depend on what your goals are and what you're trying to achieve for which communities you get involved with. So additionally, not only, first of all, I agree with Chris, you're not going to find the place to go to necessarily determine your career trajectory. The careers now are totally different than they were in the past of just, I am an operator of that thing, whether it's in the network or it's a computer or it's storage. There are data modelers of devices. There are service models, there are service designers. There's ones who are working on antifragile designs, et cetera. These are all fundamentally new careers and new career paths that are distributed across all these organizations and you're not going to find it today in any one central organization that's writing the documents that determine the fate of how that's going to happen. It's moving far too fast and it's happening all in code. Yeah, and I think that's probably part of the strength that we're seeing is this diversity brings about longevity where we have a lot of different implementations looking at things from different perspectives and we can slowly start to see where the cream rises to the top and where the critical innovative changes are really taking place. So what's kind of interesting also for network engineers, I guess Chris and I are feeling a little chatty this afternoon, but it's good. So nothing like a wedding to get you excited. So what's interesting, in the networking world, the dev ops space has a fundamentally different meaning for an application developer who's trying to get something done but there are whole careers now that are emerging in between the developers that are operationalizing that orchestration stack and those services and workflows that are coming out. Those, the networking engineers need to move into that space and there are fundamentally new skills that need to be learned and new folks that are going to come in and design new functionality as well. Yeah, there's even a new conference, NetOps. Excellent, well, I want to give you both kind of last word. We've talked about some of the technologies that are moving from kind of the emerging to it's stabilizing. So as you look forward, what's next? I'm sure there's plenty of work on the existing stuff, but what's getting you excited? What do you see down the road that more people might be learning about? Well, what I'm particularly interested in is we're creating building blocks and I don't think the building blocks are fundamentally changing. I mean, it started with virtualization, we've got virtual machines, they're still very useful. Containerization, we've got containers, they're not going to disappear or be supplanted in my opinion by the next thing that's even more exciting. What we're seeing is this is complexity, with complexity you need orchestration and automation and out of that we're seeing new applications of technologies like machine learning and how can we, I call it automate your automation, how can we get to the point where we have autonomous systems that are really adapting to the changing dynamics of the business landscape? And I think that's where it's the kind of ancillary support systems around these core technologies where I think we'll see a lot of the future development. And for me, it's proving out the concept that in a service broker or PAS system that a number of those cloud native service functions that I described earlier from a media PAS because what's interesting is we're still nation industry talking about the service broker or the PAS and in fact, the number of networking or related services that are available there is really, really small. And so whether or not you're a media content professional, those, whether again, the codec, the ingest, or a transcode or whatever the case might be, those just aren't available to you at that layer. You're still plugging in cables to connect these pieces together. Now, rinse and repeat through a security professional that wants to come up with a security design using a service broker or a PAS layer. The tools aren't available at that point and the reporting's not available, again, from the analytics side to make that happen. So I'm targeting at trying to understand whether or not there's going to be the Uber catalog or actually segment specific catalogs for specific professionals and sub-segnants of the industry. All right, lots more, I'm sure we could talk about and look forward to catching up with you at future shows. We'll be back with lots more coverage here from Red Hat 2016. You're watching theCUBE.