 from Boston, Massachusetts. It's theCUBE, covering Red Hat Summit 2017, brought to you by Red Hat. Welcome back to the Red Hat Summit here in Boston, Massachusetts. I'm Rebecca Knight, your host, my co-host Stu Miniman. We are joined by Tim Kramer. 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 in Ansible a couple of years now. Talk a little bit about your role, what you do in new projects you're working on. All right, yeah. So I came over with the acquisition of Ansible into Red Hat. I managed the Ansible engineering team and I now have the Insights engineering team as well. And yeah, 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. So what we've done is we noticed the Docker file 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 Docker file? 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. Yeah, 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 containers aren't a thing. It's more like a collection of things because you've got Linux namespaces, C groups and all those pieces. So it sounds like that's one of the 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 life cycle. So between Docker file 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, 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 its pieces like all over the place and sounds like more. Could you give us a little bit of the insider view as to how that progression went, 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. 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. So it is in literally every product that Red Hat ships today. And then we have deeper integrations with some of the products. So I know you've talked probably about cloud forms and Ansible inside and we have a better integration with Satellite and Insights as 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 is 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 with some software add-on stuff that I had in other acquisitions. But yeah, 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 to 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 hear, 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. Okay. If you want to apply. Come on. New Boston office. Good to know. Yeah, so 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. So it's actually kind of an easy philosophy to employ. So 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. 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 in 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 or all, you know, trying to do that pieces. Can you talk to us a little bit about your customers, why they turned to, you know, red hat and Ansible, you know, rather than 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, anybody that can write a shell script can start using Ansible and writing a playbook. And we got tons of examples out there so you can cargo-cult things. So it's number one, really, really easy to get going. Ah, geez. I just lost my train of thought. And the question was, oh, customers, yeah. So on the customer side, I'll give you an example. So there's a large technology company in Silicon Valley that uses us, 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. 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 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. And 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 that really helps create a real DevOps environment for them. So that's one good example. Okay, Tim, look at management 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 affordable as possible for customers? Wow, yeah, that's not my area. Okay, no, no, no, fair enough. You want to talk a little bit about some other customers here at the show. What are they asking you about? What are they excited about? 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. I see them, 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. So yeah, 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 the environment, 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. We have over 2,600 contributors to Ansible. And even in our Windows practice, we 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. 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. Experimental modules, people that are really trying some things out. That's one way that we can really help. 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. It's the open source way. It is. Tim, thanks so much for joining us. Hi, 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.