 Welcome back to the Red Hat Summit 2021 virtual coverage. I'm John Furrier, this is theCUBE coverage I'm in Palo Alto with the remote interviews for our virtual conference here. We've got two great guests, CUBE alumni's Tommy Anderson, VP of Ansible Automation Platform and Robin Bergeron who's the senior manager Ansible Community Architect and all the great things involved. Robin, great to see you, Tom. Thanks for coming back on Red Hat Summit this year virtual. Good to see you. Thanks for having us. So since last summit, what's the updates on the Ansible Community and the Automation Platform? Tom, we'll start with you, Automation Platform. What's the big updates? Yeah, so since last summit a lot has happened in the Ansible land, if you will. So last summer we were talking about content clutches, packaging and distribution format for the integrations that ends this course. So we spoke a lot about how we're going to bring all of the ansible content up to these clutches and making it a community as well as commercial users. And we launched last year a working program, certified content program. We're working with our business partners and community partners to certify the content collections that they create, fill certify them where we work together to make sure that they're developed against and tested against a proper spec so that both of us can provide them to our customer basis with the confidence that they're going to be working and performing properly and that we Red Hat and our partners co-support those out in our customer's production department. So that was a big deal. The other thing that we announced late last fall was the private automation hub. And that's the idea where our customers obviously appreciate the idea of being able to go to Ansible Galaxy or the Ansible Automation Hub to go and grab these content collections, these integrations and bring them down in their environment. They wanted a methodology or a repository where they could curate content from different sources and then manage it across their environment, the automation across their environment. Kind of leaning into a little bit of automation content as code, if you will. And so we launched the automation hub, the private automation hub, where that sits in our customer's infrastructure, whether that's in the cloud or on-premise for both and allows them to grab content from Galaxy from the Ansible Automation Hub, the Ansible Automation Hub on cloud.redhat.com as well as their internally developed content and be able to manage and provide that across their organization governed by a set of policies. So lots of stuff is going on, real advancements in the amount of content that we provide, the amount of collections that we provide that are certified by our customers and this ability to curate and manage that content across their teams. I want to do a drill down on some of the unification of teams which is a big message as well as operating at scale because that's a super value proposition you guys have and I want to get into that. But Robin, I want to come back to you on the community so much has gone on. We are now into the pandemic for almost a year and a half now. It's been a productivity boom. People, developers have been working at home for a long time so it's not a new workflow for them but you've seen a lot more productivity. What has changed in the community since last summit? Again, virtual to virtual again between the windows here, event windows. You guys have a lot going on. What's new in the community? Give us an update. Yeah, well, I mean, if we go back to summit this time-ish last year, we were wrapping up more or less the, it was, we used to have everything, you would install Ansible, you would get all the modules, you would get everything, it was all together which was great for new users who don't want to have to figure things out. It helps them to really get up and started running quickly. But it was from a community perspective trying to manage that level of complexity turned out to be pretty hard. So the move to collections was actually great for, not just for a user perspective but also from a community perspective. And we came out with Ansible 210 that was last fall, I believe. And that was the first real release of Ansible where we had collections were fully instantiated. They were available on Galaxy but you could also get them as part of the Ansible community distribution. Fast forward to now, we just had the Ansible 3.0 release here in February and we're looking to Ansible 4.0 here in early May. So there's been a lot of activity. A lot has improved honestly as a result of the changes that we've made. It's made it a lot easier for contributors to get in with a smaller group that's more their size and be able to get started and identify who are their interested peers in the community. So that's been a boon for us, honestly. The pandemic otherwise is, I think taught all of us, certainly you John, about the amazing things that we can do virtually. So we've had a lot of our meetups pivot to being virtual meetups and things like that. And it's been great to see how easily the community's been able to pivot around this sort of event. I hope that we don't have to just keep practicing it for forever, but in the meantime, it's enabled us to continue to get things done. Thank goodness to every video platform on earth. Well, we appreciate it. We're going to come back and talk more about that in the future, what best practice, what we all learned and stories. But I think I want to come back to you on the persona side of Ansible, because one of the things we talked about last time that season began, a lot of traction is that multiple personas. So I want to just hold off that we'll come back. Tom, back to you, we're at Red Hat Summit. You guys have Ansible Fest, which is your own event that you guys drilled down on this. So users watching can know this, your own community. But now we're part of Red Hat, part of IBM, which IBM thinks also happening soon as well. Red Hat Summit is still its unique event. How is Ansible fitting into the big picture? Because the value proposition of unifying teams is really consistent now with Red Hat's overall arching thing, which is operating at scale, open shift, Robin just mentioned. Where is the automation platform going this year? What's the story here at Red Hat Summit for the automation platform? Yeah, that's a great question. We've seen so in the kind of timeness a little bit of the pandemic and how it has accelerated some existing trends that we already saw. And one of those is really around the democratization of the application delivery teams. More people delivering infrastructure and applications independent of each other, which is great, faster, more agile, all of those other good words that apply to that. But what that does bring up is the opportunity for application of work, replication of effort, not reusing necessary things that are in existence already that other teams may have. Maybe not complying with all of the policies, if you will, but configuration and compliance policies. And so it's really kind of brought Ansible out into focus even more here because of the kind of common back-plane it has to provide. It's a common language and a common automation back-plane across these different teams and across these different personas. And the great thing about what we supply for these different personas, whether it's application developers and infrastructure owners, network engineers, SecOps teams, Geodox teams, there's so many of these ops teams out there who now all want independent access to infrastructure and deploying infrastructure. And Ansible has the kind of levers that each of those can use, whether it's APIs or CLIs or an event-based automation or webhooks, et cetera, et cetera. Service catalogs, UIs, all of those interfaces, if you will, are modalities or accessible into Ansible automation. So it's really allowed us to be this sort of connective tissue of blue across these different silos or domains of the organization. And kind of tying it into open-ships specifically, one of the things that we talked about last fall at our Ansible Fest was our integration between Ansible, the Ansible automation platform, our advanced cluster management product and our open-ship platform that allows native applications running on open-ship to be able to talk to a Ansible automation operator that's running on that same platform to do things on platform for it that our customers are already using Ansible for. So connecting their cloud-native platforms with their existing IT ecosystems and infrastructures, systems of records, network systems, ticketing systems, you name it. So all of those sort of integrations, Ansible has become the connective blue across all of these different environments, tying traditional IT, cloud IT, cloud native, you name it. So it's really been fun and it's been an exciting time for us inside the portfolio and out. That's a great point. Connective tissue is a great way to describe some of these platform benefits because you guys have been on this platform for a really long time and the benefits are kind of being seen in the market certainly as people have to move faster with the agility. Rob, and I want to come back to you because you brought up this idea of personas. I mean, we all know DevOps, infrastructure as code has been our religion for over a decade or more, but now the word DevSecOps is more prevalent in all the conversations. The security is now weaved in here. How are you seeing that play out in the community? And then Tom, if you can give some color commentary too on the automation platform, how security fits in. So DevOps, everything's being operationalized at scale. We get that. That's one of the value propositions you have, but DevSecOps is a persona. More people want more sec. Dev is great, more ops and standardization, more developers agile standards, and then security DevSecOps. What's your? I thought it was DevNetSecOps. Okay, I forgot net, it was putting that in there. Well, network's abstracted away, as we said. Yeah, well, from my perspective, people in their jobs all over the places, right? The more they can feel like they're efficient and doing great stuff at their work, they're happy to bring as many people into the fold as possible, right? And normally security's always been this, sort of like networking, right? It's always been this sort of isolated, this special group over here that's the traditional, one of the traditional IT bottlenecks that causes us to not be able to get anything done, but on a community level, we see folks who are interested in security all the time. I know we've certainly done quite a bit of work with some folks at IBM around one of their products, which I assume Tom will get more into here in just a moment, but from a community perspective, I mean, we've seen people who've been writing playbooks and roles and now collections for all the traditional government testing is our missed standards, all of that kind of stuff. And it's one of those, it's part of network effects and it's a great place. We're actually Automation Hub, I think for folks who are on-prem or any of our customers are really gonna start to see lots of value is how it will be able to connect folks inside the organization organically through just the place where I'm doing my Ansible things, allows them to find each other, really, and build those, take it from being silos of automation everywhere into a really sort of networked, an internal network of Ansible friends and Ansible power users that can work together and collaborate just the same way that we do an open source. And Tom, so IT modernization requires security, what's your take on this? Because you got a lot of cluster, advanced cluster management issues, you got to deal with the modern apps that are coming, IT's got to evolve. What's your take on all this? Yeah, not only does IT have to evolve, but it sets a integration of IT into the rest of the environment to be able to respond to security effects. So in the areas that we put a lot of effort into, with Ansible in terms of curating solutions around Ansible security automation, we've talked about that in the past, the idea of connecting the SecOps teams that are doing intrusion detection or threat hunting, and then responding in an automated way to those threat protections, right? So connecting the SecOps with IT, which is traditionally been siloed operations and siloed teams, and now with this curated Ansible security automation solution that we've got to market with our partners, it connects those two teams in a seamless sort of way, and we've done a lot of work with our friends that I am around this area because they are big in that security area with their resilience and QADAR, and other products in their portfolio. So we've done a lot of work with them, but we've done a lot of work with lots of our partners whether it's cyber, or Microsoft, or whoever, we've done a lot of work in those areas. So traditionally, Ansible has done a great job on sort of compliance around configuration, enforcement, threat setting, and enforcement configuration. Now we've looked at the connecting SecOps with IT, security automation, and now with our acquisition of SecOps, along with our advanced cluster management integration with Ansible, we're starting to say, what are the things inside that Dev SecOps workflow that may require integration with the core automation, package automation, automation with other parts of the environment? So we're bringing all of those pieces together as we move forward with the spirit setting for us. Okay, I got to ask you guys the number one question that I get all the time, and I see in the marketplace kind of a combo question, is how do I accelerate the automation of my cloud native development with my traditional infrastructure? Because as people put in green, they have born in the cloud projects, and then integrating it with the cloud on premises with the traditional infrastructure, how do I accelerate those two environments? How do I automate, accelerate the automation? Yeah, so it's a great story for us, and what we were talking about across the whole of Ansible, is that we're bringing together of our advanced cluster management product, a whole chip platform, and the Ansible is just in widespread use in the role of the automation of both traditional and automated infrastructure. So whether that's cloud infrastructure, on-premise, storage, compute, network, you name it, customers are using Ansible, the user is using Ansible to do all kinds of pieces in the system infrastructure. Being able to tie that to their new cloud native initiatives, without having to redo all of that work that they've already done to integrate that existing infrastructure automation with their cloud native structure and to accelerate substantially the, what I call the operationalization, easy for me to say, operationalization of their cloud native platforms with their existing IT infrastructure and existing IT ecosystem. I believe that that's where the Ansible automation platform plays a key role in connecting those two pieces together without having to redo all that work that's been done and invested out there. Robin, what's your take on this? This is what people are working on in the trenches. They realize cloud benefits, they got some cloud native action and also they got the on the traditional environment, they got to get them connected and automate. Yeah, absolutely. I mean, you know, the beauty of Ansible, you know, from an end user perspective is, you know, how easy it is to learn and how easy the language is to learn. And I think, you know, that portability, you know, it doesn't matter like how much a rocket scientist you are, you know, everybody appreciates simplicity. Everybody appreciates being able to hand something simple to somebody else and letting other people get done and having it be more or less in a, it's not quite English, but it's definitely, you know, Ansible is quite readable, right? And, you know, when we looked at, you know, when we started to work on all the Ansible operators, you know, one of that, one of the main pieces there was making sure that that simplicity that we have in Ansible is brought over directly into the operators. So just because it's cloud native doesn't mean you suddenly have to learn, you know, a whole set of new languages. Ansible is just as portable there as it is to any other part of your IT organization, infrastructure, whatever it is that you have going on. Well, there's a lot of action going on here at Red Hat Summit 2021. Things I wanted to bring up in context of the show is the success and the importance of you guys having Ansible collections. This has come up multiple times. As we talked about those personas and you got these new contributors, you got people contributing content. As open source continues to grow and be phenomenal value proposition. Touch on this concept of collections. What's the updates? Why is it important? Why should folks pay attention to it and continue to innovate with collections? I guess from a commercial perspective, from a product perspective, collections down this made it a lot easier for contributors to create and deploy and distribute content to be able to use. The Robin's mentioned earlier, these iterations in Ansible have all of that integration, all of those collections, all of which in one bit which we call the batteries included back in the day, right? But that meant that for contributors to be able to deploy their content with the base asset distribution, they have to wait for the next version of Ansible. That's when that content would get redistributed with the next version of Ansible. Like decoupling content from the core engine, putting that into collections that are individual elements of related innovations. Most of these can be better in case. So users and customers can get the content they need in a case that contributors like and can be popular, right? So customers don't have to wait for the next version of shipping product to get a new version of the integration that they really like to have. So again, if decoupling those things allows them to meet the different phases, the engine or the platform itself needs to be stable, deployment secure. It's going to move a certain life cycle, the content itself, all the different content can be popularized and network providers can write out problems. All of those things can now move at their own pace. Each of those have their own life cycle and their own private speed. So it allows us to get more functionality in our customers' hands for life quicker and then launching our certified program that's going to support that content. And certifying support that content helps me with the values that we bring to our customers through this description, is that ecosystem and ISE partners that we work with and we certify and support the stuff that we ship and support the customers who come in. Benefits both on the access to the technology as well as to the access to the value at the end of this in terms of integration, testing, and support. Robin, what's your take on the community? I see custom automation with the connector. A lot of action going on with collections. Yeah, absolutely. It's been interesting. Tom just mentioned how everything previously all had to be released all at once, right? And if you think about, sure, I have Ansible installed, but how often do I have to, just even as a regular, I'm not a system administrator these days type person, like how often do I have to click that button to update my Mac or my Linux machine or my Windows machine or the operating system on my telephone, right? Every time one of these devices that Ansible connects to or a program or whatever it is connects to something, those things are all operating and developing themselves at their own paces, right? So when a new version of, you know, well, we'll call it Red Hat Enterprise Linux. When a new version of Red Hat Enterprise Linux comes out, if there are new changes or new features that we want to be able to connect to, it's not really helpful when we're not releasing for another six months, right? So it's really helped us, you know, from a community angle to be able to have each of these collections working in concert with, you know, like, for example, in RHEL, like the Linux subsystems that are actually making things that will be turned into collections, right? Like SE Linux or SystemD, right? Like those things move at their own pace. We can update those at our own pace in collections and then people can update those collections without having to wait another six months or eight months or whatever it is for a new version of Ansible to come out. It's really made it easier for all of those, you know, developers of content to work on their content and their, you know, Ansible relationships almost in sync and make sure that, you know, both not, I'm going to do it over here and then I'm going to come back over here and fix everything later. It's more of a, you know, continuous development process. So the contributor experience is better then, you'd say. I'm sorry? The contributor experience is better then. Oh, absolutely. Yeah, 100%. I mean, it's, you know, there's something to be said for, I wouldn't say it's like instant satisfaction, but certainly the ability to have a little bit more independence and be able to release things as you see fit and not be gated by the entire rest of the project is amazing for those folks. All right, so I'll put you on the spot, Robin. So if I'm a developer, bottom line me, what's in it for me? Why should I pay attention to collections? What's the bottom line? Well, you know, Ansible is a platform and Ansible benefits from network effects. You know, the reason that we've gotten as big as we have is sort of like the snowball rolling downhill, right? The more people that latch on to what you're doing, the more people benefit and the more, you know, additional folks want to join in. So, you know, if I was working on any other product that I would consider being able to have automated with Ansible, you know, the biggest thing that I would look at is, well, you know, what are those people also using? Are they automating it with Ansible? And I can guarantee you 99% of the time, everything else that people are using is also being automated with Ansible. So you'd be crazy to not, you know, want to participate and make sure that you're providing the best, you know, Ansible experience for, you know, your application because for every application or, you know, device that we can connect to, there's probably 20 other competitors that also make similar applications that, you know, folks might also consider in lieu of you if you're not using, if you're not providing Ansible content for it. Hey, make things easier, simple to use and you reduce the steps it takes to do things. That's a winning formula, Tom. I mean, when you make things that good and then you get the network effect, but this highlights what you mentioned earlier about connective tissue. When you use words like connective tissue, it implies an organizational, it's not a mechanism, it's not just software, it's people. There's a people experience here in the automation platform. This seems to be the bottom line. What's your take? What's your bottom line? I'm a developer, what's in it for me? Why should I pay attention to the automation platform? So, I'm a developer, what kind of a set speed is when people are using what they're talking about and taking the automation platform in, crossing those domains in silence and sort of connective tissue across these tools, and it's personas, then there's those intermediaries, there's developers that are creating automation on the edit and the answer. More people across the organization, faster, more simplified way by using the answer to automation. So, they get access, right? The consumers are the automation itself, those personas, they get access to consistent automation faster, they get up and running for the last group on their part of the client group. No code or no code folks. And so, we invent the new engines of automation when we're kind of making a patient back, so they want to be able to know about the details of what it takes them to configure the network, configure the storage elements. They rely on those automation developers or contributors that would do that for them in every node. And that's really one of the powers of the platform. It's not sharing across those things, across those, again, what I've got, what Kinect and SecOps or ITOps, Kinect and SecOps and NetworkOps, they're able to do all of these tasks with the same language and the same innovation content. And it's both, it's nothing much faster and it's a model of kind of core responsibilities without worrying with new lines. Robin, you wanted to talk about something in the community. Any updates, I think navigator you mentioned, you wanted to mention, plug for that? Yeah, absolutely. So, much like any other platform in the universe, if you don't have really great tools for developing content, you're kind of dead in the water, right? You're leaving it to fate. So, we've been working on a new project, not part of the product yet, but it's sort of in a community exploratory phrase, a release early, release often, or minimum viable project, I guess might be the other way to describe it currently. It's called Ansible Navigator. It's a 2E, which is like a GUI, but it's got a sort of a terminal user interface look to it that allows you to develop, it's a sort of interface where you can develop content, all in one window have your documentation accessible to you, have all of your test results available to you in one window, rather than I'm gonna do something here and then I'm gonna go over here, and now I'm not sure, so now I'm gonna go over here and look at docs, instead it's all in one place, which we think will actually, but I mean, I know the folks who have seen it or have already been like, ah, but it's definitely in early community stages right now. We can give you the link, it's github.com slash ansible slash ansible navigator, but it's a- A 2E versus a GUI, versus a command line interface on our face, which is how do you innovate on the command line? It's a GUI or, you know, it's- It's, there's so many IDEs out there, and I think Tom can probably talk to some of this, how that might relate to VS Code or many of the other traditional developer IDEs that are out there, but you know, the goal is certainly to be able to integrate with some of those other pieces, but you know, it's one of those things where, you know, if everybody's using the same tool and we can start to enforce higher levels of quality and standards through that tool, there's benefits for everyone. Tom, I don't know if you wanna add on to that in any way? Yeah, it's just kind of one of our focus areas here, which is making it as easy as possible. You can use it to create ansible automation, and so part of that is actually in the test and take, and we're having an estimate on this goal that developers and contributors to see their IDEs, we will also build, test, and deploy automation content. So I'm making that contributor that builders like, their job, and so it can be easy. Well, thanks for coming on, Tom, and Robin, thanks for sharing the insight here. Red Hat Summit 21 virtual. Obviously, you guys continue to do a great job with the success of the platform, which has been, you know, consistently growing and having great satisfaction with developers. And now ops teams and sec teams and net teams, you know, unifying these teams is certainly a huge priority for enterprises because the end of the day, cloud scale is all about operating a scale, which means more standards, more operations. That's what you guys are doing. So congratulations on the continued success. Thanks for sharing. Thanks for having us. Okay, I'm John Furrier here in theCUBE. We are remote with CUBE virtual for Red Hat Summit 2021. Thanks for watching.