>> Narrator: Live from Atlanta, Georgia, it's theCUBE, covering Ansible Fest 2019. Brought to you by Red Hat. >> Welcome back, this is theCUBE's live coverage of Ansible Fest 2019, here in Atlanta, Gerogia. 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, Parag Dave, who is senior principle product manager with Red Hat. Thank you so much for joining us. >> Glad to be here, thanks for having me. >> Alright, so configuration management, really maturing into an entire automation journey for customers today, lets 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 worker automation. Which is basically about how to help businesses do their processing. So, from processing an invoice, how do I create the flows to do that? And we saw the same thing, like automation was just kind of like a 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 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 depth tools used at Red Hat and it's the same thing. You know, Parag, you know when you look in IT, you know Automation is not a new term. It's like 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, how does Ansible end up being a developer tool? >> Yeah, you know you see, it's very interesting, because Ansible was never really targeted for developers, right? And in fact, automation was always considered like an operational thing. Well, 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, but now the advent of API's, you know with really rich CLI's it's very easy to interact with anything and not just like in software, you can interact with the other network devices, with your infrastructure, with your storage devices. So, all of the sudden when everything became available, developers who were trying to create applications and needed environments to test, to integrate, saw that automation is a great way to create something that cannot be replicated and be consistent every time you run it. So, the need for consistency and replication drove developers to adopt to the Ansible. And we were, you know cause they had the Ansible, we never marketed to developer and then we see that wow, they are really pulling it down, it's great. The whole infrastructure is code, which is one of the key pillars for devOps has become one of the key drivers for it, because now what you are 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, run my test, bring it down, and I can do all of that through code, right? So, that really drives the adoption for Ansible. >> And the could scale has shown customers at scale, whether its 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 were talking about this on our opening yesterday, is that you have the networking and the bottom of that 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 in 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 evasion. >> Parag: Absolutely. >> You're thought on this, 'cause it's DevSecOps beefs 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 like a lot of silo's, there was like a lot of checks and balances in place that kind of made it hard to do things. It was okay, this what you, developers you write code, we will worry about all this. And now, this whole blending that has happened and developers being empowered to do it. And now, the empowerment is great and with great power comes great responsibility. SO, can you please make sure that you know, what you're using is enterprise grade, that it's going to be you know, you're not just doing things with your break environment So, once everybody become comfortable that yes, by merging these things together, we're actually not breaking things. You're actually increasing speed, 'cause 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 develop, by the time I need a feature delivered in production and my tool 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-brainer. When you have automation, you talk AI, yeah bring it on, right? What does that mean? So, when you think about automation 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 focus? Because that's the number one question. How do I land, get the adoption, and then expand out across. This seems to be the form that 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 key to the kingdom. >> Yeah, no you're absolutely right. And so, when you look at it, like what do developers want? So, something that is 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, right? And so we saw that with Ansible. It's like the fact that it's so easy to use, it's most of everything is in YAML. Which is very needed for developers, right? So, we see that from their perspective, they're very eager now, and they've been adopting it, if you look at the download stats it tells you. Like 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 we have a lot developers doing their own thing. So, there is now like way of bringing all this together, right? 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, you know like a lot of work that gets repeated, I say it's duplicated. So, we see that's what we are seeing with collections for example. What Ansible is trying to bring to the table is okay, 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 extra rolls 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 happen. >> Right open star standpoint. I see Red Hat, Ansible doing great stuff and for the folks in the ivory tower, the executive CXO'S. They hear Ansible, glue layer, integration layer, and they go, wait a minute isn't that Kubernetes? Isn't Kubernetes suppose to provide all this stuff? So, talk about where Ansible fits in the wave that's coming with Kubernetes. Pat Gelsinger at VMware, thinks Kubernetes is going to be the dial-tone, it's going to be like the TCP/IP like protocol, to use his words, but there's a relationship that Ansible has with those Microservices that are coming. Can you explain that fit? >> You hit the nail on the head. Like, Kubernetes is like, we call it 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 defactual standard upon which things run. So, one of the concepts that has really caught a lot of momentum, is the operator framework, right? Which was introduced with the Kubernetes, the later Razor 3.x. Some of that, and operator framework, it's very easy now for application teams. I mean, it's not a great uptake from software vendors themselves. How do I give you my product, that you can very easily deliver on Kubernetes as a Container, but I'll give you enough configuration options, you can make it work the way you want to. So, we saw a lot oof 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 extremely easier to get going. It doesn't require additional tools on top of it. Just because the operator SDK, you know, you're going to use playbooks. Which you're 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. >> With no chains to Kubernetes, but Kubernetes obviously has the cons of the Microservices, which is literally non-user intervention. The apps take of all provisioning of services. This is an automation requirement, this feeds into the automation theme, right? >> 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 deployers, everybody's use to, like okay, I want instantaneous deployment, automatically just does it. Automatically recognize changes that I give you in reconfiguration 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 it's own private environment in Kubernetes and then it 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 the operator framework. Which is the last one's about autopilot. So, Autoscale, AutoRemedy itself. Your application now on Kubernetes through Ansible can do all that and you don't have to worry about coding at all. It's all provided to you because of the Ansible operator. >> Parag, in the demo this morning, I think the audience really, it resonated with the audience, it talked about some of the roles and how they worked together and it was kind of, okay the developers on this side and the developers expectation is, oh the infrastructure's not going to be ready, I'm not going to have what 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 silo's and having developers be able to fully collaborate and communicate with all their other team members not just be off on their own. >> Oh yeah, that's a good point, you know. And what is happening is the developers, like 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 a infrastructure contribution without actually having discussions with the infrastructure folks and the network team will have to share with me what is the ideal contribution I should be using. So, the empowerment that Ansible brings to the table is enabled cross team communications to happen. So, there is prescriptive way of doing things and you can create this all into an automation and then just set 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, 'cause they need they same thing. Maybe you're 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 to the 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, A, I'm very happy, but B, now I would like these guests to talk to each other more and come up with a standard way of doing it. And going back to that collections concept. 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 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 floodgates in my entire organization and go for it. >> Yeah, what about how are people in the community getting to learn form everyone else? When you talk about a platform it should be if I do something not only can by organization learn from it, but potentially others can learn from it. That's kind of the value proposition of SaaS. >> Yes, yes it and having the galaxy offering out there, where we see so many users contributing, like we have close to a hundred thousand rolls out there now and that really brought the Ansible community together. It was already a strong community of contributors and everything. By giving them a platform where they can 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 Get Up projects in terms of progress that are happening out there. I mean the community is so wide run, it's incredible. Like they're driving this change and it's a community made up of developers, a lot of them. And that's what's creating this amazing synergy between all the different organizations. So, we feel that Ansible is actually bringing a lot of us together. Especially, as more and more automation becomes prevalent in the organizations. >> Alright, Parag want to give you a final word, Ansible Fest 2019, final take aways. >> No, this is great, this is my first one and I'd never been to one before and just the energy, and just seeing what all the other partners are also sharing, it's incredible. And Like I said with my backgrounds automations, I love this, anything automation for me, I think that's just the way to go. >> John: Alright, well that's it. >> Stu: 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 theCUBe's coverage of Ansible Fest 2019. Thanks for watching theCUBE. (intense music)

>> Announcer: Live from Boston, Massachusetts, it's theCUBE. Covering Red Hat Summit 2019. Brought to you by Red Hat. >> Good to have you back here on theCube we are live in Boston at the Convention Center here. Along with Stu Miniman, I'm John Walls and on theCUBE we're continuing our coverage of Red Hat Summit 2019 in Boston, as I said. Joined now by Reza Shafii, who is the VP of Platform Services at Red Hat. Former CoreOS guy >> That's right. >> Stu actually has his CoreOS socks on, >> He told me. >> Today, yeah, so he came dressed for the occasion. >> Shh, can't see those on camera, John. I can't be wearing vendor here. >> Don't show it to the camera. >> Well I just say they're cool! They're cool. Glad to have you with us, Reza. And first off, your impression, you have a big announcement, right, with OpenShift. OpenShift 4 being launched officially on the keynote stage today. That's some big news, right? >> It's a big deal, it's a big deal. The way I think about it is that it's really a culmination of the efforts that we planned out when we sat down between the CoreOS leadership team and the Red Hat leadership team, when the acquisition was closed. And we planned this out, I remember a meeting we had in the white board room. We planned this out. In terms of bringing the best of OpenShift and CoreOS technology together. And it's really great to see it out there on the keynote, and actually all demoed and working. >> And working, right? Key part. >> Reza, dig in for us a little bit here, because it's one thing to say okay, we got a white board and we put things together. You know, when I looked at both companies, at first both, CoreOS before the acquisition and Red Hat, I mean open source, absolutely as its core. I remember talking to the CoreOS team, I'm like, you guys are gonna build a whole bunch of really cool tools, but what's the business there? Do you guys think you're gonna be the next Red Hat? Come on. Well, now you're part of Red Hat. So, give us a little bit of the insight as to what it took to get from there to the announcements, CoreOS infused in many of the pieces that we heard announced this week. >> Yeah, so the way I like to think about it is that Red Hat's OpenShift's roots, it started with making sure that they create a really nice comfortable surface area for the deaf teams. The deaf teams can go in and start pushing the applications and it just ensures that it's running those applications in the right way. The CoreOS roots came from the operations perspective and the system administrator. We always looked at the world from the system administrator. Yes, you're right, CoreOS had a number of technologies they were working on, etcd, Rocket, clair. I used to joke that there's a constellation of open source services that we're working on, but where is the one product? And, towards the end, right before the acquisition, the one product I think was pretty clear is Tectonic, the Kubernetes software. Now, if you look at Tectonic, the key value difference was automated operations. The core tenants of what Alex Polvi and Brandon Philips said into the mindset of the company was we're outnumbered, the number of machines out there is going to be way more than we can handle, therefore we need to automate all operations. They started that on the operating system itself, with CoreOS, the namesake of the company. And then they brought that to Kubernetes. What you see with OpenShift is, OpenShift 4, you see us bringing that to, not only the Kubernetes core, that's the foundation of OpenShift 4, so all capabilities of running Kubernetes are automated with 20 plus operators now. But you see that apply to all the other value capabilities that are on top of OpenShift as well, and we're bringing that to ISV. I was walking around and a number of ISV's have their operators as the number one thing they're advertising. So you're seeing automated operations really take hold and with OpenShift 4 being a foundation for that. >> You talk about operations or operators, you have Operator Hub that was launched earlier this year, what was the driving force behind that? And then ultimately what are you trying to get out of that in terms of advancement and going forward here? >> Right, I think it means it's worked. Going back a little bit of history on this, the operator pattern was coined at CoreOS as a way to do things on a Kubernetes cluster to automate operations. The right way. You have to expose it as a proper API, you have to use a controller, so on and so forth. Then as the team started doing that we realized well there's a lot of demand for this pattern, we started documenting it, describing it better and so on. But then we realized there's a good case for a framework to help people build these automations. Therefore we announced the operator framework at Cubeacon. I think it was a year and a half ago. What happened then was interesting, suddenly we started seeing hundreds plus operators being built on the operator framework. But, it was hard because you could see five Redis operators, 10 MySQL operators. It was hard for our customers to know where can I find the right set of operators that have the right functionality and how do they compare to each other? OperatorHub.IO is a registry that we launched together with AWS, Google and Microsoft to solve for that problem. Now that we have a way to create operators easily and capture that automated operations, we have sort of created a pattern and a framework around it, where do you go to find the right set of operators. >> It's an interesting point because if you look in the container space, especially Kubernetes, it's like, okay well what's standardized, what works across all of these environments? We always worry, I've probably got some pain from previous projects and foundations as to well what's certified and what's not and how do we do that? So, did I see there's a certification now for operators and how do you balance that we need it to work everywhere, we don't wanna have it's Red Hat's building an open ecosystem not something that's limited to only this? >> Yes. So OperatorHub.IO is a community initiative. And, every operator you find on there should work on any Kubernetes. So in fact as part of the vetting process we make sure that that's the case. And then on the certification we launched today, actually, and you can see a number of, we have already 20 plus operators that are certified. This is where we take it a step further and we work with the vendors to make sure that it works on OpenShift. It's following a number of guidelines that we have, in terms of using, for example, Rail as the basis. They work with us to run the updates through security checks and so on. And that's just to give our enterprise customers more levels of guarantees and validation, if they would like to. >> So what are they getting out of that, out of the certification system? What, I guess, stability and certainty and all those kinds of things that I'm looking for, standardization of some kind, is that what's driving that? >> It's simple, at the end of the day they got three things. They get automated updates that are pushed through the OpenShift update mechanism. So if you are using the Redis one, for example, and it's certified, you're gonna be able to update the Redis operator through the same cluster administration mechanism, then you would apply it to the entire cluster itself. You see updates from Redis come in, you can put it through the same approval work so on, so on. The second is they get support. So they get first line of support from Red Hat. They can call Red Hat, our customers and actually we work with them on that. And the third is that they actually get that security vulnerability scans that we put them through to make sure that they pass certain checks. And actually one last one, they also get Rail as the basis of the operator, so, yup. >> Reza, help bring us into the customer point of view. What does all this mean to them, what are the big challenges, how do they modernize their applications and get more applications moving along this path? >> Yeah, in this case the operator customer is mainly the infrastructure administrators. It's important to point that out. The developers will get some benefit on that in that it's self service, so the provision, but there's other ways to do that as well. You can go to a Helm chart, deploy that Helm chart, you get that level of self service automated provisioning. To go ahead and configure for example, a charted MongoDB database on a Kubernetes cluster, you have to create something like 20 different objects. And then to update that to change the charts, you have to go and modify all those 20 different objects. Let's just stay at that level alone. An operator makes that before different parameters on a yaml file that you change. The operator takes that and applies all these configurations for you. So, it's all about simplifying the life of the infrastructure administrators. I truly believe that operators, human operators, infrastructure administrators are one of the least appreciated personas right now that we have out there. They're not the most important ones, but there is a lot of pain points and challenges that they have we're not really thinking about too much. And I think OpenShift goes a long way and operators go a long way to actually start thinking about their pain point as well. >> So what do you think their reaction was this morning when they're looking, first off, the general announcement, right? And then some of the demonstrations and all those things that are occurring? Is there, do you have or are you talking to customers? Are you getting the sense of relief or of anticipation or expectation? I mean, how would you characterize that? >> Think they're falling into a couple of different buckets. There's the customers we've talked to, for awhile now, that know this stuff, so this is not super new to them, but they're very happy to see it. There's one big automaker that's a customer of us and the main human operator was telling me awhile ago that he does not want any service on the cluster unless it has an operator, this is a year and a half ago. And he kept pushing me well I want a Kafka one and I want an Elasticsearch one, and you know. And we, CoreOS, were too small to try to build that ourselves. Obviously that's not, we can't maintain a Kafka operator and a CoreOS one. Now, he's able to go to our operator APP, he's gonna be able to get a Kafka operator that's maintained by Kafka experts. He's gonna be able to get a Redis operator that's maintained by Redis experts. So that bucket of customers are super happy. And then there's another one that's just starting to understand the power of all this. And I think they're just starting to kick the tires and play around with this. Hopefully they will get to the same point as the first bucket of customers, and be asking for everything to be operator based all the time. >> Convert the tire kickers, you're gonna be okay, right? >> That's right. >> Thank you for the time. >> Thank you. >> We appreciate that and continued success at Red Hat, and, once again, good to see you. >> Thank you, always a pleasure. >> You bet. Live, here on theCUBE, you're watching Red Hat Summit 2019. (upbeat music)