 Red Hat OpenShift Container Platform. Live from Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2017, brought to you by Red Hat. Welcome back to theCUBE's coverage. I'm Rebecca Knight, your host here with Stu Miniman. Our guest now is Andreas Benokratis. He is the Principal Product Manager at Ansible Red Hat Network Automation. Thanks so much, Andreas, for- Thanks for having me, appreciate it. This is your first time on the program. First time. We're going to- We're going to- Start a little bit with, you know, you're new to the company, relatively- Relatively. Networking guy by background. Give us a little bit about your background. Sure, I mean, I actually started at Red Hat in 2003, and I did about four or five jobs there for about 11 years, and then jumped, went to a startup named Cumulus Networks for about two years. Great crew, and then now I've been, now I'm at Ansible. Been there since about December. So working on the Network Automation use case for Ansible. All right, so networking has a little bit of coverage here. I mean, I remember, you know, it says something like the open daylight stuff I had. There were actually a couple of Red Hatters that I interviewed at one show, ended up forming a company that got bought by Docker. So, you know, there's definitely networking people, but maybe give us kind of a broad view of, you know, where networking fits and the stuff that you're working on specifically. Sure thing, I think it's interesting to point out that as everything started in the compute side and everything started getting disaggregated, the networking side has come along for the ride, per se. It's been a little bit behind, but when we talk about networking, a lot of people just think automatically of SDN. And we're actually trying to think a little bit lower level, so layer one, layer two, layer three, so switching, routing, firewalls, load balancers, all those things are still required in the data center. And when people started using Ansible, it started five years ago on the compute side, a lot of the people started saying, well, I need to run the whole rack. So, and I'm not a CCIE and I really don't know what to do there, but I've been thrown in to do something. I'm a cloud admin, you know the new title, right? So, I have to run the network, so what do I do? Like, I don't know anything about networking, I'm just trying to be good enough. Well, I know Ansible, so why don't I just treat switches like servers and just treat them like, like what I know? They just have a lot more interfaces, but they just treat it that way. So, a lot of the expertise came from the ground up from the open source model and say, this is the new use case. Yeah, well, JR River's the founder of Cumulus, it's like, well, networking could just be a Linux operating model, you know, extended to the network, which is always it's like, wait, it sounds like a company like Red Hat should be doing that kind of stuff. Exactly, it's interesting to see a bash prompt in the networking, right? So, it's familiar to a lot of people in the DevOps space, absolutely. So, it's a very rapidly changing time, as we know in the digital computing age. The theme of this conference is the power of the individual, celebrating that individual, the developer, empowering the developers to take risks, be able to fail, make changes, modify. You're not a developer, but you manage developers, you lead developers. How do you work on creating that context that Jim Whitehurst talked about today? Yeah, I think it starts with the true empowerment. You have, the majority of the networking platforms are still proprietary and walled off gardens. They're black boxes, you can't really do much with them, but you still have the ability to SSH into them. You can still, you're familiar terms and concepts from the server side in the networking side. So, as long as you have SSH to the box and you know your CLI commands to make changes, you can utilize that in part of Ansible to generate larger abstractions to use the playbooks in order to build out your data center into, with the terms and the lexicon of YAML, like the language of Ansible, things that you already know and utilizing that and going further. All right, could you speak to us a little bit about the customers, you know, what's holding them back? How are you guys moving them forward to kind of the more agile development space? Yeah, our customers are mostly brownfield. They're trying to extend what they already have. They have all their gear, they have everything that they need, but they're trying to do things better. I don't find greenfield customers when it comes to the network side of the house. I mean, we've all got what I have and it's, you know, IT is always additive. So, I mean, that's got to be a challenge. It's a huge challenge. It's a huge challenge. I think from the network operators and the network engineers, a lot of them are saying, again, they're looking at their friends in the compute side and they can spin up VMs and provision hardware on instantaneously. But why does it have to take four to six weeks to provision to VLAN or get a VLAN added to a network switch? That sounds ridiculous. So, a lot of the network engineers and operators saying, well, I think I could be as agile as you, so we can actually work together using a common framework, common language with Ansible and we can get things done and we can get all of this stuff I hate doing and we don't have to do that anymore. We can worry about more important things in our network, like designing the next big thing. If you want to do BGP, design your BGP infrastructure. You want to move from a layer two to a layer three or an SDN solution. So, I just love that. You talk about everybody kind of a software wave and breaking down silos, you know, networking storage people like, oh my God, you're taking my job away. You don't have to exactly. No, this is completely, we're not taking your job. We are augmenting what you already have. We're giving you more tools in your tool belt to do better at your job. And that's truly it. People can be smarter. So, if you want to add a VLAN, that can be a code snippet created by the Sysadmin. It can be in Git and then the network engineer can say, oh yeah, that looks good. And then I just say, no, submit. So, what we see today with some of the customers is, yeah, I want to automate. I really want to automate. And you say, great, let's automate. But then you start getting, you feel back the onion and you start seeing that, well, how are you managing your inventory? How are you managing your endpoints? And they're like, I have a spreadsheet. And you're like, as a networking guy, I guess you, I don't know how spreadsheets are for inventory management. But that working is scary for a lot. It's super scary. So, how do you break that down? You do what you can. You do it in small pieces. We're not trying to change the world. We're not trying to say, you're going to go 100% DevOps in the network. Do, start small. Start with something that you, like again, you really hate doing. If you want to change something really low risk, things you hate doing, just start small, low risk things. And then you could propagate that. And as you start getting confidence and you start getting the knowledge and the teams and everyone starts, everyone has to be bought in, by the way. This is not something you just go in and say, go do it. It has to, you have to have everyone on board. The entire organization. It can't be bottom up. It can't be top down. Everyone has to be on board. So when I talk to people in the networking space, risk is the number one thing they're worried about. They buy on risk, they build on risk. And the problem we have in the network, there are too many things that are manual. So if I'm typing in some 16 digit hexadecimal code, manually from a spreadsheet, copy and pasting, or gosh, yeah, things like that, there is the room for error is too high. So there's the things that we need to be able to automate so that we don't have somebody that's tired or just, wait, was that a one or an L or an I? You know, I don't know. So we understand that it actually should be able to, you know, reduce risk, increase security, all the things that the business is telling you. All of these networking vendors have virtual instances. You can do all your testing and deployment. All your testing and your infrastructure, and you can do everything in Jenkins and have all your networking switches virtually. You can have your whole data center in virtual environment, if you want. So if you talk about lowering risk, instead of just copying and pasting, and oh, is that a slash 24 or a slash 16? Whoops, I mean, it looked right, but it was wrong. But did it go through test? It probably didn't. And someone's getting a page at three in the morning and a router's down, an edge router's down and you're toast. So enabling the full DevOps cycle of continuous integration, so bringing in the same concepts that you have on the compute side, testing changes in a full cycle and then doing that. You talked about the importance of buy-in and also the difficulties of getting buy-in. How much of that is an impediment to the innovation process? But one of the things we've been talking about is can big companies innovate? What are the challenges that you see and how do you overcome them? That is the number one, that is the biggest issue right now in the networking space is getting buy-in. Whether it's someone who has done it on their own, someone can get in, someone can just install Ansible and do something and then deploy a switch. But if they leave the company and there's no remediation, if it's not in the MOP, if it's not in the method procedure, no one knows about it. So it has to be part of your, you want to keep all the things that you have, all the good things that you have today with your checks and balances in the networking and the CIOs and the people at the top have to understand you can keep all that stuff but you have to buy-in to the automation framework and everyone has to be on board to understand how it fits in in order to go from where you are today to where you want to be. All right, so at the show here, what's exciting your customers, it gives a little bit of a viewpoint for people that are checking out your stuff, what they expect. Well, I think the one thing is they're not used to seeing, they think it's black magic, they think it's just magic. They're like, I can use the same things for everything? I said, yeah, you can. The development processes, I think the innovation in the community, for example, if you wanted a Cisco ACI module, it's in GitHub, right, it's in Cisco's GitHub, you can just go ahead and do that and now we're starting to migrate those things into core. So the more that we get innovation in the community and that we have the vendors and the partners driving it and you're seeing that today, so we have F5 here, we have Cisco, we have Juniper, we have Avi, all those people, they have certified platforms with Ansible and Ansible Core which is going to be integrated with Ansible Tower. They have full buy-in from them. They want to meet with us and say, how can we do better? How can we innovate with you to drive the next-gen data centers with our products? You talked about yourself as a boomerang employee. I mean, what is the value in that? And are you seeing a lot of colleagues who are bouncing around and then coming back from? Absolutely, I think pre-acquisition Ansible, the vast majority of the people, I believe were X-ray headers that went to Ansible. So it's really nice to kind of come back home and understand the people that left that came back to understand already what the- And people feel that way, it's a coming home? It's a coming home, it really is. They understand, they came back, they understood the values of open source and the culture. Again, I started Redhead in 2003. I see the great things, I see new people getting hired and I see the same things I saw when I was in, back then, 2003, 2004, all the great things that people are doing in the culture. Jim's done a great job at keeping the culture, how it is, even way back then when it was only 400 people when I started. Anderson, to extend that culture, I think about the network community and open source and you talk about there's risk there and I grew up with enterprise infrastructure mentality. It's like, don't touch it, don't play with it. We always joked, it's like, I got everything there, really don't walk by it and definitely, some zip tie or duct tape's going to come apart. Are we getting better? Is networking embracing this? Yes, for sure. I think the nice thing is you start seeing these communities pop up. You're starting to see network operators and engineers, they've been, historically, if they don't know the answer, they won't go find it. They're kind of maybe shy, shy to ask for help, per se. If it wasn't on their certification, they didn't need to know it. Exactly, if it wasn't there, I'm not going to know. We're bringing them into, so we have, there's a Slack instance, there's, there are networking communities, networking automation communities just for network automation. And there's one, there's an Ansible channel on the network to code, Slack channel that has almost 800 people on it. So they're coming and now they have a place, they have a safe place to ask questions. They don't have to kind of guess or say, you know what, I'm not going to do that. Now they have a safe place for network engineers, for network engineers to get into the net DevOps space. Another one of the sort of the sub themes of this summit is people's data strategy and customers and vendors, how they're dealing with the massive amounts of data that their customers are generating. What is your data strategy and how are you using data? So, there's two aspects here, so the data can be the actual playbooks themselves, the actual, the golden master images, so you can pull configs from switches and you can store them and you can use them for continuous compliance. You can say, you know, someone, a rogue engineer might make a change, you know, configuration drift happens, but you need to be able to make those comparisons to the other versions. So we're utilizing things like Git, so your data strategy can be in the cloud, it can be similar on your side, you can do stash locally, so to actually, for part of the operations piece, you can use that. The second piece is log aggregation is a big piece of the Ansible, so when you actually want to make sure that a change happens, that it's been successful and that you want to ensure continuous compliance, all that data has to go somewhere, right? So you can utilize Ansible Tower as an aggregator, you can go off using integrations like Splunk and some other log aggregation connectors with Ansible Tower to help utilize your data strategy with the partners that are really the driving, the people that know data and data structures, so we can use them. And one of the other issues is the, building the confidence to make decisions with all the data. Are you working on that too with your team? Yes, we are working with that and that's part of the larger tower organization, so it goes beyond networking, so whatever networking gets, everyone else gets. So when we start developing Ansible Core in the community and Ansible Tower in-house, we think about networking and we think about Windows, that's a huge opportunity there. We're talking about AWS and the cloud, so cloud instances, these are all endpoints that Ansible can manage and it's not just networking, so we have to make sure that all of the pieces, all the endpoints can be managed directly, but everyone benefits from that, so. Andrea, thank you so much for your time, we appreciate it. Thanks again for having me. I'm Rebecca Knight for Stu Miniman, thank you very much for joining us, we'll be back after this.