>>Hey everyone. Welcome back to Chicago. The Cube is excited to be live on day two of Ansible Fest, 2022. Lisa Martin and John Fur. You're here having some great conversations, a lot of cube alumni, a lot of wisdom from the Ansible community coming at you on this program this week. You know, John, we've been, we've been hearing stories about the power and the capabilities and the collective wisdom of the Ansible community. You can feel it here. Yeah, there's no doubt about that. It's, Ansible is nothing, as Stephanie Chair said yesterday, if not a community and the significant contributions that it makes over and over again, or it's fuel. >>I mean the power of the community is what drives Ansible is gonna drive the future of, I think, cloud in our next generation modern application environment. And it's collective intelligence. It's a production system at the end of the day. And I think these guys have harnessed it. So it should be a really great segment to talk about all the contributor work that's been done. So I'm looking forward to it. >>We've got two great alumni here to talk about the contributor work, how you can get involved. Please welcome back to the cube. Carol Chen, principal community architect at Red Hat. Adam Miller joins us as well, fresh from the keynote stage senior principal software engineer at Red Hat. Guys, great to have you on the cube. Great to be here. Yeah, thank you. So we, we talked, we enjoyed your keynotes, Adam, and what you were talking about on stage, the Ansible contributor summit. That's, you guys have been doing what, this is the seven you've had seven so far in just a couple of years. >>Well, we had seven virtual contributor summits. >>Seven virtual. This is the first Monday was the first in person in. >>First in person since the pandemic and actually the 15th contributor summit overall >>15th overall. Talk about the contributor summits, what the contributors are able to do and the influence that it's having on Ansible Red Hat and what people are able to do with cloud. At the Edge automation. Yeah. >>So our community contributors have always had ways to influence and contribute to the project. But the contributor Summit is really a place where we can get people together, preferably in the same place so that we can, you know, have a really great dynamic conversations and interactions. But we also want to make sure that we don't leave out people who have been constantly online joining us. So this year we are so happy to be here in Chicago in person. We've had about 60 to 70 here joining us. And at first I thought maybe we'll have one third of the attendees joining online because about 30 to 40 people signed up to join online. But in the end, we have more than 100 per people watching our live stream. So that's more than half of the attendees overall, were joining us online. So that really shows where, you know, the contributors are interested in participating for >>Develop. Right. Yeah, it's been, it's been interesting. It's been since 2019, since the in-person Ansible Fest in Atlanta. Now we're in Chicago, we had the pandemic. Couple interesting observations from our side that I wanna get your reaction to Adam Carol. And that is one Ansible's relevance has grown significantly since then. Just from a cloud growth standpoint, developer open source standpoint, and how people work and collaborate has changed. So your contributor based in your community is getting more powerful in scope, in my opinion. Like in, as they become, have the keys to the kingdom in the, in their respective worlds as it gets bigger and larger. So the personas are changing, the makeup of the community's changing and also how you guys collaborate is changing. Can you share your, what's going on with those two dynamics? Cause I think that power dynamic is, is looking really good. How are you guys handling >>That? Yeah, so I mean, I, I had the opportunity to represent the community on stage yesterday as part of the keynote and talk to this point specifically is one of the things that we've seen is the project has had the opportunity to kind of grow and evolve. There's been certain elements that have had to kind of decompose from a technology perspective. We actually had to kind of break it apart and change the architecture a little bit and move things into what are called Ansible collections, which, you know, folks here are very familiar with No One Love. And we've seen a lot of community work in the form of working groups coalesce around those organically. However, they've done so in kind of different ways. They, they pick tools and collaboration platforms that are popular to their subject matter expertise audience and things like that. So we find ourselves in a place where kind of the, the community itself had more or less segmented naturally in a way. And we needed to find ways to, you know, kind of ke that >>Fragmentation by demographics or by expertise or both as >>A Mostly, mostly expertise. Yeah. And so there was a open source technology called Matrix. It is a open source, standardized, federated messaging platform that we're able to use to start to bridge back some of those communities that have kind of broken off and, and made their their own home elsewhere on the internet. So now we're able to, for example, the right, the docs organization, they had a, a group of people who was very interested in contributing to the Ansible documentation, but they'd already self-organized on Discord. And what was interesting there is the existing team for the Ansible documentation, they were already on internet Relay Chat, also known as irc. And Matrix allowed us to actually bring those two together and bridge that into the other matrix cha chat channels that we had. So now we're able to have people from all over the world in different areas and different platforms, coalesce and, and cross. It's like a festival cross pollinate. Yeah. >>And you're meeting the contributors exactly where they are and where they want to be, where they're comfortable. >>Yes. Yeah, we always say we, we reach out to where they are. So, >>And, and, and much in the way that Ansible has the capability to reach out to things in their own way, Right. And allow that subject matter expertise to, you know, cause the technology has the potential and possibility and capability to talk to anything over any protocol. We're able to do, you know, kind of the same thing with Matrix, allowing us to bridge into any chat platform that it has support for bridging and, and we're able to bring a lot of people >>Together. Yeah. And how's that, how's the feedback been on that so far? >>I, I think it has been very positive. For example, I want to highlight that the technical writers that we have contributing via Discord is actually a group from Nigeria. And Dave also participated in the contributor summit online virtually joining us in, in, you know, on the matrix platform. So that, that bridge that really helps to bring together people from different geographical regions and also different topics and arenas like that. >>So what were some of the outcomes of the contributor summit? The, the first in person in a while, great. That you guys were able to do seven virtually during the pandemic. That's hard. It's hard to get people together. You, there's so much greatness and innovation that comes when we're all together in person that just can't replicate by video. You can do a lot. Right. But talk about some of the outcomes from Monday. What were some of the feedback? What were some of the contributions that you think are really going to impact the community? >>I think for a lot of us, myself included, the fact that we are in person and meeting people face to face, it helps to really build the connections. And when we do talk about contribution, the connection is so important that you understand, well this person a little bit about their background, what they've done for the SPO project and or just generally what, what they're interested in that builds the rapport and connection that helps, you know, further, further collaboration in the future. Because maybe on that day we did not have any, you know, co contributions or anything, but the fact that we had a chance to sit together in the same place to discuss things and share new ideas, roadmaps is really the, the kind of a big step to the future for our community. Yes, >>Yes. And in a lot of ways we often online the project has various elements that are able to function asynchronously. So we work very well globally across many time zones. And now we were able to get a lot of people in the same place at the same time, synchronously in the same time zone. And then we had breakout sessions where the subject matter, you know, working groups were able to kind of go and focus on things that maybe have been taking a little while to discuss in, in that asynchronous form of communication and do it synchronously and, you know, be in the same room and work on things. It's been, it's been fantastic >>Developers there, like they, they take to asynchronous like fish to water. It's not a problem. But I do want to ask if there's any observations that you guys have had now that we're kind of coming out of that one way, but the pandemic, but the world's changed. It's hybrid, hybrid work environment, steady state. So we see that. Any observations on your end on what's new that you observed that people are gravitating to? Is there a pattern of styles is or same old self-governing, or what's new? What do you see that's coming out of the pandemic that might be a norm? >>I I think that even though people are excited to get back in person, there are, things have changed, like you said, and we have to be more aware of, there are people who think that not be in person, it's okay. And that's how they want to do it. And we have to make sure that they, they are included. So we, we did want to make a high priority for online participation in this event. And like I said, even though only 4 30, 40 people signed up to join us online initially, so that it was what we were expecting, but in the end, more than 100 people were watching us and, and joining participation in >>Actually on demand consumption be good too, >>Right? Yeah. So, you know, I think going forward that is probably the trend. And as, as much as we, we love being in person, we, we want this to continue that we, we take care of people who are, has been constantly participating online and contributing you >>Meaning again, meaning folks where they are, but also allowing the, the, those members that want to get together to, to collaborate in person. I can only imagine the innovation that's gonna come even from having part of the back, Right. >>And, and not to continue to harp on the matrix point, but it, it's been very cool because Matrix has the ability to do live video sessions using open source another to open source technology called jy. So we're able to actually use the same place that we normally find ourselves, you know, congregating and collaborating for the project itself in an asynchronous and, you know, somewhat synchronous way to also host these types of things that are, are now hybrid that used to be, you know, all one way or all the other. Yeah. And it's been, it's >>Been incredible. Integration is, the integration is have been fascinating to watch how you guys do that. And also, you know, with q we've been virtual too. It's like, it's like people don't want another microsite, but they want a more of a festival vibe, a hub, right? Like a place to kind of check in and have choice, not get absolutely jammed into a, you know, forum or, you know, or whatever. Hey, if you wanna be on Discord, be on Discord, right? Why >>Not? And we still, you know, we do still have our asynchronous forms of >>Work through >>Our get GitHub. We have our projects, we have our issues, we have our, you know, wiki, we have various elements there that everybody can continue to collaborate on. And it's all been, it's all been very good. >>Speaking of festivals, octoberfest that's going on, not to be confused with Octoberfest, that was last month. Talk about how the Ansible project and the Ansible community is involved in Octoberfest. Give us the dates, Carol. So >>YesTo Fest is a annual thing in October. So October Octoberfest, I think it's organized by Digital Ocean for the past eight or nine years. And it's really a, a way to kind of encourage people to contribute to open source projects. So it's not anal specific, but we as an Ansible project encourage people to take this opportunity to, you know, a lot of them doing their first contributions during this event. And when, when we first announced, we're participating in Octoberfest within the first four days of October, which is over a weekend actually. We've had 24 contributions, it, 24 issues fixed, which is like amazing, like, you know, just the interest and the, the momentum that we had. And so far until I just checked with my teammates this morning that we've had about 35 contributions so far during the month, which is, and I'm sorry, I forgot to mention this is only for Ansible documentation. So yeah, specifically. And, and that's also one thing we want to highlight, that contributions don't just come in code in, you know, kind of software side, but really there's many ways to contribute and documentation is such a, a great way for first time users, first time contributors to get involved. So it's really amazing to see these contributions from all over the world. And also partly thanks to the technical writers in Nigeria kind of promoting and sharing this initiative. And it's just great to see the, the results from that. Can >>You double click on the different ways of contribution? You mentioned a couple documentation being one, code being the other, but what is the breadth of opportunities that the contributors have to contribute to the project? >>Oh, there's, there's so many. So I actually take care more of outreach efforts in the community. So I helped to organize events and meetups from around the world. And now that we're slowly coming out of the pandemic, I've seen more and more in person meetups. I was just talking to someone from Minneapolis, they're trying to get, get people back together again. They have people in Singapore, in Netherlands from pretty much, you know, all corners of the globe wanting to form not just for the Ansible project, but the local kind of connection with the re people in the region, sometimes in their own language, in their local languages to really work together on the project and just, >>You know, you to create a global Yeah. Network, right? I mean it's like Ansible Global. >>Exactly. >>Create local subnets not to get all networking, >>Right? >>Yeah. >>Yeah. One, one quick thing I want to touch on Theto Fest. I think it's a great opportunity for existing contributors to mentor cause many people like to help bring in new contributors and this is kind of a focal point to be able to focus on that. And then to, to the the other point we, you know, it, it's been, it's been extremely powerful to see as we return these sub communities pop up and, and kind of work with themselves, so on different ways to contribute. So code is kind of the one that gets the most attention. I think documentation I think is a unsung hero, highly important, great way. The logistical component, which is invaluable because it allows us to continue with our adoption and evangelization and things like that. So specifically adoption and evangelize. Evangelization is another place that contributors can join and actually spawn a local meetup and then connect in with the existing community and try to, you know, help increase the network, create a new subject. Yeah. >>Yeah. Network affects huge. And I think the thing that you brought up about reuse is, is part of that whole things get documented properly. The leverage that comes out of that just feeds into the system that flywheel. Absolutely. I mean it's, that's how communities are supposed to work, right? Yep. Yes. >>That's what I was just gonna comment on is the flywheel effect that it's clearly present and very palpable. Thank you so much for joining John, me on the program, talking about the contributors summit, the ways of contribution, the impacts that are being made so far, what Octoberfest is already delivering. And we're, we still have about 10 days or so left in October, so there's still more time for contributors to get involved. We thank you so much for your insights and your time. Thank >>You. Thank you so much for having us. >>Our pleasure. For our guests and John Purer, I'm Lisa Martin. You're watching The Cube Live from Chicago, day two of our coverage of Red Hat Ansible Summit 22. We will see you right n after this short break with our next guest.

>> (soft upbeat music) >> Announcer: From around the globe, it's the cube with digital coverage of Ansible Fest 2020, brought to you by RedHat. >> Hello, welcome to the cubes coverage of Ansible Fest 2020. We're not in person, we're virtual. I'm John Furrier , your host of theCube. We've got a great power panel here of RedHat engineers. We have Brad Thorton, Senior Principle Software Engineer for Ansible networking. Adam Miller, Senior Principle Software Engineer for Security and Jill Rouleau, who's the Senior Software Engineer for Ansible Cloud. Thanks for joining me today. Appreciate it. Thanks for coming on. >> Thanks. >> Good to be here. >> We're not in person this year because of COVID, a lot going on but still a lot of great news coming out of Ansible Fest this year. Last year, you guys launched a lot since last year. It's been awesome. Launched the new platform. The automation platform, grown the collections, certified collections community from five supported platforms to over 50, launched a lot of automation services catalog. Brad let's start with you. Why are customers successful with Ansible in networking? >> Why are customers successful with Ansible in networking? Well, let's take a step back to a bit of classic network engineering, right? Lots of CLI interaction with the terminal, a real opportunity for human error there. Managing thousands of devices from the CLI becomes very difficult. I think one of the reasons why Ansible has done well in the networking space and why a lot of network engineers find it very easy to use is because you can still see an attack at the CLI. But what we have the ability to do is pull information from the same COI that you were using manually, and showed that as structured data and then let you return that structured data and push it back to the configuration. So what you get when you're using Ansible is a way to programmatically interface and do configuration management across your entire fleet. It brings consistency and stability, and speed really to network configuration management. >> You know, one of the big hottest areas is, you know, I always ask the folks in the cloud what's next after cloud and pretty much unanimously it's edge, and edge is super important around automation, Brad. What's your thoughts on, as people start thinking about, okay, I need to have edge devices. How does automation play into that? And cause networking, edge it's kind of hand in hand there. So what's your thought on that? >> Yeah, for sure. It really depends on what infrastructure you have at the edge. You might be deploying servers at the edge. You may be administering IOT devices and really how you're directing that traffic either into edge compute or back to your data center. I think one of the places Ansible is going to be really critical is administering the network devices along that path from the edge, from IOT back to the data center, or to the cloud. >> Jill, when you have a Cloud, what's your thoughts on that? Because when you think about Cloud and Multicloud, that's coming around the horizon, you're looking at kind of the operational model. We talked about this a lot last year around having Cloud ops on premises and in the Cloud. What should customers think about when they look at the engineering challenges and the development challenges around Cloud? >> So cloud gets used for a lot of different things, right? But if we step back Cloud just means any sort of distributed applications, whether it's on prem in your own data center, on the edge, in a public hosted environment, and automation is critical for making those things work, when you have these complex applications that are distributed across, whether it's a rack, a data center or globally. You need a tool that can help you make sense of all of that. You've got to... We can't manage things just with, Oh, everything is on one box anymore. Cloud really just means that things have been exploded out and broken up into a bunch of different pieces. And there's now a lot more architectural complexity, no matter where you're running that. And so I think if you step back and look at it from that perspective, you can actually apply a lot of the same approaches and philosophies to these new challenges as they come up without having to reinvent the wheel of how you think about these applications. Just because you're putting them in a new environment, like at the edge or in a public Cloud or on a new, private on premise solution. >> It's interesting, you know, I've been really loving the cloud native action lately, especially with COVID, we're seeing a lot of more modern apps come out of that. If I could follow up there, how do you guys look at tools like Terraform and how does Ansible compare to that? Because you guys are very popular in the cloud configuration, you look at cloud native, Jill, your thoughts. >> Yeah. So Terraform and tools like that. Things like cloud formation or heat in the OpenStack world, they do really, really great at things like deploying your apps and setting up your stack and getting them out there. And they're really focused on that problem space, which is a hard problem space that they do a fantastic job with where Ansible tends to come in and a tool like Ansible is what do you do on day two with that application? How do you run an update? How do you manage it in the longterm of something like 60% of the workloads or cloud spend at least on AWS is still just EC2 instances. What do you do with all of those EC2 instances once you've deployed them, once they're in a stack, whether you're managing it, whatever tool you're managing it with, Ansible is a phenomenal way of getting in there and saying, okay, I have these instances, I know about them, but maybe I just need to connect out and run an update or add a package or reconfigure a service that's running on there. And I think you can glue these things together and use Ansible with these other stack deployment based tools really, really effectively. >> Real quick, just a quick followup on that. what's the big pain point for developers right now when they're looking at these tools? Because they see the path, what are some of the pain points that they're living right now that they're trying to overcome? >> I think one of the problems kind of coincidentally is we have so many tools. We're in kind of a tool explosion in the cloud space, right now. You could piece together as as many tools to manage your stack, as you have components in your stack and just making sense of what that landscape looks like right now and figuring out what are the right tools for the job I'm trying to do, that can be flexible and that are not going to box me into having to spend half of my engineering time, just managing my tools and making sense of all of that is a significant effort and job on its own. >> Yes, too many may add, would choke in years ago in the big data search, the tools, the tool train, one we call the tool shed, after a while, you don't know what's in the back, what you're using every day. People get comfortable with the right tools, but the platform becomes a big part of that thinking holistically as a system. And Adam, this comes back to security. There's more tools in the security space than ever before. Talking about tool challenges, security is the biggest tool shed everyone's got tools they'd buy everything, but you got to look at, what a platform looks like and developers just want to have the truth. And when you look at the configuration management piece of it, security is critical. What's your thoughts on the source of truth when it comes into play for these security appliances? >> So these are... Source of truth piece is kind of an interesting one because this is going to be very dependent on the organization. What type of brownfield environment they've developed, what type of things that they rely on, and what types of data they store there. So we have the ability for various sources of truth to come in for your inventory source and the types of information you store with that. This could be tagged information on a series of cloud instances or series about resources. This could be something you store in a network management tool or a CMDB. This could even be something that you put into a privilege access management system, such as, CyberArk or hashivault. Like those are the things and because of Ansible flexibility and because of the way that everything is put together in a pluggable nature, we have the capability to actually bring in all of these components from anywhere in a brownfield environment, in a preexisting infrastructure, as well as new decisions that are being made for the enterprise as I move forward. And, and we can bring all that together and be that infrastructure glue, be that automation component that can tie all these disjoint loosely coupled, or complete disc couple pieces, together. And that's kind of part of that, that security posture, remediation various levels of introspection into your environment, these types of things, as we go forward, and that's kind of what we're focusing on doing with this. >> What kind of data is stored in the source of truth? >> I mean... So what type of data? This could be credential. It could be single use credential access. This could be your inventory data for your systems, what target systems you're trying to do. It could be, various attributes of different systems to be able to classify them ,and codify them in different ways. It's kind of kind of depending, be configuration data. You know, we have the ability with some of the work that Brad and his team are doing to actually take unstructured data, make it structured, bullet into whatever your chosen source of truth is, store it, and then utilize that to, kind of decompose it into different vendors, specific syntax representations and those types of things. So we have a lot of different capability there as well. >> Brad, you were mentioned, do you have a talk on parsing, can you elaborate on that? And why should network operators care about that? >> Yeah, welcome to 2020. We're still parsing network configuration and operational state. This is an interesting one. If you had asked me years ago, did I think that we would be investing development time into parsing with Ansible network configurations? I would have said, "Well, I certainly hope not. "I hope programmability of network devices and the vendors "really have their API's in order." But I think what we're seeing is network containers are still comfortable with the command line. They're still very familiar with the command line and when it comes time to do operational state assessment and health assessment of your network, engineers are comfortable going to the command line and running show commands. So really what we're trying to do in the parsing space is not author brand new parking and parsing engine ourselves, but really leverage a lot of the open source tools that are already out there bringing them into Ansible, so network engineers can now harvest the critical information from usher operational state commands on their network devices. And then once they've gotten to the structure data, things get really interesting because now you can do entrance criteria checks prior to doing configuration changes, right? So if you want to ensure a network device has a very particular operational state, all the BGP neighbors are, for example before pushing configuration changes, what we have the ability to do now is actually parse the command that you would have run from the command line. Use that within a decision tree in your Ansible playbook, and only move forward when the configuration changes. If the box is healthy. And then once the configuration changes are made at the end, you run those same health checks to ensure that you're in a speck can do a steady state and are production ready. So parsing is the mechanism. It's the data that you get from the parsing that's so critical. >> If I had to ask you real quick, just while it's on my mind. You know, people want to know about automation. It's top of mind use case. What are some of these things around automation and configuration parsing, whether it's parsing to other configuration manager, what are the big challenges around automation? Because it's the Holy grail. Everyone wants it now. What are the couches? where's the hotspots that needs to be jumped on and managed carefully? Or the easiest low hanging fruit? >> Well, there's really two pieces to it, right? There's the technology. And then there's the culture. And, and we talk really about a culture of automation, bringing the team with you as you move into automation, ensuring that everybody has the tools and they're familiar with how automation is going to work and how their day job is going to change because of automation. So I think once the organization embraces automation and the culture is in place. On the technology side, low hanging fruit automation can be as simple as just using Ansible to push the commands that you would have previously pushed to the device. And then as your organization matures, and you mature along this kind of path of network automation, you're dealing with larger pieces, larger sections of the configuration. And I think over time, network engineers will become data managers, right? Because they become less concerned about the network, the vendors specific configuration, and they're really managing the data that makes up the configuration. And I think once you hit that part, you've won at automation because you can move forward with Ansible resource modules. You're well positioned to do NETCONF for RESTCONF or... Right once you've kind of grown to that it's the data that we need to be concerned about and it could fit (indistinct) and the operational state management piece, you're going to go through a transformation on the networking side. >> So you mentioned-- >> And one thing to note there, if I may, I feel like a piece of this too, is you're able to actually bridge teams because of the capability of Ansible, the breadth of technologies that we've had integrations with and our ability to actually bridge that gap between different technologies, different teams. Once you have that culture of automation, you can start to realize these DevOps and DevSecOps workflow styles that are top of everybody's mind these days. And that's something that I think is very powerful. And I like to try to preach when I have the opportunity to talk to folks about what we can do, and the fact that we have so much capability and so many integrations across the entire industry. >> That's a great point. DevSecOps is totally a hop on. When you have software and hardware, it becomes interesting. There's a variety of different equipment, on the security automation. What kind of security appliances can you guys automate? >> As of today, we are able to do endpoint management systems, enterprise firewalls, security information, and event management systems. We're able to do security orchestration, automation, remediation systems, privileged access management systems. We're doing some threat intelligence platforms. And we've recently added to the I'm sorry, did I say intrusion detection? We have intrusion detection and prevention, and we recently added endpoint security management. >> Huge, huge value there. And I think everyone's wants that. Jill, I've got to ask you about the Cloud because the modules came up. What use cases do you see the Ansible modules in for the public cloud? Because you got a lot of cloud native folks in public cloud, you've got enterprises lifting and shifting, there's a hybrid and multicloud horizon here. What's some of the use cases where you see those Ansible modules fitting well with public level. >> The modules that we have in public cloud can work across all of those things, you know. In our public clouds, we have support for Amazon web services, Azure GCP, and they all support your main services. You can spin up a Lambda, you can deploy ECS clusters, build AMI, all of those things. And then once you get all of that up there, especially looking at AWS, which is where I spend the most time, you get all your EC2 instances up, you can now pull that back down into Ansible, build an inventory from that. And seamlessly then use Ansible to manage those instances, whether they're running Linux or windows or whatever distro you might have them running, we can go straight from having deployed all of those services and resources to managing them and going between your instances in your traditional operating system management or those instances and your cloud services. And if you've got multiple clouds or if you still have on prem, or if you need to, for some reason, add those remote cloud instances into some sort of on-prem hardware load balancer, security endpoint, we can go between all of those things and glue everything together, fairly seamlessly. You can put all of that into tower and have one kind of view of your cloud and your hardware and your on-prem and being able to move things between them. >> Just put some color commentary on what that means for the customer in terms of, is it pain reduction, time savings? How would you classify their value? >> I mean, both. Instead of having to go between a number of different tools and say, "Oh, well for my on-prem, I have to use this. "But as soon as I shift over to a cloud, "I have to use these tools. "And, Oh, I can't manage my Linux instances with this tool "that only knows how to speak to, the EC2 to API." You can use one tool for all of these things. So like we were saying, bring all of your different teams together, give them one tool and one view for managing everything end to end. I think that's, that's pretty killer. >> All right. Now I get to the fun part. I want you guys to weigh in on the Kubernetes. Adam, if you can start with you, we'll start with you go in and tell us why is Kubernetes more important now? What does it mean? A lot of hype continues to be out there. What's the real meet around Kubernetes what's going on? >> I think the big thing is the modernization of the application development delivery. When you talk about Kubernetes and OpenShift and the capabilities we have there, and you talk about the architecture, you can build a lot of the tooling that you used to have to maintain, to be able to deliver sophisticated resilient architectures in your application stack, are now baked into the actual platform, so the container platform itself takes care of that for you and removes that complexity from your operations team, from your development team. And then they can actually start to use these primitives and kind of achieve what the cloud native compute foundation keeps calling cloud native applications and the ability to develop and do this in a way that you are able to take yourself out of some of the components you used to have to babysit a lot. And that becomes in also with the OpenShift operator framework that came out of originally Coral S, and if you go to operator hub, you're able to see these full lifecycle management stacks of infrastructure components that you don't... You no longer have to actually, maintain a large portion of what you start to do. And so the operator SDK itself, are actually developing these operators. Ansible is one of the automation capabilities. So there's currently three supported there's Ansible, there's one that you just have full access to the Golang API and then helm charts. So Ansible's specifically obviously being where we focus. We have our collection content for the... carries that core, and then also ReHat to OpenShift certified collection's coming out in, I think, a month or so. Don't hold me to the timeline. I'm shoving in trouble for that one, but we have those things going to come out. Those will be baked into the operator's decay that we fully supported by our customer base. And then we can actually start utilizing the Ansible expertise of your operations team to container native of the infrastructure components that you want to put into this new platform. And then Ansible itself is able to build that capability of automating the entire Kubernetes or OpenShift cluster in a way that allows you to go into a brownfield environment and automate your existing infrastructure, along with your more container native, futuristic next generation, net structure. >> Jill this brings up the question. Why don't you just use native public cloud resources versus Kubernetes and Ansible? What's the... What should people know about where you use that, those resources? >> Well, and it's kind of what Adam was saying with all of those brownfield deployments and to the same point, how many workloads are still running just in EC2 instances or VMs on the cloud. There's still a lot of tech out there that is not ready to be made fully cloud native or containerized or broken up. And with OpenShift, it's one more layer that lets you put everything into a kind of single environment instead of having to break things up and say, "Oh, well, this application has to go here. "And this application has to be in this environment.' You can do that across a public cloud and use a little of this component and a little of that component. But if you can bring everything together in OpenShift and manage it all with the same tools on the same platform, it simplifies the landscape of, I need to care about all of these things and look at all of these different things and keep track of these and are my tools all going to work together and are my tools secure? Anytime you can simplify that part of your infrastructure, I think is a big win. >> John: You know, I think about-- >> The one thing, if I may, Jill spoke to this, I think in the way that a architectural, infrastructure person would, but I want to try to really quick take the business analyst component of it as the hybrid component. If you're trying to address multiple footprints, both on prem, off prem, multiple public clouds, if you're running OpenShift across all of them, you have that single, consistent deployment and development footprint for everywhere. So I don't disagree with anything they said, I just wanted to focus specifically on... That piece is something that I find personally unique, as that was a problem for me in a past life. And that kind of speaks to me. >> Well, speaking of past lives-- >> Having me as an infrastructure person, thank you. >> Yeah. >> Well, speaking of past lives, OpenStack, you look at Jill with OpenStack, we've been covering the Cuba thing when OpenStack was rolling out back in the day, but you can also have private cloud. Where you used to... There's a lot of private cloud out there. How do you talk about that? How do people understand using public cloud versus the private cloud aspect of Ansible? >> Yeah, and I think there is still a lot of private cloud out there and I don't think that's a bad thing. I've kind of moved over onto the public cloud side of things, but there are still a lot of use cases that a lot of different industries and companies have that don't make sense for putting into public cloud. So you still have a lot of these on-prem open shift and on-prem OpenStack deployments that make a ton of sense and that are solving a bunch of problems for these folks. And I think they can all work together. We have Ansible that can support both of those. If you're a telco, you're not going to put your network function, virtualization on USC as to one in spot instances, right? When you call nine one one, you don't want that going through the public cloud. You want that to be on dedicated infrastructure, that's reliable and well-managed and engineered for that use case. So I think we're going to see a lot of ongoing OpenStack and on-prem OpenShift, especially with edge, enabling those types of use cases for a long time. And I think that's great. >> I totally agree with you. I think private cloud is not a bad thing at all. Things that are only going to accelerate my opinion. You look at the VM world, they talked about the telco cloud and you mentioned edge when five G comes out, you're going to have basically have private clouds everywhere, I guess, in my opinion. But anyway, speaking of VMware, could you talk about the Ansible VMware module real quick? >> Yeah, so we have a new collection that we'll be debuting at Ansible Fest this year bore the VMware REST API. So the existing VMware modules that we have usually SOAP API for VMware, and they rely on an external Python library that VMware provides, but with these fare 6.0 and especially in vSphere 6.5, VMware has stepped up with a REST API end point that we find is a lot more performance and offers a lot of options. So we built a new collection of VMware modules that will take advantage of that. That's brand new, it's a lighter way. It's much faster, we'll get better performance out of it. You know, reduced external requirements. You can install it and get started faster. And especially with these sphere seven, continuing to build on this REST API, we're going to see more and more interfaces being exposed so that we can take advantage. We plan to expand it as new interfaces are being exposed in that API, it's compatible with all of the existing modules. You can go back and forth, use your existing playbooks and start introducing these. But I think especially on the performance side, and especially as we get these larger clouds and more cloud deployments, edge clouds, where you have these private clouds and lots and lots of different places, the performance benefits of this new collection that we're trying to build is going to be really, really powerful for a lot of folks. >> Awesome. Brad, we didn't forget about you. We're going to bring you back in. Network automation has moved towards the resource modules. Why should people care about them? >> Yeah. Resource modules, excuse me. Probably I think having been a network engineer for so long, I think some of the most exciting work that has gone into Ansible network over the past year and a half, what the resource modules really do for you is they will reach out to network devices. They will pull back that network native, that vendor native configuration. While the resource module actually does the parsing for you. So there's none of that with the resource modules. And we returned structured data back to the user that represents the configuration. Going back to your question about source of truth. You can take that structure data, maybe for your interface CONFIG, your OSPF CONFIG, your access list CONFIG, and you can store that data in your source of truth under source of truth. And then where you are moving forward, is you really spend time as every engineer managing the data that makes up the configuration, and you can share that data across different platforms. So if you were to look at a lot of the resource modules, the data model that they support, it's fairly consistent between vendors. As an example, I can pull OSPF configuration from one vendor and with very small changes, push that OSPF configuration to a different vendor's platform. So really what we've tried to do with the resource modules is normalize the data model across vendors. It'll never be a hundred percent because there's functionality that exists in one platform that doesn't exist and that's exposed through the configuration, but where we could, we have normalized the data model. So I think it's really introducing the concept of network configuration management through data management and not through CLI commands anymore. >> Yeah, that's a great point. It just expands the network automation vision. And one of the things that's interesting here in this panel is you're talking about, cloud holistically, public multicloud, private hybrid security network automation as a platform, not just a tool, we're still going to have all kind of tools out there. And then the importance of automating the edge. I mean, that's a network game Brad. I mean, it's a data problem, right? I mean, we all know about networking, moving packets from here to there, but automating the data is critical and you give have bad data and you don't have... If you have misinformation, it sounds like our current politics, but you know, bad information is bad automation. I mean, what's your thoughts? How do you share that concept to developers out there? What should they be thinking about in terms of the data quality? >> I think that's the next thing we have to tackle as network engineers. It's not, do I have access to the data? You can get the data now for resource modules, you can get the data from NETCONF, from RESTCONF, you can get it from OpenConfig, you can get it from parsing. The question really is, how do you ensure the integrity and the quality of the data that is making up your configurations and the consistency of the data that you're using to look at operational state. And I think this is where the source of truth really becomes important. If you look at Git as a viable source of truth, you've got all the tools and the mechanisms within Git to use that as your source of truth for network configuration. So network engineers are actually becoming developers in the sense that they're using Git ops to worklow to manage configuration moving forward. It's just really exciting to see that transformation happen. >> Great panel. Thanks for everyone coming on, I appreciate it. We'll just end this by saying, if you guys could just quickly summarize Ansible fast 2020 virtual, what should people walk away with? What should your customers walk away with this year? What's the key points. Jill, we'll start with you. >> Hopefully folks will walk away with the idea that the Ansible community includes so many different folks from all over, solving lots of different, interesting problems, and that we can all come together and work together to solve those problems in a way that is much more effective than if we were all trying to solve them individually ourselves, by bringing those problems out into the open and working together, we get a lot done. >> Awesome, Brad? >> I'm going to go with collections, collections, collections. We introduced in last year. This year, they are real. Ansible2.10 that just came out is made up of collections. We've got certified collections on automation. We've got cloud collections, network collections. So they are here. They're the real thing. And I think it just gets better and deeper and more content moving forward. All right, Adam? >> Going last is difficult. Especially following these two. They covered a lot of ground and I don't really know that I have much to add beyond the fact that when you think about Ansible, don't think about it in a single context. It is a complete automation solution. The capability that we have is very extensible. It's very pluggable, which has a standing ovation to the collections and the solutions that we can come up with collectively. Thanks to ourselves. Everybody in the community is almost infinite. A few years ago, one of the core engineers did a keynote speech using Ansible to automate Philips hue light bulbs. Like this is what we're capable of. We can automate the fortune 500 data centers and telco networks. And then we can also automate random IOT devices around your house. Like we have a lot of capability here and what we can do with the platform is very unique and something special. And it's very much thanks to the community, the team, the open source development way. I just, yeah-- >> (Indistinct) the open source of truth, being collaborative all is what it makes up and DevOps and Sec all happening together. Thanks for the insight. Appreciate the time. Thank you. >> Thank you. I'm John Furrier, you're watching theCube here for Ansible Fest, 2020 virtual. Thanks for watching. (soft upbeat music)

(gentle music) >> Hello from Chicago, Lisa Martin here at AnsibleFest 2022 with John Furrier. John, it's great to be here. The transformation of enterprise and industry through automation. This is not only the 10th anniversary of Ansible, this was the first in-person AnsibleFest since 2019. >> It's awesome, it's awesome, Lisa, and I want to welcome everyone to our live performance here in Chicago. We were remote for two years, 2019 in Atlanta. AnsibleFest, part of Red Hat now, Red Hat part of IBM. So much has happened in the past couple years and I think one of the things that we're going to cover this week here in Chicago, is the evolution of Ansible, where it fits into the new cloud-native ecosystems emerging, and also, kind of, what it means for developers and operators. And we're going to see a lot of that here at AnsibleFest with wall-to-wall coverage, keynote just happened. Very interesting to see, you know, Ansible stayed true to their knitting, as you say, you know. What do they do? No big announcements. Some big community news. But humble. >> Very humble. Very humble, but also very excited. All the keynotes did a great job of addressing that community, and being grateful to the community for, really, the evolution that we see at Ansible and now 10 years later. They were talking a lot about smoothing operations for the developers, democratizing automation across the organization. They talked a little bit about that skills gap. I wanted to get your opinion, 'cause as we know there's, they talked about it from a demand perspective, there's over 300,000 open positions on LinkedIn for Ansible skills. So a lot of opportunity there, a lot of opportunity for them to help democratize automation across organizations. >> Yeah, I mean, I think the big theme last year we heard, "Three things, top three things at AnsibleFest 2021, Animation, Automation, Automation." Again, this year the same theme, "Automate everywhere" is what they're talking about. But I think you're right, there's a cultural shift where the entire cloud ecosystems kind of spun to the doorstep of what Ansible's ecosystem stood for for many years in the decade, which is configuration, running things at scale. That notion is now persistent across all the enterprise. And I think the key takeaway from the keynote, in my opinion, is that configuration and automation around devices and infrastructure stuff is an enterprise architecture now, it's not just a, kind of a corner case, or a specific use case, it's going to be native across the entire enterprise architecture. And that's why we heard a lot of cultural shift conversations. And that is where the people who are running the Ansible stuff, they're going to be the keys to having the keys to the kingdom. And I think you're going to see a lot more of this automation at scale. I love the introduction of ops-as-code, that's a little piggyback off of infrastructure-as-code and infrastructure-as-configuration. They're saying operations now is the new software model and it's like ops dev, not dev ops. So it's really interesting to see how the operator is now a very big important role in the next level of cloud native. And it's really exciting because this is kind of what we've been reporting on theCUBE, for over 12 years. So, watching Ansible grow organically into a powerhouse community is very interesting. To see how they operationalize this, you know, going forward. >> Well the operator's becoming really pivotal catalysts in this next way, that you've been covering for 12 years. You know, if we think about some of the challenges and the barriers to adopting automation that organizations have had, one of them has been skills, staff rather. The other has been, "Hey, we need to really determine which processes to automate, that's actually going to give us the most ROI, most bang for our buck." They talked a little bit about that today, but that's still something that Ansible is working with its customers and the community to help sort of demystify. >> Yeah and I think that they were front and center around, "You on the room," people in the room, "you make this happen." They're very much, it's not a top-down corporate thing, Ansible staying true to their roots as I mentioned. But the thing about skills gap is interesting, you heard Kaete Piccirilli talking about, "Level Up how your organization automates, push your people, expand your scope." So the theme is, the power is in the hands of this community to essentially be the new enterprise architecture for operations. At the same time that feeds the trend around, we're seeing this accelerated cloud-native developer we're seeing, we're going to be at KubeCon next week, that cloud-native developer, they want to go faster, they want self-service. So you're seeing higher velocity cloud-native development putting pressure on the ops teams to level up, so the theme kind of connects for me. I think Red Hat has got it right here, with Ansible, that the theme is shifting to ops better get their act together, to level up and to the velocity of what the developers are expecting. At the same time, giving them the freedom to be using infrastructure-as-code, infrastructure-as-configuration, and ultimately, ops-as-code. To me, I think this is like the evolution of how infrastructure-as-code, which is the nirvana of DevOps, now is ops-as-code. Which means, if that's true, ops becomes much more invisible, if you will, which is what developers want. >> And we're going to be breaking down ops-as-code today, no doubt, in our conversations with some of the great Ansible community folks and partners and leaders that we have on, as well as tomorrow in our full two days of coverage. You talked about cultural shift, we talk about that a lot John, it's challenging, but one of the things I think that was very palpable this morning, is the power of the Ansible community. Not just those folks that are here with us in Chicago, but all the folks watching virtually online. >> Yeah. >> Truly help drive that cultural shift that is needed for organizations to really be able to streamline cloud ops. >> Yeah and I think Adam Miller who came on, I thought his portion was excellent, around community. He talked about, you know, the 10 years, put a little exclamation point on that. Managing the communications within the community. He actually brought up IRC and Slack and then, "We have Discord." And they introduced a new standard for communications it's called Matrix, which is open-source based. And even in their decision making, their principles around open source stay true. Again, they checked the box there, I thought that was really cool. The other thing that, within the meat of the product, the automation platform, Matt Jones was talking about the scale, the managing at scale, is one thing. But the thing that I think that hit, jumped out at me, was that this trusted automation messaging was really huge. Signing, having signatures, that really hits the supply chain that we've been talking about, and we're going to talk about it next week at KubeCon, the software supply chain is trusting the code. And I think as you have automation, it's a really big part of the new platform. So, I thought that was really the meat on the bone there. >> That was a very strong theme, was the trust this morning. You know, another thing that was important was Walter Bentley, who's coming on, I believe, later today, talked about how organizations really need to think about the value that automation can deliver to the business and then develop an automation strategy, really thinking at it strategically rather than what a lot of folks have done. And they've put automation in sort of in silos and pockets. He's really talking about, how can you actually make it strategic across the organization and make sure that you really fully see and understand and can articulate the value to the business, from a competitive advantage perspective, that it's going to deliver. >> Yeah, and Stefanie Chiras who's coming on too, she mentioned a lot about the multi-cloud, multi-environment layer, how Ansible can sit across all the environments and then still support the cloud-native through what she called "an automation loop". That's going to be really talking to what we're seeing as multi-cloud or super-cloud, next-gen cloud, where Ansible's role of automating isn't just corner case in the enterprise. Again, if it's an enterprise-wide architecture, it will be a centerpiece of multi-cloud, multiple capabilities. Whether that's compatibility services or, you know, stuff running best of breed on different clouds. 'Cause, obviously Amazon was on stage here, they're talking about this, big Ansible supporter. So, we've got Google supporting Ansible, so you got the multiple clouds and even VM-Ware environments. So, Ansible sits across all this. And so, I think the big opportunity that I'm seeing come out of this, is that if Ansible is in this position, this could be a catalyst for them to be the multi-cloud hybrid architecture for configuration and operations, and I think, the edge is going to be a really interesting conversation. We have a lot of guests coming on, I'll talk about that. But, I think running distributed workloads across multiple clouds in multiple environments, that's a killer app and we'll see if they can pull it off. We're going to be drilling everyone on that topic today, so I'm looking forward to it. >> We're going to be dissecting that. I like how you paint that picture of Ansible really as the nucleus of that hybrid cloud strategy. You know, so many organizations are living in a hybrid cloud world for many reasons, but for Ansible to be able to be that catalyst. And question for you, if we think about that, when we talk about multi-cloud strategically or organically or whatnot, where is automation moving in terms of the customer conversation? We know Ansible's really focused on smoothing the developer experience, but where is automation going, in your vision, up the C-suite stack? >> Well, multi-cloud is a C-suite message and they love to hear that, but you talk to anyone who's in the trenches, they hate multi-cloud. It's more complexity and there's a lot of issues around latency. So what you're seeing is, you're starting to see an evolution of more about compatibility and interoperability. And this is kind of classic enterprise abstraction layers when you start getting into these inflection points, as things get better, so it gets sometimes more complex. So I think Ansible's notion of simplicity and ease of use, could be the catalyst for this abstraction layer between clouds. So it's all about reducing the complexities, because at the end of the day, if you want to do something on multiple clouds, whether that's run common services across, that's not making it simpler. You got to, it's going to be harder before it gets easier. So, if that makes any sense. So doing multi-cloud sounds great on paper, but it's really hard and that's why no one's really doing it. So you're going to start to see multi-cloud, what we call super-cloud, which is more capabilities on one cloud. And then having them still differentiate the idea that some standard's going to emerge, is complete fantasy. I think you're going to, we still need more innovation. Amazon does a great job, Microsoft's coming up on number two position as well, the clouds still need to differentiate. But that doesn't change Ansible's position. They can still be that shim layer or bolt-on, to whatever clouds do best. If you run 'em on machine learning on Google, that's cool. You want to use Amazon for this? How do you make those work? That's a hard problem. And, again, that's where automation ends up. >> And with that context, do you think that Ansible has the capability of helping to dial down some of the complexity that's in this hybrid multi-cloud world? >> Yeah, I mean, I think the thing about what's going on great here, that's unique in the history of the computer industry, is open source is so powerful and it continues to power away with growth. So, more code is coming. So, software supply chain is a big issue, we heard that with the trusted thing, but also now, how people buy now is different. You can actually try stuff out on open source and then go to Red Hat, Ansible, and say, "Hey, I'm going to get some support." So there's a lot of community collective intelligence involved in decision making, not just coding, but buyer selection and consumption. So the entire paradigm of purchasing software and using it, has completely changed. So, that puts Ansible in a leading position because they got a great community, and now you've got open source continuing to thrive away. So, if you're a customer, you don't need the big enterprise sales pitch you can just try the code, if you like it, then you go with Ansible. So it's really kind of set up nicely, this cloud market, for companies like Ansible, because they have the community and they got the software, it's open and it is what it is, it's transparent, everything's above board. >> Yeah, you know, you talk about the community, you mentioned Matrix earlier, and one of the things that was also quite resonant during the keynote this morning was the power of collaboration and how incredibly important that is to them, to stay native to their open-source roots, as you you said. But also really go to where the customers are. And they talked about that with respect to Matrix and Discord and that was an interesting, this is the community reaching out to really kind of grow upon itself. >> Well, being someone who's used all those tools, even IRC 'cause I'm old, all the old folks use IRC. Then the, kind of, Gen X'ers use, and the millennials use Slack. Discord, the way they mentioned Discord, it's so true. If you're a gamer, you're younger, you're using Discord. Now, Matrix is new, they're trying to introduce an open source, 'cause remember they don't control Discord and they don't control Slack. So Slack's Salesforce now, and Discord is probably going to try to get bought by Microsoft, but still, it's not open. So Matrix is their open-sourced chat service. And I thought that was interesting and I think, that got my attention, because that went against the principles of users that like Slack. So, it'd be great. I mean if Matrix, if that takes off, then that's going to be a case study of going against-the-grain on the best-of-breed package software like Slack or Discord. But I think the demographic shift is interesting. Discord is for younger generations, let's see how Matrix will do. And the uptake wasn't that big. Only been around for a couple months, we've seen almost 5,000 members. But, you know, not a failure. >> Right. >> But not a home run either. >> Right. Well we'll have to see how that progresses- >> Yeah, we'll see how that plays out. >> as all of the generations in the workforce today try to work together and collaborate. You know, if we think about some of the things that we're going to talk about today and tomorrow, business outcomes, increasing business agility, being able to ensure compliance, with security and regulatory requirements, which are only proliferating, really also helping organizations to optimize those costs and be as competitive as they possibly can. So I'm excited to dissect the announcements that came out today, some of the things that we're going to hear today and tomorrow, and really get a great view of the automation infrastructure marketplace and what's going on. >> Yeah, it's going to be great. Infrastructure-as-code, infrastructure-as-config, operations-as-code, it's all leading to, you know, distributed computing edge. It's hybrid. >> Yep. All right John- >> Yeah. >> looking forward to two days of wall-to-wall CUBE coverage with you, coming to you live from Chicago, at the first AnsibleFest in person, since 2019. Lisa Martin and John Furrier with you here all day today and tomorrow, stick around, our first guest joins us. We're going to dissect ops-as-code, stick around. (gentle music)

>> Welcome back to AnsibleFest. I'm Matthew Jones, I'm the architect of the Ansible Automation Platform. And today I want to talk to you a little bit about what we've got coming in 2021, and some of the things that we're working on for the future. Today, I really want to cover some of the work that we're doing on scale and flexibility, and how we're going to focus on that for the next year. I also want to talk about how we're going to help you grow and manage and use your content on the Automation platform. And then finally, I want to look a little bit beyond the automation platform itself. So, last year we introduced Ansible Content Collections. Earlier this year, we introduced the Ansible Automation Hub on Red Hat Cloud. And yesterday you heard Richard mentioned on private automation hub that's coming later this year. And automation hub, Ansible tower, this is really what the automation platform means for us. It's bringing together that content, with the ability to execute and run and manage that content, that's really important. And so what we really want to do, is we want to help you bring Red Hat and partner content that you trust together with community content from galaxy that you may need, and bring this together with content that you develop for yourself, your roles, your collections, the automation that you actually do. And we want to give you control over that content and help you curate that content and build a community around your automation. We want to focus on a seamless experience with this automation from Ansible Tower and from Automation Hub for the automation platform itself, and make it accessible to the automation and infrastructure that you're managing. Now that we've talked about content a little bit, I want to talk about how you run Ansible. Today an Ansible Tower, use virtual environments to manage the actual execution of Ansible, and virtual environments are okay, but they have some drawbacks. Primarily they're not very portable. It's difficult to manage dependencies and the version of Ansible. Sometimes those dependencies conflict with the other systems that are on the infrastructure itself, even Ansible Tower. So what we've done is created a new system that we call execution environments. Execution environments are container-based. And what we're doing is bringing the flexibility and portability of containers to these Ansible execution environments. And the goal really is portability. And we want to be able to leverage the tools that the community develops as well as the tools that Red Hat provides to be able to produce these container images and use them effectively. At Ansible we've developed a tool called Ansible Builder. Ansible builder will let you bring content collections together with the version of Ansible and Red Hats base container image so that you can put together your own images for execution environments. And you'll be able to host these on your own private registry infrastructure. If you don't already have a container registry solution, Automation Hub itself provides that registry. The idea here is that, unlike today where your virtual environments and your production execution environments diverge a little bit from what your developers, your content developers and your automation developers experience, we want to give you the same experience between your production environments and your development environments, all the way through your test and validation workloads. Red Hat's also going to provide some prebuilt execution environments. We want to have some continuity between the experience that you have today on the Ansible tower and what you'll have next year, once we bring execution environments into production. We want you to be able to trust the Ansible, the version of Ansible that's running on your execution environments, and that you have the content that you expect. At the same time, we're going to provide a version of the execution environment, that's just the base execution environment. All it has is Ansible. This will let you take those using Ansible builder, take the collections that you've developed, that you need in your automation and combine them without having to bring in things that you don't need, or that you don't want in your automation and build them together into a very opinionated, container image. If you're interested in execution environments and you want to know how these are built and how you'll use them, we actually have them available for you to use today. Shane McDonald and Adam Miller are giving a talk later with a walk through how to build execution environments and how you'll use them. You can use this to make sure that you're ready for execution environments coming to the automation platform next year. Now that we've talked about how we build execution environments, I want to talk about how execution runs in your infrastructure. So today when you deploy Ansible tower, you're deploying a monolithic web application. Your execution capability is tied up into how you actually deploy Ansible tower. This makes scaling Ansible tower and your automation workloads difficult, and everything has to be co-located together in the same data center. Isolated nodes solve this a little bit, but they bring about their own sort of opinionated challenges in setting up SSH and having direct connectivity between the control nodes and the execution nodes themselves. We want to make this more flexible and easier to use. And so one of the things that we've created over the last year and that we've been working on over the last year is something that we call receptor. Receptor is an overlay network that's an Automation Mesh. And the goal here is to separate the execution capability of your Ansible content from the control plane capability, where you manage the web infrastructure, the users, the role-based access control. We want to draw a line between those. We want you to be able to deploy execution environments anywhere. Chris Wright earlier today mentioned Edge. Well Edge Cloud, we want you to be able to manage data centers anywhere in the world, and you can do this with the Automation Mesh,. The Automation Mesh connects your control plane with those execution nodes, anywhere in the world. Another thing that the Automation Mesh brings is, we're going to be able to draw the lines between the control plane themselves and each Automation Mesh node. This means that if you have an outage or a problem on your network and on your infrastructure, if you can draw a line between the control plane itself and the node that needs to execute, the sensible work, the Automation Mesh can route around problems. The Automation Mesh in the way it's deployed, also allows this to fit closer with ingress and egress policies that you have between your infrastructure. It doesn't matter which direction the Automation Mesh itself connects in. Once the connection is established, automation will be able to flow from the control systems to the execution nodes and get responses back. Now, this all works together with automation of the content collections that we mentioned earlier, the execution environments that we were just talking about and your container registries. All of these work together with these Automation Mesh nodes. They're very lightweight and very simple systems. This means you can scale up and scale down execution capacity as your needs increase or decrease. You don't need to keep around a lot of extra capacity just in case you automate more, just because you're not sure when your execution capacity needs will increase and decrease. This fits into an automated system for scaling your infrastructure and scaling your execution capacity. Now that we've talked about the content that you use to manage, and how that execution is performed and where that execution is performed. I want to look a little bit beyond the actual automation platform itself. And specifically, I want to talk about how the automation platform works with OpenShift and Kubernetes. Now we have an existing installer for Ansible tower that we'll deploy to OpenShift Kubernetes, and we support OpenShift and Kubernetes as a first-class system for deploying Ansible tower. But I mentioned automation hub and Ansible tower as this is what the automation platform is for us. So we want to take that installer and replace it with an operator-based full life cycle approach to deploying and managing the automation platform on OpenShift. This operator will be available in OperatorHub. So there's no need to manage complex YAML files that represent the deployment. Since it's available in OperatorHub, you have one place that you can go to manage deployments, upgrades, backup and restore. And all of this work seamlessly with the container groups feature that we introduced last year. But I want to take this a little bit beyond just deploying and upgrading the automation platform from the operator. We want to look at what other capabilities that we can get out of those operators. So beyond just deploying and upgrading, we're also creating a resource operators and CRDs that will allow other systems running in OpenShift or Kubernetes to directly manage resources within the automation platform. Anything from triggering jobs and getting the status of jobs back, we want to enable that capability if you're using OpenShift and Kubernetes. The first place we're starting with this, is Red Hats Advanced Cluster Management system. Advanced Cluster Management brings together the ability to manage OpenShift and Kubernetes clusters to install them and manage them, as well as applications and products in managing the life cycle of those across your clusters. So what we really want to do, is give you the ability to connect traditional and container-based workloads together. You're already using the Ansible automation platform to manage workloads with Ansible. When using Advanced Cluster Management and OpenShift and Kubernetes, now you have a full system. You can manage across clouds across clusters, anywhere in the world. And this sort of brings me back to one of the areas of focuses for us. Our goal is complete end-to-end automation. We want to connect your people, your domains and the processes. We want to help you deliver for you and your customers by expanding the capabilities of the Ansible automation platform. And we want to make this a seamless experience to both curate content, control the content for your organization, and run the content and run Ansible itself using the full suite of the Ansible automation platform. So the Advanced Cluster management team is giving a talk later where you'll actually be able to see Advanced cluster Management and the Ansible automation platform working together. Don't forget to check out Adam and Shane's talk on execution environments, how those are built and how you can use those. Thank you for coming to AnsibleFest, and we'll see you next time.