 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 here in Atlanta, Georgia. I'm Stu Miniman, my co-host is John Furrier, and we're going to dig in and talk a bit about developers, our guest on the program, Prague Dave, who is a senior principal product manager with Red Hat. Thank you so much for joining us. Glad to be here, thanks for having me. All right, so configuration management, really maturing into an entire automation journey for customers today, let's get into it. Tell us a little bit about your role and what brings you to the event. Yeah, so I actually have a very deep background in automation, I started by doing workload automation, which is basically about how to help businesses do their processing. So, right from processing and invoice, how do I create the flows, right, to do that. And we saw the same thing, like automation was just kind of like an operational thing and was brought on just to fulfill the business, make it faster. And next thing you know, it grew like, I don't know, like a wildfire. I mean, it was amazing and we saw the growth and people saw the value, people saw how easy it was to use. Now I think that combination is kicking in. So now I'm focusing more on developers and the DevTools BU at Red Hat and it's the same thing. Yeah, Prague, you know, when you look at IT, you know, automation is not a new term. So we've been talking about this for decades. Talk to us a little bit about how it's different today and you know, you talked about some of the roles that are involved here. You know, how does Ansible end up being a developer tool? Yeah, you know, it's very interesting because Ansible was never really targeted for developers, right? And in fact, automation was always considered like an operational thing. Now what has happened is the entire landscape of IT in a company is available to be executed programmatically. Before it was interfaces were only available for a few programs. Everything else you had to kind of write your own programs to do. And now with the advent of APIs, with really rich CLIs, it's very easy to interact with anything. And not just like in software, you can interact with your network devices, with your infrastructure, with your storage devices. So all of a sudden when everything became available, developers who were trying to run, create applications and needed environments to test, to integrate saw that automation is a great way to create something that can now be replicated and be consistent every time you run it. So the need for consistency and replication drove developers to adopt tools like Ansible. And we were like, you know, because at Ansible, we never marketed to developers. And then we see that, wow, they are really pulling it down. It's great. The whole infrastructure as code, which is one of the key pillars for DevOps, has become one of the key drivers for it. Because now what you're seeing is the ability for developers to say that I can now, when I'm done with my coding, and my application is ready for, say, a test environment or a staging environment, I can now provision everything I need, right from configuring my network devices, getting the infrastructure ready for it. We'd run my test, bring it down, and I can do all of that through code, right? So that really drives the adoption. And the cloud scale has shown customers at scale, whether it's on-premises or cloud or edge, is really going to be a big factor in their architecture. The other thing that's interesting, and Stu and I were talking about this in our opening yesterday, is that you have the networking and the bottom of the stack moving up the stack, and you have the applications kind of wanting to move down the stack. So they're kind of meeting in the middle on this programmability in between them. You know, containers, Kubernetes, microservices, is developing as a nice middle layer between those two worlds. So the networks have to telegraph up data, and also be programmable. This is causing a lot of disruption and innovation. Your thoughts on this is, because now it's NetSecOps, means DevOps, that's DevOps, this is now all that's coming together. Exactly, and what's happening is what we are seeing with developers is that there's a lot more empowerment going on. You know, before, there was a lot of silos, there was a lot of checks and balances in place that kind of made it hard to do things. It was like, okay, this is what you, developers, you write code. We will worry about all this. And now this whole blending that has happened, and developers have been empowered to do it. And now you throw that, okay, the empowerment is great, and with great power comes great responsibility. So can you please make sure that what you're using is enterprise-grade, and it's like, you're not just doing things which will break my environment. So once everybody becomes comfortable, that yes, by merging these things together, we're actually not breaking things. We're actually increasing speed, because what's the number one driver right now for organizations? Is speed with security, right? Can I achieve that business agility so that by the time I need a feature developed, by the time I need a feature delivered in production, and my thought comes for it, I need to close that gap. I cannot have a long gap between that. So we are seeing a lot of that happening. People love automation, they love AI. These are two areas that, it's a no brain. When you talk automation, you talk AI, get it, bring it on, right? Yes, absolutely. What does that mean? So when you think about automation and the infrastructure, that's in the hands of the operators, but also they want to enable applications to do it themselves as well, hence the DevOps. Where is the automation focused? Because that's the number one question. How do I get land, get the adoption, and then expand out across? This seems to be the form of the Ansible's kind of cracked the code on. The organic growth has been there, but now as a large enterprise comes in, I got to get the developers using it, and it's got to be operator friendly. This seems to be the key. The balance has to be there, the kingdom. Yep, no, you're absolutely right. And so when we look at it, what do developers want? So something that's just frictionless to use, very quick, very easy. And so that I don't have to spend a lot of time learning it and doing it. And so we saw that with Ansible. The fact that it's so easy to use, most of everything is in YAML, which is very native to developers. So we see that from the dev perspective, they're very eager now, and they've been adopting it. If you look at the download stats, it tells you there's a lot of volume happening in terms of developers adopting it. What companies are now noticing is that, wait, that's great, but now you have a lot of developers doing their own thing. So there is no way of bringing all this together. So it's like, if I have 20 teams in one line of business and each team tries to do things their own way, what I'm going to end up with is a lot of repeatable, like a lot of work that gets repeated, that gets duplicated. So we see that stuff that we're seeing with collections, for example, what Ansible's trying to bring to the table is like, hey, how do I help you kind of bring things into one umbrella? And how can I help you as a developer decide that, wow, I got like 100 plus engine X roles I can use in Ansible? Well, which one do I pick? And you pick one, somebody else picks something else, somebody creates a playbook with like one separate, you know, one different thing in it versus yours. How do we get our hands around it? And I think that's where we are seeing that. Right, open source standpoint, obviously Red Hat, Ansible doing great stuff. And for the folks in the Ivory Tower, the executives CXOs, they hear Ansible glue layer, integration layer, and they go, wait a minute, isn't that Kubernetes? Isn't Kubernetes supposed to provide all this stuff? Be that. So talk about where Ansible fits in the wave that's coming with Kubernetes. Kubernetes. That Gelsinger at VMware thinks Kubernetes is going to be the dial tone. It's going to be like the TCP IP like protocol is use his words. But there's a relationship that Ansible has with those microservices that are coming. Could you explain that fit? No, you know, you hit the nail on the head that Kubernetes is like, we calling the new operating system. It's like, that's what everything runs on now, right? And it's very easy for us, you know, from a development perspective to say, great, I have my containers, I have my applications built. I can bring them up on demand. I don't have to worry about, you know, having the whole stack of an operating system delivered every time. So Kubernetes has become like the de facto standard upon which things run. So one of the concepts that has really caught a lot of momentum is the operator framework, right? And which was introduced, you know, with the Kubernetes, the later release of 3.x. So what we saw that with an operator framework, it's very easy now for application teams. And we saw a great uptake from software vendors themselves of how do I give you my product that you can very easily deploy in Kubernetes as a container. But I'll give you enough configuration options so you can make it work the way you want to. So we saw a lot of software vendors creating and delivering their products as operators. Now we are seeing that a lot of software application developers themselves, for their own applications want to create operators. It's a very easy way of actually getting your application deployed onto Kubernetes. So Ansible operator is one of the easiest ways of creating an operator. Now there are other options. You can do a Golang operator, you can do Helm. But Ansible operators has become an extremely easy way to get going. It doesn't require any additional tools on top of it. It just requires the operator SDK. It's, you know, you're going to use Playbooks, which you were used to already. And you're going to use Playbooks to execute your application workflows. So we feel that developers are really going to use Ansible operators as a way to create their own operators, get it out there. And this is true for any Kubernetes world. So there's nothing different about, you know, an Ansible operator versus any other operator. No change to Kubernetes, but Kubernetes obviously has the concept of microservices, which is literally non-user intervention. The app's taking care of all the provisioning of services. This is an automation requirement. This feeds into the automation theme. Yes, exactly. And what this does for you is, it helps you, like if you look at operator framework, it goes all the way from basic deployment, which everybody's used to. Like, okay, I want instantaneous deployment, automatically just does it. Automatically recognize changes that I give you in my configuration and go redeploy a new instance the way it should. So how do I automate that? Like how do I ensure that my operator, that is actually running my application, can set up his own private environment in Kubernetes and then he can actually do it automatically when I say, okay, now go make one change to it. Ansible operator allows you to do that. And it goes all the way into the life cycle, the full five phases of life cycle that we have in operator framework, which is all the last ones about autopilot. So auto scale, auto remedy itself. Your application now on Kubernetes through Ansible can do all that. And you don't have to worry about quoting it all. It's all provided to you because of the Ansible operator. Progg, in the demo this morning, I think the audience really resonated with the audience that they talked about some of the roles and how they worked together. And it was kind of, okay, the developers on his side and the developer's expectation is, the infrastructure's not going to be ready. I'm not going to have I need. Leave me alone. I'm going to play my video games until I can actually do my work. And then, okay, I'll get it done and do my magic. Speak a little bit to how Ansible is helping to, break through those silos and having developers be able to fully collaborate and communicate with all their other team members, not just be off on their own. No, yeah, that's a good point. And what is happening is that with developers, like with what Ansible is bringing to the table is giving you a very prescriptive set of rules that you can actually incorporate into your developer flows. So what developers are now doing is that, I can't create an infrastructure configuration without habitually having discussions with the infrastructure folks. And the network team will have to share with me what is the ideal configuration I should be using. So the empowerment that Ansible brings to the table is enable cross-team communications to happen so that there is a prescriptive way of doing things and you can create this automated into an automation and then just set it up so that it gets triggered every time a developer makes a change to it. So internally, they do that. Now other teams come and say, hey, how are you doing this, right? And so, because they need the same thing. I mean, okay, maybe your destinations are going to be different, obviously. But in the end, the mechanism is the same because you are under the same enterprise, right? So you're going to have the same layer of network tools, same infrastructure tools. So then teams start talking to each other. I was talking with a customer and they were telling me that they started with four teams working independently, building their own Ansible playbooks and then talking to the admins. And next thing they know, everybody had the full automation done and nobody knew about it. And now they're finding out and they were saying, wow, I got like hundreds of these teams doing this. So I am, A, I'm very happy, but B, now I would like these guys to talk to each other more and come up with the standard way of doing it. I'm going back to the collections concept, right? That's what's really going to help them. And we feel that with the collections, it's very similar to what we did with operator hub for the OpenShift. It's where we have a certified set of collections so that they're supported by Red Hat. We have partners who contribute theirs and then they're supported by them but we become a single source. So as an enterprise, you kind of have this way of saying, okay, now I can feel confident about what I'm going to let you deploy in my environment and everybody's going to follow the same script. And so now I can open up the flood gates in my entire organization and go for it. Yeah, what about how are people in the community getting to learn from everyone else? When you talk about a platform, it should be if I do something, not only can my organization learn from it, but potentially others can learn from it. That's kind of the value proposition of SaaS. Yes, yes, it is. And having the Galaxy offering out there where we see so many users contributing, we have across a hundred thousand rules out there now. And that really brought the Ansible community together is, it was already a strong community of contributors and everything. But by giving them a platform where they can now have these discussions, where they can see what everybody else is doing, it's the story is where you will now see a lot more happening. Like today, I think it was Ansible is like the top five GitHub projects in terms of pull requests that are happening out there. I mean, the community is so vibrant, it's incredible, like they're driving this change. And it's a community made up of developers, a lot of them. That's what's creating this amazing synergy between all the different organizations. So we feel that Ansible is actually bringing a lot of this together, especially as more and more automation becomes prevalent in the organizations. All right, Parag, I want to give you a final word, Ansible Vest 2019 final takeaways. No, this is great. This is my first one, and I've never been to one before. And this is the energy and just seeing what all the other partners are also sharing, it's incredible. And like I said, like with my backgrounds, automations, all of this, anything automation for me, it's, I think that's also a way to go. All right, well, Parag, thank you so much for sharing the developer angle with us. Thank you very much. For John Furrier, I'm Stu Miniman. Back to wrap up from the cubes coverage of Ansible Vest 2019. Thanks for watching theCUBE.