 Live from Atlanta, Georgia, it's theCUBE. Covering Ansible Fest 2019, brought to you by Red Hat. Welcome back, everyone. It's theCUBE Live coverage in Atlanta, Georgia for Ansible Fest. This is Red Hat's event where all the practitioners come together to the community to talk about Automate for Anywhere. I'm John Furrier with my co-host, Stu Miniman, our next two guests, Robyn Bergeron, principal community architect for Ansible. Now Red Hat and Greg DeKernisburg, senior director of community at Ansible as well. Thanks for coming on. Appreciate it. Thank you. Hey, so we were talking before camera that you guys had, this is a two-day event. We're covering theCUBE. You guys have Ansible Fest, but you had your community day yesterday, the day before the event. People came in early, the core community, heard great things about it. I'd love to get an update. Could you share just what happened yesterday and then we'll get into some of the community. Sure, so for all of our Ansible Fest for a while now, we've started them with a community contributor conference and the goal of that conference is to get together a lot of the people we work with online, right? People we see as IRC NICs or GitHub handles, is to get them together in the same room, have them interact with core members of our team. And that's where we really do make a lot of decisions about how we're gonna be going forward, get really direct feedback from some of our key contributors about the decisions we're making, the things we're thinking about with the goal of involving our community deeply in a lot of the decisions we make. That's the goal. So it's like a working session meets social get-together. That's right, several working sessions and then drinks afterward for those who want the drinks and just hang out time that we don't. By the way, drinks and dairy last night was really good, I caught the end of it. I missed the session, but I caught it. Did you have the peaches? The peaches at all the table? It was good, it was good. But this is the dynamic of community. This is one of the things we know here, not a seat open in the house on the keynote, standing room only, active participant base from this organic Ansible Community, now going mainstream. How are you guys handling it? How are you guys riding this way? Because certainly you're certainly doing the communities which is great for feedback to get from the community, but as you have the commercialized open source and Ansible, it's a tough task. Well, I'd like to think part of it is, I guess maybe it's not our first rodeo, is that what we'd say? I mean, for Ansible I worked at Elasticsearch, doing community stuff. Before that I worked at Red Hat and I was a Fedora project leader, number five. And you were a Fedora project leader, what number was that? Number one. It depends on how you count it, but yeah. You were the one that got us to be able to call it, having a Fedora project leader, so I sort of counted as number one. So we've been dealing with this stuff for a really long time. It's different in Ansible and that, unlike a lot of old school things like Fedora, a lot of this stuff is newer and part of the reason it's really important for us to get some of these folks here to talk to us in person is that, especially, and you saw my keynote this morning where I talked about modularity, a lot of these folks are really just focused on their one little bit and they don't always have as much time. People are working in lots of open source projects now, right? And it's hard to pay deep attention to every single little thing all the time. This gives them a day of, in case you missed it, here's the deep dark dive into everything that we're planning or thinking about and they really are people who are managing those smaller parts all around Ansible, really are some of our best feedback loops, right? Because they're people who probably wrote that module because they're using it every single day and they are hardcore Ansible users, but they also understand how to participate in communities. So we can get those people actually talking with the rest of us who, a lot of us used to be CIS admins, I used to be a CIS admin. Lots of us, you know, a lot of our employees actually just got into wanting to work on Ansible because they loved using it so much at their jobs and when you're not actually CIS admining every day, you lose a little bit of- The front lines were the truth of what's going on. The ground truth is right there. And putting all these people together in a room, make sure that they all also, you know, when you have to look at someone in the eye and tell them news that they might not like, you have a different level of empathy and you approach it a little bit differently than you may on the internet, so. Robin, so I loved in your keynote this morning, you talked about, you know, Ansible, first commit was only back in 2012, so that simplicity of that modularity and the learnings from where open source had been in the past. Yes. Share a little bit, you know, what could Ansible do being a relatively young project that it might not have been able to do if it had a couple of decades of history? Maybe Greg should tell the story about the Funk project. There was a project at Red Hat that we started in 2007 in a coffee shop in Chapel Hill, North Carolina. It was myself and Michael Dahan and Seth Vidal and Andrew Likens who still works with us at Ansible. And we put together an idea with all the same underpinnings, right? A highly modular automation tool. We debated at the time whether it should be based on SSL or SSH for Funk, we chose SSL. And, you know, after watching that grow to a certain point and then stagnate, and it being inside of Red Hat where, you know, there were a lot of other business pressures, things like that, we learned a lot from that experience and we were able to take that experience. And then in 2012, there was, the open source community was a little different, open source was more acceptable, GitHub was becoming a common platform for open source project hosting. And so a lot of things came together in a short period of time, all that experience, all of those. And also market conditions had changed, right? Like in 2007, cloud was sort of a weird thing that not really everyone was doing. 2012 rolls around, everyone has these cloud images and they need to figure out how to get something in it. And it turns out that Ansible's a really great way to actually do that. And, you know, even if we had picked SSH back in the beginning, I don't know, you know, sometimes projects grow to a certain point and I can point to lots of projects that were just, it's a shame that they were so ahead of their time. And because of that, you know, money ran out or people moved on. Timing's everything, but the key I think now what I've always admired about the simplicity is automation requires that they abstract the way the complexities. And so I think you bring up cloud that brings up more complexity, more use cases for some of the underlying pinnings of the plumbing. And this is always going to, this is a moving train that's never going to stop. What was the feedback from the community this year around as you guys get into some of these analytical capabilities? So the new features have a platform flair to it. It's a platform you guys announced, Ansible Automation Platform. That implies that enables some value. You know, I think in a way, we've always been a platform, right? Because a platform is a set of small rules and then modules that attach to it. It's about how that grows, right? And traditionally, we've had a batteries included model where every module and plug-in was built to go into Ansible. Boy, that got really big, right? And so- Yeah, we're like, we're at, I don't even know how many thousands of modules. I keep saying, I'll say 2,000, then it'll be 3,000. I say 3,000, that was something else. It's a lot of content. And it's, you know, in the beginning it was, I can't imagine this ever being more than 200, 250 batteries included. And at some point, you know, it's like, hmm, yeah, taking care of this and making sure it all works together all the time gets more and more difficult. You guys have done a great job with the community. And one of the things that you mentioned with Cloud is, as more use cases come, scale becomes a big question. And there's real business benefits now. So Open Source has become part of the business. People talk about business models with Open Source. You guys know that. You've been part of that 28 years of history with Linux. But now you're seeing DevOps, which is, you know, go back to 2007, eight, nine, 10 time frame, you know, only the purists were talking DevOps at that time. Infrastructure as code was being kicked around. We certainly been covering the cubes as 2010 on that. But now in mainstream enterprise, it seems like the commercialization and operationalizing of DevOps is here. You guys have a proof point in your own community of people talking about culture, about relationships. We have one guest on talking about, they're now friends with the other guys. And grew at Cal's. So you see the collaborations now becoming a big part of it because of the playbooks, because of these instances. So talk about that dynamic of operationalizing the DevOps movement for enterprise. All right, so I remember an example at one of the first AnsibleFest I ever went to. There were a few before I came on board. But it was, I think it was the first one I came to when I was about to make the jump from my previous company. And I was just there as a visitor and a friend of the team. And there was an admin who talked to me and said, for the first time, I have this thing, this playbook, that I can write and that I can hand to my manager and say, this is what we're gonna do, right? And so there was this artifact that allowed for a bridging between different parts of the organization. That was the simplicity of that playbook, that was human readable, that he could show to his boss or to someone else in the org that they could agree on. And suddenly there was this sort of a document that was a mechanism for collaboration that everyone could understand and buy into that hadn't really existed before Ansible existed. For me, that was one of the many flip of the light moments where I was like, oh, wow, maybe we have something really big. There were plenty of other infrastructures, code things that you could hand to someone. But for a lot of people, it's like, I don't speak that language, right? And that's why we like to say Ansible's sort of this universal automation language, right? Like everybody can read it. You don't have to be a rocket scientist. It's great for your exact example, right? I'm showing this to my manager and saying, this is the order of operations and you don't have to be a genius to read it because it's really, really readable. It's connecting systems which connects people. That's right. What's fascinating to me is there was this whole wave of enterprise collaboration tools that the enterprise would try to push down and force people to collaborate. But here is a technology tool that from the ground up is getting people to do that collaboration and they want to do it and it's helping to break down some of those walls. Well, and it's interesting, you mentioned that and I'm sure that something like Slack is a thing that falls into that category and they've built a business around making sure that the 20 billion people inside a company all sign up until somebody in the IT department's like, what do you mean these random people are just all, everyone's using it and no one's saving it and is it secure and they all freak out? And well, I mean, this is sort of, you know, everybody tells their friend about Ansible and they go, oh, right, tool that's going to save the world number 22. Oh wait, actually, yeah. No, this is, this actually is pretty cool. Yeah, yeah, it gets started in 15 minutes. Well, you know, sometimes a better mouse trap will always drive people to that solution. You guys have proven that organic. What's interesting to me is, not only does it keep win on capabilities, it actually grew organically in this connected tissue between different groups. Right. It takes down that whole silo mentality and that's really where IT's been stuck. Yes. And as software becomes more prominent and data becomes more prominent, it's going to just shift more power in the hands of the developer. Yeah. And to the sys admins who are now being redeployed into being systems architects or whatever they are. I mean, this transitional human roles with automation. Digital transformation architect. Oh my God. Yeah. I'll be entitled now. That's a real title. Yeah. You pay me. I don't have it, but. Just double my pay. I'll take it. All right. So, collections is one of the key things talked about when we talk about the Antelope Automation Platform. I've been hearing a lot of discussion about how the partner ecosystems really stepping up even more than before. You know, 4,600 plus contributors out there in community, but the partner stepping up. But where do you see this going? Where will collections really catalyze the next growth for your... It's got to be the future for us. You know, there were a few key problems that we recognized that collections was ultimately the solution that we chose. You know, one key problem is that with the batteries included model, that put a lot of pressure on vendors to conform to whatever our processes were. They had to get their batteries into our thing to be a part of the ecosystem. And there was a huge demand to be a part of our ecosystem. So partners would just sort of swallow hard and do what they needed to do. But it really wasn't optimized to help partners, right? So they might have different development processes. They might have different release cycles. They might have different testing on the back end that would be more difficult to hook together. Collections breaks a lot of that out and gives our partners a lot of freedom to innovate in their own time. Release on their own cycles, right? Release on their own cycle. We just released our new version of software. But you can't actually get the new Ansible modules that are updated for it until Ansible releases is not always the thing that, you know. Right. Makes their product immediately useful. You know, if you're a vendor, you release something new, you want people to start using it right away. Not wait until, you know, Ansible comes around, so. And that new artifact also creates more network effects with, you know, Galaxy and Automation Hub and the new deployment options that we're going to have available for that stuff. So it's, I think it's just leveling up, right? It's taking the same approach that's gotten us this far and just taking out to another level. But I certainly wouldn't consider it to be like that partners are separate part of our, they're still definitely part of the community. It's just, they have slightly different problems. And, you know, there were folks from all sorts of different companies who are partners in the contributor summit yesterday. Yeah, they were excited. We're actually, you know, participating and, you know, folks swapping stories and listening to each other and, again, being part of that feedback loop. Yeah, maybe just a little bit broader. You know, the other communities out there, I think of the Cloud Native Computing Foundation, the Open Infrastructure Foundation, you're wearing your Zoolpin. Talk a little bit about how Ansible plays across these other communities, which are, you know, very much a mixture of the vendors and the end users. Well, I mean, Ansible certainly had, sorry, are you asking about how Ansible is relating to those other communities? Okay, yeah, because I'm all about that. I mean, we certainly had a long-standing sort of fan base over in OpenStack slash Open Infrastructure Foundation land. Most of the deployment tools for all of, you know, all the different ways, so many ways to deploy OpenStack. A lot of them wound up settling on Ansible towards the end of time as, you know, that community has sort of matured and, you know, there was a lot of periods of experimentation and, you know, that's one of those things is some things lived, some things didn't, but the core parts of what you actually need to make a cloud are, you know, basically still there. And then we also have a ton of modules, actually in Ansible that, you know, help people to operationalize all their OpenStack cloud stuff, just like we have modules for AWS and Google Cloud and Azure and whoever else I'm leaving out this week. As far as the CNCF stuff goes, I mean, again, we've seen a lot of, you know, how to get this thing up and running. Turns out, Kubernetes is not particularly easy to get up and running. It's even more complicated than a cloud sometimes because it also assumes that you've got a cloud of some sort already and I like working on our thing. I can actually use it. It's pretty cool. CubeSpray and then a lot of the other projects also have, you know, things that are related to Ansible and now there's the Ansible operator stuff. I don't know if you want to touch on that, but. Yeah, we're working on, you know, one of the big questions is how do Ansible and OpenShift slash Kubernetes work together? Frequently in sort of Kubernetes land, OpenShift land, you want to keep as much as you can on the cluster, lots of operations on the cluster. Sometimes you got to talk to things outside of the cluster, right? You got to set up some networking stuff or you got to go talk to an S3 bucket. There's always some storage thing. As much as you try to get things into container land, there's always legacy stuff. There's always new stuff, maybe edge stuff that might not all be part of your cluster. And so one of the things we're working on is making it easier to use Ansible as part of your operator structure to go and manage some of those things using the operator framework that's already built into Kubernetes and OpenShift. And more complexity out there. Well, and the thing is, we're great glue. Ansible is such great glue and it's accessible to so many people. And as we move away from monolithic code bases to microservices and vastly spread out code bases, it's not like the complexity goes away. The complexity simply moves to the relationship between the components. And Ansible is excellent glue for helping to manage those relationships between components. Who doesn't like a glue layer? Everyone, if it's good and easy to understand, even better. The glue layer is key. Guys, thanks for coming on, Bob and Greg, sharing your insights. Thank you so much. Take a quick minute to give a quick plug for the community. What's up, stats, updates, quick projects. Give a quick plug for what's going on in the community real quick. You go first. We're big, we're a few, six, seven, well. It was number six. Number seven was Kubernetes. Right, number six out of 96 million projects on GitHub, so lots of contributors, lots of energy. Anytime I try to cite a stat, I find that I have to actually go and look it up and I was about to cite, again, the wrong. So active, high numbers of people, activity. Lots of activity. I mean, you're running the plumbing, so obviously it's cloud and on-premise. Other updates, projects, or the contributor day, what's next, what's on the schedule? We're looking to put together our next contributor summit. We're hoping in Europe sometime in the spring, so we've got to get that on the plate. I don't know if we've announced the next Ansible Fest yet. I know that happens tomorrow, so don't ruin that. I won't ruin that for everybody. Congratulations on a great community. You guys done great work. Obviously open source, open business, open everything these days. Bed against open. It's hard to get to bed against open. I wouldn't bed against open. We're here, CUBE, we're open. We're sharing all the data here in Atlanta with the interviews. I'm John Furrier with Stu Miniman State with us for more after this short break.