 Yeah, so I heard about Ansible during a time when we were trying to automate our patch process. So our patch process was taking about 1900 man hours per year. So it was highly manual. And so we were looking at some other things like Puppet was out, CF Engine which is incredibly complex. And then in a sales meeting we heard about Ansible because that was the direction that Red Hat was going. So I looked it up and learned about it and that's the other thing, the barriers to entry were so low. It's modular, you can jump in and start learning. You can write a playbook without knowing everything else about Ansible and so that's how we got started with the journey. Okay, so the patches you said over like 1900 hours in a year, do you know how long it takes you now? Yeah, we reduced that to about 70 hours a year. Yeah, so it was a massive reduction in the amount of time that we spent patching. Definitely platform thinking is different. You know, the easy way to look at it and the old big data space too we used to cover that was a tool versus a platform, you know, tools, the hammer and the nail. Did great things, one thing great or a few things good. Platform is more of a systems thinking. Yes. And you got glue layers, you got data, so it's really more of that systems thinking. That separates the winners from the losers, at least in our opinion. Yeah, absolutely. I mean, when you looked at who was the leaders in my wave, it wasn't on the basics of automating orchestration and configuration management, they all had that. The ones that were winners were can I do compliance in a different way? Can I actually have people come into the system that aren't IT people and make a call on some of these things? Can I apply AI and machine learning to some of this? Can I make some recommendations and hopefully direct people in the right, you know, where they should go? And you know, the folks that were able to do that. We look at it as Linux and REL is the one thing that stays the same and helps you get the value out of all the work you've already put in, all the development work you've already put in and make sure that that translates to the future where everything is changing. How you deploy, where you deploy, what you deploy, all of that may change. But if you want to get the value out of the work and the development that has been done yesterday, you need something to stay the same. And in our view, that's REL. We build it with in mind for the enterprise, right, a long life cycle, security, support. We build all of that into it so that when you build on a REL, on a REL kernel, you can take that. If you want to deploy it in a container, you can deploy on REL itself or if you need orchestration, you can deploy it on OpenShift. And that's part of the reason why you mentioned CoreOS. So we now have REL CoreOS is within OpenShift 4.0 and beyond, of course. But what we did was we tailored down what is in REL, it's the same packages, it's the same certification security, all of that work that we put in. We take the CoreOS piece of it, what's essential and really optimized for OpenShift. We build that into an immutable image and it goes out as part of OpenShift. It's not available separately because it's really tailored what we pick. The life cycle is all matching OpenShift. And what that does is provide you an OpenShift experience that's easy to update fully across the board, all the way down to the kernel. But you know it's the same Linux that you have in REL. And it's that consistency of technology that we really strive for. Same thing in public cloud. So when you build an image on crime on REL, you can take that image onto the public cloud and know it's the same level of security and it just will work. You know, part of my team and we take a lot of pride in the fact that it will just work. And while that may not sound super exciting, particularly in days like right now, being dependable and being reliable and knowing that it's secure, all of that is really important when you run your business. That those features are anything but monetized. Sure, thanks. So yes, not a huge focus around announcements. This summit, especially given everything going on in the world around us today. But that being said, we continue our OpenShift journey. We started that, well, many years ago, but in 2015, we had our first release focused on Kubernetes and a container focused platform. And ever since then, you know, we continue to grow and evolve. At last count now, over 2,000 customers globally by trust of the platform in industries, literally every industry and also obviously every geography around the front floor. So that's been great to see. Last summit, we actually announced a fairly significant enhancement of the platform with the launch of OpenShift 4. Big focus around greater manageability, the ability to use operators, which is, you know, Kubernetes concept to make applications much more manageable when they're being run natively within the platform. We continue to invest there. So there's a new release of the platform OpenShift 4.4 based on Kubernetes 1.17 being made available to our customers globally. And then really sort of this notion of over the air updates, right? To create a platform that is almost autonomous in nature, you know, acts more like your mobile phone in the way you kind of manage and update and upgrade. I think it's a key value proposition that we're providing for our customers. But so we're excited to see that and then be able to share that with you first of all. Well, I think as people deploy these environments, there's a lot of conversation about the platform, right? But there's a lot of things that have to go with the platform. And Red Hat's actually been very good about that in terms of providing all the things you're necessary that you're quite necessary to make the platform successful in your environment, right? So obviously you need the platform, but you need the storage and the development environments, management, the automation, the ability to get trained on it. We have our open innovation labs. There's lots of things that are beyond the platform that people require to be successful. In the case of management and automation, ACM is a huge advancement in terms of how to manage these environments, but we're not done. We're going to continue to add more automation, integration with things like Ansible, more integration with observability and analytics. So far from done, but we want to make sure that OpenShift stays the best managed environment that's out there. I also do want to make a call out to the fact that, you know, this team has been working on this technology for the past couple of years. And so even though it's only been at Red Hat for five months, this technology is actually very mature. But it is quite an accomplishment for any company to take a new team and a new technology in five months to do what Red Hat does to it, in terms of making it consumable for the enterprise. So big kudos to the team that are really not there at all. Linux is running the enterprises now. And now it's about how do you bring new innovation in? When we launched RL8, we focused really on two sectors. One was how do we help you run your business more efficiently? And then how do we help you grow your business with innovation? One of the key things we did, which is probably the one that stuck with me the most, was we actually partnered with the Red Hat Management Organization and we pulled in the capability of what's called Insights into their product itself. So all current subscriptions, 6, 7, 8, all include Insights, which is a rules based engine built upon the data that we have from, you know, over 15 years of helping customers run large scale Linux deployments and we leveraged that data in order to bring that directly to customers. And that's been huge for us. And it's not only it's the first step into getting into Ansible. So if you think about it, you know, everybody is moving towards a multi hybrid cloud, you know, sort of configuration, right? Each one of these platforms and clouds has their own set of tools which work really well, perhaps in their particular cloud or their silo or their environment. If you're an organization and you're running multi cloud, you're responsible for automating things that might span these clouds. You don't want to have different silos of automation tools and teams that only work in one cloud or one environment. So the fact that Ansible can automate across these both on-premise and in the public clouds, multiple public clouds, across domains, network, storage, compute, create accounts, you know, do all sorts of things that you're going to need to do. So it's one automation technology that will span the complexity of those environments. So it really it's I don't see how people are going to do it otherwise without fielding lots of people and lots of tools. Different in Ansible and that, you know, I'm like a lot of, you know, old school things like Fedora, you know, a lot of this stuff is newer. And part of the reason it's really important for us to get, you know, some of these folks here to talk to us in person is that, you know, especially and you saw my keynote this morning where they talked about where I talked about modularity. A lot of these folks are really just focused on their one little bit and they don't always have as much time. People are working in lots of open source projects now, right? And it's hard to pay deep attention to every single little thing all the time. So this gives them a day of, in case you missed it, here's the deep dark dive into everything that, you know, we're planning or thinking about and they really are, you know, people who are managing those smaller parts all around Ansible really are some of our best feedback loops, right? Because there are people who probably wrote that module because they're using it every single day and they're hardcore Ansible users, but they also understand how to participate in the community. So we can get those people actually talking with the rest of us who a lot of us used to be sysadmins. I used to be a sysadmin. Lots of us, you know, a lot of our employees actually just got into wanting to work on Ansible because they loved using it so much at their jobs. And when you're not actually sysadmining every day, you lose a little bit of the front lines where the truth of what's going on is right there. And putting all these people together in a room makes sure that they all also, you know, when you have to look at someone in the eye and tell them news that they might not like, you have a different level of empathy and you approach it a little bit differently than you may on the internet. So, probably more quickly and more efficiently with that way. So, one of the other things we were talking to the community about is the feedback loops that you have with the community to tell us a little bit about what, you know, your team's hoping to get from the users attending and participating here. Absolutely. On the Ansible network side, everything is done transparently in the community. We have weekly, we have a community meetup. We've had this for a long time. Everything's out in the open. Everything's in GitHub. Everything that we've done, we've had a contributor day. I don't know if you were here on Monday. It was focused on network. We're pitching this idea around resource models and the forward strategy of the platform as it relates to network. Everyone, including the contributors, developers, the partners, all of the people that you could see that half the vendors here on the floor are network partners. So, they're invested as well. They want this to succeed. So, we're extremely proud and happy that they're along for the ride as well. All right. Maybe explain to our audience what an angry potato is. Was it a tater? It's an angry tater. Yeah, it's the mascot for AWX, I believe, and yeah, they're fun. The sticker's in the little plushies. So, we're going back to the story. Yeah, it's a really interesting conversation. I mean, I think one of the things that the Ansible team's really focusing on that's important is the modularity. The fact that you can plug and play and kind of grow over time. And also that it's a very software-driven paradigm with the automation artifacts under source control, which is kind of different for a lot of ops teams. They don't have that notion of Git and software development all the time. So, I think that having a platform approach that still allows a fair amount of modularity integration and it lets different parts of the organization decide over time how much they want to participate in a very curated, consistent integration. And at the same time, at least in the Ansible world, because of the way it's architected, they can still have modules that call out to other automation solutions that are in the environment. So, it's not an all or nothing and I think that's really, really important. And also it's a platform for analytics, I'm sorry, but data about what's going on with the automation. Another angle we all see when we talk to the engineers that the partners that are actually doing the work to work with Ansible is that they're seeing it as a change also in how they, you know, it's no longer like an individual customer inside an individual data center because everything's so much more open and so much more visible. You know, there's value in them making it appealing and easy for their customers to gain advantage of what they're doing and also the fact that then scales across those customers as well because they have their internal teams doing the same things. And so, bringing them to an automation, you know, capability like Ansible and then we have to push that means that they also gain some, the customer's appreciation for them making it easier to do their task in collaboration with us. And, you know, the best collaborations we've got with some of our partners were all initiated by customers saying, hey, I want you to go and get Ansible content. So the customers are driving a lot of the behavior in the ecosystem. Correct. Yeah, you know, it's very interesting because Ansible was never really targeted for developers, right? And in fact, automation was always considered like I said earlier, like an operational thing. Now, what has happened is entire landscape of IT in a company is available to be executed programmatically. Now, before it was interfaces were only available for a few programs. Everything else you had to kind of write your own programs to do. And now with the advent of APIs, with really rich CLIs, it's very easy to interact with anything and not just like in our software. You can interact with your network devices, with your infrastructure, with your storage devices. So all of a sudden when everything became available, developers who were trying to run, create applications and needed environments to test, to integrate saw that automation is a great way to create something that can now be replicated and be consistent every time you run it. So the need for consistency in replication drove developers to adopt tools like Ansible. And we were like, you know, because at Ansible we never marketed to developers. And then we see that, wow, they are really pulling it down. It's great. The whole infrastructure as code, which is one of the key pillars for DevOps has become one of the key drivers for it. Because now what you're seeing is the ability for developers to say that I can now, when I'm done with my coding, and my application is ready for, say, a test environment or a staging environment, I can now provision everything I need right from configuring my network devices, getting the infrastructure ready for it. We run my test, bring it down and I can do all of that through code, right? So that really drives the adoption. And the cloud. So automation, I think, and my prediction is, is that automation will be as big of a category as observability was. And remember, we kind of missed observability. We saw it as important. We covered all those companies, but it's basically network management on steroids with the cloud. But look what happened. Multiple companies went public. Big companies getting sold for billions of dollars, a lot of M&A activity. Observability is the most important areas of cloud 2.0. It's not just some white space around network management. The data is super important. I think automation is going to grow into a highly competitive, highly relevant and lucrative marketplace for companies. And I think Ansible is in pole position to capture that with Red Hat. And now Red Hat, part of IBM, I think automation is going to be very big land grab. It's going to be where the value is created. I think observability and automation are going to go hand in hand. And I think AI and data, those are the things programming infrastructure revolve around those two spheres. I think it's going to be super important. I think that's why theCUBE is here. We smelled it out. We sniffing it. We can see it. We can touch it. And the community here, they're doing it. They're actually have proof points. This community is demonstrating that the process is going to be more efficient. The technology works and the people are transforming. And that is a key piece with automation. People can work on other things. And it's certainly changing the game. So all three aspects of digital transformation are in block step and expanding rapidly.