 Live from San Francisco, it's theCUBE, covering DevNet Create 2017, brought to you by Cisco. Welcome back everyone, live in San Francisco, this is theCUBE's exclusive coverage of the inaugural event for Cisco Systems. DevNet creates an extension or augmentation, a foot in the water of the new open source world for them, cloud native DevOps, infrastructure as code. It's Cisco's new mission, where applications meets infrastructure, AKA infrastructure as code, which is music to the ears of DevOps and all application developers. I'm John Furrier with my co-host, Peter Burris, head of research at wikibon.com. Our next guest is Bradley Wong, director of product management at Docker. Bradley, welcome to theCUBE, great to see you again. Yeah, great, thanks John. Docker, no other company to reference in terms of being a shining star in a shift of a paradigm shift or transformation where containers, Docker containers and now containers and Kubernetes microservices has taken cloud and brought it into a whole nother dimension. We've been covering you guys at all your DockerCon events. It's been great, multiple years. Congratulations, your success. You got to be happy that you got Cisco coming out saying, hey, we're going to make this in network programmable. Finally, let's do it, thoughts. Yeah, no, we're very excited about that. We, it's kind of interesting because we also found that networking is also one of those things that's quite difficult. And we saw this challenge probably about more than two years ago after people started getting more comfortable with containers and they wanted to start doing some more interesting things with them and start getting the containers to talk to each other and the rest of the world. That's kind of really where we saw that networking couldn't be improved upon. And I think you maybe remember probably about two years ago now that maybe more actually, we made an acquisition company called Soccer Plane that really helped us define what it means to really do networking properly. And that was actually the genesis of where even the Cisco partnership also started evolving as well because at Docker, we really needed to build out a framework for how to do networking properly internally first. And we always follow the mantra, the mandate of batteries included but swappable. So we built a reference implementation of what it meant to do networking properly for containers. But in doing so, we also then work quite closely with Cisco to also bring there many, many years of expertise to the table as well. So, and you can probably see that now with the culmination of projects like Contiv, which is actually now a certified plugin on Dockerstore that Cisco's really stepped it up and has really made lots of really great inroads and done a lot of good additions to Docker networking. It's always seems that way. I mean, the conversation we've been also following a lot of other communities, like OpenStack for instance, there's always debates but always gets down to, hey, the network, network, yeah. And I've had so many countries that say Randy Byas about the issues around it. It's really hard. And also you see Cisco get pulled into conversations just with gravity pulling them in because they're the network guys. So now it's nice to see that the executives at Cisco led by Susie Wee and the team and Rick, not just putting their toe on the water, they're jumping in the deep end here with the cloud native approach by going to developers and outreaching to them in a different way and saying, look it, we want to make your life easier. That's what you guys have done. So certainly a success to you guys for Cisco doing the work around the fringe but now that they're coming in, how would you tell someone, describe that move for Cisco? I mean, obviously Cisco hasn't not been absent. They've been there with you guys. What does this really mean for them as they go fully committing here now? Right, yeah, that's a good question. And Cisco is beyond just obviously a networking company. That's kind of where its roots came from. But we saw that there was some good opportunities to work with Cisco, not just on networking but a few other things. I think what a lot of people probably get familiar with Docker because it's a great developer tool to start. And that's really where people's first interactions with Docker really is. It's really easy to get started, really easy to start building your applications in Docker and start moving those applications into other environments, like going from dev into test into prod very, very seamlessly. So Docker really becomes that sort of what we call a software supply chain that really enables dev and ops to use the same tooling, the same tool chain end to end. And we feel that if we're able to use the same tool chain end to end from dev all the way through to the ops, we alleviate a lot of the challenges to deploying applications in production. Now Cisco so far has been very, very strong in the ops space, very strong in the infrastructure space. And we also come very, very strongly from the developer space as well. So I think as we basically build out this software supply chain, there also is a need to make sure that there is this kind of underlying infrastructure that's also ready to run that software supply chain as well and to really harden it. And that's what, one of the first things that we really did with Cisco is to make sure that we have a very clear vision of how to make that operationalizable for the enterprise. Second time I heard the word software supply chain, few years also use the word data supply chain. Data is asset, it's also going to be software. Software is an asset, it's data as well. What is software supply chain mean? Describe that for a second, take a minute to explain. Yeah, I mean, that's a good question. So in any supply chain, I think there's sort of a progression of where there's sort of inputs, where things sort of come in. And for us, we are in the mission to build tools of mass innovation. So we really want to sort of start with the developer and that's really where a lot of really good stuff comes from. Everyone's got great ideas and we piece those ideas together, give them the tools that they know how to use really well to develop them. But it's not just good to have great applications. They need to be usable and they need to be able to be deployed. And what we believe is software supply chain is taking that development process and being able to have developers put their artifacts inside containers and then move those because that's really what it is. It's actually moving those artifacts into places where they can be shared with greater teams to start testing those and to start iterating on those. And ultimately to move those into production, whether it's on-premise or whether it's in the cloud. And that's what we believe that we enable is that movement of- Code and motion. Exactly, exactly. And it doesn't stop there because as you know, code is not stable. That always, there's always an iterated process and we enable that as well. So then as we find issues or enhancements that we want to fix in production, we move that back to developer and that whole process starts again. And be able to do that really, really quickly is what we want to do. So let's see in that metaphor for a second. If we think about this as a software supply chain, does that make Cisco a logistic supplier? I would say with any supply chain, so Cisco once again has lots of different areas that they're focusing in. And by no means am I speaking on behalf of Cisco where they are. Are they the rider trucking? Are they the ones responsible for moving things around? Yeah, so that's one of the places that Cisco does play very, very strongly in. So for example, we identified that the compute platform that Cisco has, the UCS platform, is a great place to actually run Docker in production, especially on-premise. And that's definitely one of the things that we needed to start validating all these different infrastructures that can actually have the right availability, the right performance characteristics, and things that then we can do together to make sure that these are essentially solid infrastructures to actually run these production environments on. Now, Cisco's been running solid enterprise infrastructure for many, many years. Docker's been running Dockerized applications also for many years as well. The marriage of the two we hope and we believe that will culminate in a lot of the enterprises which were very comfortable with running enterprise applications on top of enterprise infrastructure to now run Docker applications on enterprise infrastructure as well. So just making sure that there is very, very good infrastructure that's in place to actually host that supply chain. I think that's definitely one of the key areas that we are hoping to get out of this partnership with Cisco. So the other we've talked about here in the last couple of days for a amount is Conway's Law. And I'm sure you're familiar with Conway's Law. Which is basically the observation that the software that's generated, the reflection of the organization that generated it. You can use Docker or any other container technology to create really crappy software if you want to. But one of the things that Docker does introduce is the idea of segmentation, compartmentalization while at the same time simplified mechanics for how things work together. So talk a little bit about the expectations of people who get into the Docker and container world should have of the network. How should they think about their software as essentially distributed elements that then require a network? What's your thoughts on that architecturally? How is it going to play out? Yeah, I mean, it really depends on where that journey sits. I think we're, once again, I think we are the suppliers of these tools of innovation. But we want to also hold their hands as well through this journey. And that journey is not done day one. It's a step-by-step process as well. So a good example is you can start off and build the greatest distributed microservice application. And that might work well for certain parts of your company, but there's certainly many, many other applications that are already deployed out there which it may not fit, at least not today. And there's a journey to take those existing traditional applications along that journey as well. So anything that basically requires interaction with other components, any services that need to talk to each other to the external world obviously requires a network. Networking has been a very, very tough thing in the past that not always the simplest. Sometimes it could be over-complicated. You know. Sometimes. And many, many, many times. You know, honestly, I do think that the network professionals have gone out of their way to make the network as obscure and abstract as possible. You know, I think. You're command-line, guys. Come on. You know, I think, you know, to, I mean, I've been in a networking world for a long time as well before joining Darker. So I see some of that, you know, I think networking guys tend to, and young girls, tend to really look at what are all the different things that we can do, all the different little knobs that we can actually tweak to squeeze every little bit of performance, convergence time, things like that. That might work well in some environments, but may not others. That's why you needed so much variability and hence all these nerd knobs, so to speak. Darker comes from a very different place. I think if you look at the mentality of how we drive things, usability is a very, very key thing for us. We talk about usable security. We talk about, you know, a simple orchestrator through Swarm, for example. We forego the complex to focus on things that are usable. So networking for us, we wanted to initially look at it and say networking should be something that's simple and usable and essentially kind of get out of the way of the developer. Developers shouldn't have to think about all these kind of over complicated concepts. Like the network should be able to form its way around what the application needs. And that's really kind of what we're sort of thinking about there. Make it simpler and no simpler than it needs to be. And make it programmable. And make it programmable as well. Simple and programmable. And when I say programmable doesn't have to, like we're not expecting ops folks to have to learn how to code necessarily. I think if there's the right tools that are available, that should be a natural flow on them. They have to enable it so that the app developer doesn't have to do all the horror stuff like configuration management, all the hardware and the operational stuff that the networking guys have done for them. Because they're not ops guys, right? They're devs. That's a really good point because today, there is not really one single tool chain. And coming back to my earlier point of what we're trying to solve for, there's not really one single tool chain that ops folks use and application developers use. They traditionally use different tooling. What we're trying to do is first to have that common foundation of common tooling that people can converge on. And the second then is if we provide all the right hooks, so just enough hooks for the application developer to say, this is what my application looks like. And then enough hooks for the operations folks then plug in to say, hey, these are my security policies. These should talk to these and these shouldn't talk to these. And once we have the right ingestion points there, we should be able to, they take that into end without having to manually ingest all these different after the fact concepts into that development process. That should be a natural flow on. We're not saying the work is done there, there's still a lot of things to do, but I think the first glimpse of what we have there is starting. Docker, as you may know, there has some great tools to define what an application is. Docker compose for example, you can see how a multi-service application is laid out. Cisco can actually then provide plugins into that compose file and say, well, this web tier needs to talk to this application tier. And these are the basic premises of what networking security tools can then plug into to enforce policy. So we feel that that can be a lot more automated and we'll work towards that. Bradley, thanks so much for coming on theCUBE. Really appreciate it. Great to see you again. And Docker, obviously continuing to do great and continue to cover all your events. But my final question for you, take a minute to just explain short, quickly and succinctly for the audience. The Docker-Sysco relationship, what is it? I mean, joint partnership? Is it just, you guys just high-fiving each other? You actually writing code together? Is there a technology partnership? Give us some details on the relationship. Yeah, sure. It's a strategic partnership, which basically means that it goes beyond just high-fiving each other. There's some of that as well, but we believe in there's, any relationship of this size needs to be built on solid, attainable things. So we worked on, say, the Contiv project together, for example. We also worked together on what we call Cisco Validated Designs for Docker. This is joint engineering. Joint engineering work. We also work on joint marketing and joint go-to-market motions as well. And joint support. So you can actually call up Cisco for a Docker-Sysco solution that's deployed out there. You can call up Cisco support and they will hold that trouble ticket. And if any troubles do arise, they will take the call and then work on that. It's a nice relationship, it's a win-win. They get some cloud-native mojo with Docker and this new app world. You guys get enterprise access to the huge amount of clients that they have. Exactly. All right, final question, since one just popped into my head, it always happens that way when you got a role. But what's on the roadmap for you guys with respect to the Cisco and this DevNet Create, obviously it's going to, they're foray into this new world and bringing a new ecosystem together with DevNet, their core application, I mean their core developer community. What's on the Docker roadmap? What can we expect to see that's going to be fruits of the labor? Yeah, I think one of the things that we're definitely going to be focusing quite a lot on is to look at that first step of that journey, which is even taking not just the microservices that everyone loves to talk about, but even the traditional applications, those monolithic applications that are already deployed at their running mission critical enterprise workloads on there. We want to take those together with partnerships like Cisco and Dockerize those. And eventually modernize them and eventually evolve them into microservices. Yeah, get those mission critical apps, microservice size, if that's a word. Bradley Wong, director of product management, great to see you. Thanks for coming on theCUBE's live coverage with theCUBE here at the Cisco's inaugural event. Again, great show, great Cisco. I'm John Furrier with Peter Burris, more analysis and commentary and interviews after this short break. Hi, I'm April Mitchell and I'm the senior director of strategy.