>> Announcer: From Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2017 brought to you by Red Hat. (electronic music) >> Welcome back to the Red Hat Summit here in Boston, Massachusetts, I'm Rebecca Knight, your host, my cohost, Stu Miniman, we are joined by Tim Cramer, he is the engineering director at Ansible Red Hat. Thanks so much for joining us, Tim. >> Hey, great to be here. >> So, you've been at Ansible a couple of years now, talk a little bit about your role, what you do, and new projects you're working on. >> All right, yeah, so I came over with the acquisition of Ansible into Red Hat, I manage the Ansible engineering team and I now have the Insights engineering team as well. We have many cool projects that we've been working on, one that's really exciting was Networking, but I know that you've talked to other people about that one. Another one is Ansible Container, which I'm also really excited about. What we've done is we noticed the Dockerfile sure did look convoluted, so we thought, it kind of looked like a bad shell script, and we thought well since we take bad shell scripts and we turn them into playbooks, into something very human readable, wouldn't it be great if we did the same thing for Dockerfile? So that's what Ansible Container really is. It's for companies that have really invested in Ansible, and they have a lot of Ansible content, take that content and be able to basically onboard it into OpenShift really easily with the Ansible container project. >> I actually, it was interesting, we were talking about kind of the history and things like the old Solaris Containers versus Docker, I read an interesting article talking about you know, containers aren't a thing it's more like a collection of things because I mean, you've got Linux Namespaces, Cgroups, and all those pieces, so it sounds like that's one of things that you guys are trying to help like Red Hat has always done, bring some supervision to some of these open source pieces. >> Yeah, a big thing about Ansible the thing that we try to do, over and over again is just make things as simple as possible, we're all about simplicity, and that's what we're trying to do on the Docker, sort of lifecycle. Between Dockerfile becoming easier, we also try to make it easier for you to be able to compose those into some kind of running set of microservices. >> Tim, since you came over with the acquisition, one thing that we've noted is, you know, Ansible's everywhere this week, it's been 18 months since the acquisition, we talked to Joe Fitzgerald, we talked to Andreas and it's getting it's pieces all over the place and sounds like more, could you give us a little bit of the insider view as to, you know, how that progression went, you know, what you're seeing, any challenges, I mean, we know it's all open source, but what do you have to navigate and how do you get that one plus one equals three once you put all this stuff together? >> Yeah, so I think that the acquisition itself was a really great move, right? It was great for Ansible, it was great for Red Hat. It filled a gap that they needed on the automation side and to make their products easier to install, configure especially, so what we noticed is that right after the acquisition Red Hat really just tried to let us keep going and run the business as is. They didn't try to force us into any specific model that they had for running things at Red Hat. What naturally happened was, because of the acquisition a lot of teams just started using it, playing with it, we were there as a consulting team to help a bunch of teams through whatever questions they had, but it took off virally just like it seems to take off virally with a lot of our customers. It is in literally every product that Red Hat ships today and then we have deeper integrations with some of the products. I know you've talked probably about CloudForms and Ansible Inside and we have a better integration with Satellite and Insights is the other one that's really good. >> In terms of the acquisition, what about the cultures? Before the cameras were rolling we were talking about how deep the Red Hat culture runs, really that's sort of brought down by Jim Whitehurst. Ansible had its own culture, how has the blending of the cultures been from your perspective? >> Yeah, one thing that I was really excited about coming in was, I've been in several large enterprises and I've been acquired now, this will be the third time that I've been acquired, and it's definitely the best one. This is a software company and that in itself is very exciting, because we're not trying to placate the hardware teams or you know, with some software add on stuff that I had in other acquisitions. The culture at Red Hat is one of really cooperation and everybody helping each other out, working together in communities, especially upstream communities, it's really upstream community first oriented, and that really helps teams integrate better at Red Hat because we can just work in our upstream community, we work in other people's upstream communities and get everything to tie together, it's a really nice collaborative model. So that culture of collaboration, and everybody's trying to get things done, do the right thing, it's fascinating. >> In a previous interview, you described your management philosophy as one of trust and enablement and that is something we've heard a lot at this conference is really empowering the individual, trusting the individual, it sounds wonderful, and it's the kind of boss I would want to work for, but how do you do it, what are some of the practices that you do to ensure that your engineers feel supported? And that you trust them? >> Well first, we do have a few job openings, so if you want to apply. >> (laughs) Okay, good to know. >> I guess some of the practices that I have when it comes to trust and enablement is I give my, there's an unending amount of work to do, right? So it's actually kind of an easy philosophy to employ. I just make sure that my team has a set of directives that are really clear, that they need to perform and you do sort of trust but verify, right? So you give them a bunch of actions to perform and make sure that you're checking in regularly and let them solve problems the way they want to. If they have an issue, or a question, or they're confused about something, we just cover it in a one on one or in a group meeting. The other thing that I do a lot of is, I tend to do a lot of group meetings. So I have my entire staff, like an all hands event, we do those every two weeks to make sure everybody's on the same page about what's going on in the greater Red Hat and within our own projects and I think that keeps people really tied in. >> Tim, management is something that gets pulled out, you know, pulled out from every vendor in the environment. The cloud guys are trying to build more into it, those infrastructure guys you mentioned that do hardware are all, you know, trying to do that pieces. Talk to us a little bit about your customers, why they turn to Red Hat and Ansible rather than to some of the other alternatives that are out there. >> Sure, so again, I think that one of the things that's given us a huge advantage is that Ansible is just so simple and we appeal to a very broad range of users. So I think that's why it took off so quickly and is used by so many people. So a system that anybody that can write a shell script can start using Ansible and writing playbook and we've got tons of examples out there so you can cargo cult things. So it's number one, really, really easy to get going. I just lost my train of thought, and the question was? >> Customers, why they're choosing it. >> Oh, customers, yeah. On the customer side, I'll give you an example. So there's a large technology company in Silicon Valley that uses us, and I can't say their name, but one of the problems that they had was utilizing, well, they were having problems communicating between development and production, okay? So the development guys would go off and they'd come up with a product and they'd know how they would deploy it in development, but when it came to production they needed you know, a different way of deploying it. So they used to create these giant documents, requirements documents and they'd pass them back and forth and they would speak different languages, it really wouldn't work, it'd take a long time to get something into prod. Now they're using Ansible Playbooks as that definition. Since it's so readable, the production guys can understand what they're trying to do, the development guys can easily write that in. So it's a great communication mechanism between those teams, it really helps create a real DevOps environment for them. So that's one good example. >> Look at management, it usually has a different pricing structure than some of the rest of Red Hat, some of the cloud models, how do you guys look at pricing? How are you trying to make sure that you make it as you know, affordable as possible for customers? >> Wow, yeah, that's not my area (laughs). >> Fair enough, you want to talk a little bit about some other customers, you know, you're here at the show, what are they asking you about, what are they excited about, I'd love to get some of the customer viewpoints that you're hearing this week. >> It's been fascinating, I've done mostly customer interviews the whole time and what I get is a lot of positivity. They're excited about Ansible, they're excited about the integrations that we're having with the other Red Hat products, it's taking off everywhere and yeah, they're generally just really happy with the product. We have a lot of interest in Tower as well which helps manage your Ansible environment. It's been super positive. >> As you look forward, what do we expect to see going forward? We understand Ansible will keep growing across the portfolios and environments, but what excites you and what should we look for going forward? >> So I think within the community one thing that I'm excited about is the number of contributors we have, right? We have over 2,600 contributors to Ansible and even like in our Windows practice, we've got 83 people that are working actively on helping our Windows modules. I want to see that continue to accelerate, I want to be able to make sure that our contributors are able to get changes in quickly and easily and that's something that we've been focusing on a lot. One thing about a really large community, it's great because you get a lot of attention, but the difficult part is that you can't accept all the contributions that people want to give you without just letting anything in, so we've come up with some techniques now, we have some bots that we wrote that help people formulate their pull requests and what I see going forward is we'll get more and more contributions in. >> And you'll continue that, creating more bots to let more people in, or let more people contribute? >> Yeah, we're also doing some tagging, so we're making it really clear what things are really managed by the core team itself, right? All the basic stuff and the engine of Ansible, then we have vendor modules, that's another thing that's pretty exciting, a lot of vendors are coming in and contributing publicly which is fantastic, especially on the networking side. And then we'll have those things that are curated so they have an active maintainer within the community, and they go through review from our core team to make sure that they're up to the right standards, but those are modules you know you can count on and then we'll have more of that wild west, you know, experimental modules. >> Rebecca: I like it. >> People are really trying some things out. That's one way that we can really help, if we can get a lot more of those wild west and let those settle a little bit, get some community leadership and kind of take off, and then they go into the curated pile. >> Rebecca: It's the open source way. >> Tim: It is. >> Tim, thanks so much for joining us. >> Right, yeah, it's great being here. >> I'm Rebecca Knight for Stu Miniman, we will continue with more of Red Hat in Boston, Massachusetts after this. (electronic music)

>> Red Hat OpenShift Container Platform >> Announcer: 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 Andrius Benokraitis, he is the Principle Product Manager at Ansible Red Hat Network Automation, thanks so much Andrius. >> Thanks for having me I appreciate it. >> This is your first time on the program. >> Andrius: First time. >> We're nice, >> Really nervous, so, okay. we don't bite. >> Start a little bit with your new to the company relatively >> Andrius: Relatively. >> networking guy by background, can you give us a little bit about your background. >> Sure, I mean, I actually started at Red Hat in 2003. And then did about four 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'm at Ansible, been there since about December, so working on the Network Automation Use Case for Ansible. >> Alright, so networking, has a little bit of coverage here, I remember, you know, something like the Open Daylight stuff and I have, actually there are a couple of Red Hatters that I interviewed at one show ended up forming a company that got bought by Dockers, so you know, there's definitely networking people, but maybe give us a broad view of where networking fits into this stuff that you're working on specifically. >> Yeah, sure thing. I think it's interesting to point out that as everything started in the compute side, and everything started to get disaggregated, the networking side has come along for the ride per se. It's been a little bit behind. When we talk about networking a lot of people just think automatically that's the end. 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, I need to run the whole rec, and I'm not a CCIE, and I don't really know what to do there but I've been thrown in to do something, I'm a cloud admin, the new title right. I have to run the network, so what do I do. 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 with the opensource model and said this is the new use case. >> Well, Jay Rivers, the founder of Cumulus, it's like networking will just be a Linux operating model, you know, extended to the network, which is always like, hey, 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, it's familiar to a lot of people, in the devop space, absolutely. >> So it's a very rapidly changing time, as we know, in this 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. >> I think it starts with, the true empowerment, you have the majority of the networking platforms are still proprietary and walled off, 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 have familiar terms and concepts from the server side in the networking side. So as long as you have SSH in 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 play books in order to build out your data center, with the terms and the Lexicon of YAML, the language of Ansible, things that you already know and utilizing that and going further. >> Can you speak to us a little bit about customers, you know, what's holding them back, how are you guys moving them forward to the more agile development space? >> Our customers are mostly brownfield, they're trying to extend what they already have. They have all their gear, they have everything they have 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 we knew that IT's always additive, so, I mean that's got to be a challenge. >> It's a huge challenge. >> Something you can help with right? >> It's a huge challenge, and I think from the network operators and network engineers, a lot of them are saying, again, they're looking at their friends on the compute side, and they can spin up VMs and provision hardware instantaneously, but why does it have to take four to six weeks to provision a VLAN or get a VLAN added to a network switch? That sounds ridiculous, so a lot of the network engineers and operators are saying, well I think I can 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. >> I love that you talk about everybody, kind of the software wave and breaking down silos, network and storage people are like, oh my God, you're taking my job away. >> Exactly, completely, no, 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, we don't have to, people can be smarter so, if you want to add a VLAN, that can be a code snippet created by the sys admin, it can be in Git, and then the network engineer can say, oh yeah, that looks good, and then I just say, submit. 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 peel 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, (excited clamoring) >> Networking is scary for a lot, >> It's super scary, yeah. >> 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. Start small, start with something, like again, you really hate doing, if you want to change, something really low risk, things you really hate doing, just start small, low risk things. And then you can propagate that, and as you start getting confidence, and you start getting the knowledge, and the teams, and every one starts, everyone has to be bought in by the way. This is not something you just go in and say, go do it. 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. >> And Andrius, 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 with the networks, they're too many things that are manual. So if I'm typing in some you know, 16 digit hexadecimal code >> From notepad, manually you're copying and pasting >> from like a spreadsheet. Copying and pasting, or gosh, so things like that, 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. I don't know, so we understand that it actually should be able to reduce risk, increase security, all the things that the business is telling you. >> All these network 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 a virtual environment if you want. So if you talk about lower risk, instead of just copying and pasting, and oh was that a slash 24 or a slash 16, oops, I mean that looked right, but it was wrong, but did it go through test, it probably didn't. And then someone's going to get paged at three in the morning, and a router's down, an edge router's down and your 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 network space, is getting buy in. Whether it's someone who has done it on their own, 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 of Procedure, no one knows about it. So it has to be part of your, you want to keep all the things you have, all the good things 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 onboard to understand how it fits in in order to go from where you are today to where you want to be. >> At the show here what's exciting your customers? You know, give us a little bit of a viewpoint for people that are checking out your stuff, what to 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 say, yeah, you can. The development processes, the innovation in the community, you know for example, if you want to assist, go ACI Module, it's in GitHub, it's in Cisco's GitHub, you can just go ahead and do that. Now we're trying, 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, you know, we have F5 here we have Cisco, we have Juniper we have Avi, all those people, you know, they have certified platforms with Ansible, Ansible Core, which is going to be integrated with Ansible Tower, we 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 nexgen data centers with our products. >> You talked about yourself as a boomerang employee, 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 ex-Red Hatters that went to Ansible. So what's really nice to 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? >> Yeah, it's a coming home, it really is. They understand, you know, they came back, they understood the values of opensource and the culture, again, I started Red Hat in 2003, I see the great things, I see new people getting hired and I see the same things I saw back then, 2003, 2004, with all the great things that people are doing, and the culture. You know, Jim's done a great job at keeping the culture how it is, even way back then when there was only 400 people when I started. >> Andrius, extend that culture, I think about the network community and opensource and you know, you talk about, there's risk there, and you know, you think about, I grew up with kind of enterprise, infrastructure mentality, it's like, don't touch it, don't play with it. We always joked, I got every thing there, really don't walk by it and definitely, you know, 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 kind of may be shy, shy to ask for help, per se. >> If it wasn't on their certification, >> Exactly. >> They weren't going to do it. >> If it wasn't there I'm not going to go, we're bringing them into, so we have, whether there's slack instance, there are networking communities, networking automation, communities, just for network automation. And there's one, there's an Ansible channel, on the network decode, select channel, 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. And know they have a safe place for network engineers, for network engineers to get into the net devop space. >> Another one of the sort of 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 they're 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, 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 you're data strategy can be in the cloud, it can be similar on your side, you can do Stash locally. For part of the operations piece, you can use that. A 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 the 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. When we started developing Ansible Core and the community and Ansible Tower in-house, we think about networking and we think about Windows, that's a huge opportunity there, you know, we're talking about AWS in 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 of the endpoints can be managed directly. Everyone benefits from that. >> Andrius 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.