 Live from Atlanta, Georgia, it's theCUBE. Covering AnsibleFest 2019, brought to you by Red Hat. Welcome back. This is theCUBE's live coverage of AnsibleFest 2019. Two days of wall-to-wall coverage. I'm Stu Newman, and my co-host for the week is John Furrier, and happy to welcome back to the program one of our CUBE alumni, Tim Kramer, Vice President of Engineering for Management and Automation in Red Hat. Stan, thanks so much for joining us. Absolutely, it's a pleasure. All right, so Tim, it's been about four years since the acquisition, some of the undercurrents here is Red Hat didn't mess things up. As a matter of fact, the community's growing quite a bit. The ecosystem is definitely robust. Networking and security expanding really the footprint of Ansible. So, give us a little bit of the engineering side as to big announcement, Red Hat Ansible Automation platform, how long, you hear customers always talking about, oh, I took a thousand hours and brought it down to minutes of my time. Well, I think there were probably a lot of engineering hours on your team's side to get this rolling. Yeah, sure. With the Red Hat acquisition, the first thing that really happened when we came in was they wanted to make sure that we kept the community and that culture moving forward the way it was. We had a really good start at it, but it needed a lot of growth and obviously that worked out pretty well. Red Hat immediately invested pretty heavily in Ansible and in the ecosystem and really helped us kind of pop it out, right? Because that was one thing that Red Hat's really, really good at, that Ansible needed a little bit of help with. So, we saw the community just take off, we had the right kind of investment on the engineering side so that we could build up the processes and then also build the core engine really well and invest on the tower side to make that all work. The other thing that happened sort of as a byproduct was we started getting Ansible integrated into a bunch of the other Red Hat products and we started out with some of the other management products, right? And I think one of the most interesting integrations that we did was on the insight side. So, insights are artificial intelligence automation and what it does is it goes out and it works with RHEL especially, but it goes and does daily dumps of a bunch of information about your RHEL system, does a bunch of analysis on that and then tries to find problems or issues and then proactively tell you about them. What we did then is instead of just sending you an article telling you how to fix the problem, we thought, why don't we combine that with Ansible and then just ship you a playbook and fix the thing automatically and then we took those two concepts, brought those together, put it with tower and with satellite and then started just the complete cycle that would allow you to do self-healing software. So now we can just by daily dumps of things figure out what kind of problems you're having, issues, CVEs, performance problems, other things, match that in our database, figure out what our support organization has figured out in the past and proactively give you a playbook and fix it on one stop. What's the impact of customers on that feature? What's the impact of those guys? Well, so if you're managing a really large fleet of machines, one of the things you want to do is you want to make sure that you're staying up to date, maybe you have compliance issues, you're worried about CVEs that are coming in, or perhaps you just want to make sure that you got the latest in grade, you're tuned well, whatever it is. If you're managing that number of machines, you're going to spend an inordinate amount of time trying to resolve those issues manually. Even if you could use Ansible to do the automation, you got to know that you have the problem to begin with. So it really connects the two sides. So it's like automating your support experience. And so what does self-healing mean in that context? Means it heals the... Yeah, so here's an example. I can give you an example. So an example would be, there happens to be a CVE that's recently come out. You want to scan your 20,000 machines and you want to figure out if that CVE is hitting you. So insights would upload the information about your system. We'd know that that CVE had not been applied, that you needed to do it. It would automatically generate a playbook that would then patch your system. That would come down into satellite. Satellite would then, let's say, go out and patch those systems for you. Or you could do it with tower as well. No human involvement. No human necessary, yeah. But a lot of people don't like to just let automation take over. So you still get the, I really want to do this button that you can push. But it makes it a lot faster. So then you can, you know. And the alternative is to just manually manage it. Yeah. Take it in. Yeah, in the, I guess pre-ansible days, what you would do is, even if you had insights, that was still a big win because you get the support organization's knowledge that's being automatically given, a report given to you. But you'd get a knowledge-based article that would tell you how to go about fixing the problem. And so you'd take that and manually do it yourself. Now we just generate that playbook and everything happens right away. So Tim, over the last four years or so, we've seen some massive changes in the IT landscapes. When we could go to Red Hat Summit, containerization had a huge impact. Multi-cloud, now we understand how rail fits in all of these environments. The people that are managing environments, most of what they're managing isn't something that they could go touch. So how's that impacting the Ansible marketplace? Well, I think the biggest thing is that because there are so many various systems that you need to be able to manage, the fact that we have the ecosystem available within the Ansible community has just, that has been the biggest part. There's, I shouldn't say there's no way, but it would take an incredible amount of investment if we were going to take the 3,000 modules we had and write those all ourselves and try to maintain those all ourselves. The community coming in and the ISVs who are the experts in those areas are actually building up all of this content and this gives then the users and customers of Ansible that capability of managing across all of those various kinds of ecosystems and hardware and VMs and containers and everything. Yeah, help explain how collections are going to change that relationship of the ecosystem especially I look at the cloud providers. You can't keep up with the deluge of announcements and new solutions that they're pushing out and therefore it would have been tough for Ansible to kind of maintain that on their own. Yeah, yeah, no that's great. So really what, the way collections came about was that we had a tension between the core platform which was changing as rapidly as the modules were and we had a desire from our customers and users that the core platform was pretty solid. We didn't have to keep modifying that as quickly as we were, but the module and the content developers they wanted things coming out faster. So this was a way for us to basically give some relief in that area where we are slowing down the core engine releases and we're speeding up then and we're allowing the people that would own the collections to get those changes and capabilities out much more quickly. What are some of the priorities on the roadmap that you have on engineering? Obviously given the feedback from the community you got customers and community and now you got an ecosystem developing at F5, you got NetApp, you got Cisco, you got IBM, a variety of other vendors are all here and growing, kind of a new stakeholder not a new stakeholder but still a glue layer and integration layer is going to attract partners. Right. What's the roadmap, what's your focus? Yeah, so our focus is really just now expanding that ecosystem, providing that value, giving more advanced analytics back into Ansible. So we really have to grow out now the automation hub itself and the analytics. And when you hear people say glue layer, integration layer, feels like a control plane, nice security network as Stu mentioned or areas that have been plugging in nicely and growing on the security side. What does that mean to you when you hear integration layer as the head engineer? You got to build that, what does that mean? Well, what it really means is having an extremely well-defined set of APIs that are really stable that you can integrate into. And that really is a big part of our focus and then making it very performant. And the feedback from the partners is I want to control it, you want to control it, where's the win, what's the trade-offs with partners? Because people tend to get pretty dogmatic, well, I'm going to own my data. And the problem in say security is is that a lot of these tools aren't sharing data quickly enough, real time is important, so glue layer is pretty important. Yeah, so I would say with the glue layer we don't really have much conflict as with any partners or any of the other users, really. So because it is pretty solid, I would say at this point. And we have such a great decoupling of the module development and roles, other content that's on Galaxy from the core engine itself, right? So for us, it means that we have to allow the experts that understand those modules the capability of being able to manage, deliver those things on their own cadence that makes sense, as long as it continues to work well with the core engine. So that's really what our focus is. And the APIs are critical, make sure they're rock solid, didn't get tested properly. Yeah, and don't change and shift on you so that if you're on older versions that ends up messing you up. I talk about the show, this show is really kind of a chill show, we love the show, it's kind of one of our wheelhouse shows in terms of community, we love going because you can get down and dirty and talk about tech, do deep dives, hallway conversations are very cool. What are some of the things you're seeing? What's the show focus this year? What should people know about the Ansible Fest this year? Why is it so important? Well, to me, Ansible Fest is honestly my favorite event. I've been doing these for years. The first one was in New York City in 2015. That was my first one. I think we only had about 150, 200 people at that. It's a pretty small show. It's just been rapidly growing ever since. And the thing I've always loved about Ansible Fest is the community of people that are here. It really is a user community and they are in love with Ansible. They love what it can do for them and they just want to learn more. I also have a lot of customer meetings while I'm here and from a customer standpoint, usually the kind of feedback we get is how can I get more Ansible usage within my organization? They'll have a pocket of it that has come up and they're really excited about it and they want to expand that to other groups. So instead of maybe other conferences where you're getting a lot of concerns and people want to yell at you, it's more of a love fest, really. I love it. Tim, can you comment on the dynamics of an engineering organization working on a product that is open source and what that project means? Because we heard some feedback from the contributor summit, a lot of engagement, really good attendance from a real diverse ecosystem. So give us your commentary on that. Yeah, I mean, to be perfectly honest, right? One of the things that we are really trying to focus on is enabling the community to do more with less help from us, right? So one of the things that's really important is you have to make sure that as a user, you know what the rules are so that you can get your contributions in as quickly and easily without any questions or concerns as possible. So we've spent a lot of time on making sure that contributions can be as easily accepted as possible. And a lot of that really, honestly, is more process than it is anything technical. You have to know what testing levels are required in and what kind of stability do I need in my modules and what kind of support am I expected to give on that? So once you know what those rules are, it's easier for you to figure out how to contribute as opposed to you think you're done and then it gets rejected and you get frustrated and you give up. Give us what you can. Nice thing about an open source project is people know when things are coming. So platforms announced, it's going to be GA, come November, what directionally should we be looking for by the time we come to AnsibleFest 2020? AnsibleFest 2020, what I would hope to see is that we're going to have much better advanced analytics about how your organization is using Ansible internally and even being able to compare that against other organizations and other companies that are also running. So you can see how you're doing against, let's say your peers in the industry. That's a big one. The other one, of course, is we really want to get more engagement with our partners and others that want to provide collections of content that you can trust. All right, any nuggets from customer discussions either something that might not have gotten talked about on the main stage or just general feedback that you'd share? I think that one of the things that we hear a lot is really around the scale and what we're seeing customers do is scale Ansible out to very large levels, right? So I would say some of the number one requests we have are around making sure that we can scale well, having sort of high availability solutions. I think those are the main things that we get. All right, well, Tim Kramer, thank you so much for all the updates. I look forward to seeing some of those enhancements that you talk about as the platform continues to mature. Be back with lots more coverage here from Ansible Fest 2019 for John Furrier. I'm Stu Miniman. Thank you for always for watching theCUBE.