 Okay, so thanks everybody for joining today. I've got a really special story for you to hear, something that I was involved in firsthand. My name is John Wadley. I'm a principal architect at Red Hat. And I can tell you for sure in the last three to four years I've been involved with a bunch of engagements with healthcare businesses. And Red Hat has been heavily invested in helping healthcare kind of modernize their IT structure, right? We've been collaborating with Blue Shield of California. We have a special guest here, Tye Lim from Blue Shield of California, and as well as... Ooh, I get to introduce myself. Yes, oh, you weren't mic-ready. Not mic-ready. Still not mic-ready. That's our, oh, Olivia P. Varma, customer success executive with Red Hat. And I'm Tye Lim. I'm the manager of a site reliability engineering at Blue Shield. So this engagement involved all three of us, and it's a great success story of persistence and commitment to success and automation, especially on the OpenShift platform. So with that, I'd like our special guest, Tye Lim, to start with his story and our story. Sorry. Okay, so this is the agenda for today. We're gonna do an understanding of the opportunity that, and challenges that we face during our adoption phase, if you will, of Ansible and going into what we deployed Ansible into, or let me be more specific, Ansible Automation Platform, how we began that journey from where we were before we took a look at Ansible to where we are today. And then I'll just showcase one particular effort that we did with respects to moving our automation from various platforms, shell scripting, popped enterprise into Ansible Automation Platform. And then we'll go into what we're looking at for the future. So this is us, stuff on the Wiki page. So I won't dive too deep into this, but this is Blue Shield of California. We're a healthcare insurance provider based out of Oakland, and we have a ton of assets that we need to, in terms of looking at and how we manage our, referring to IT assets. And so this is what we're talking about today, is Ansible on OpenShift. Okay, so here I wanna focus on, a really touch on, I should say, what we did with Ansible at the beginning in terms of understanding what Ansible provided for us. The ease of use, the ability for us to reduce our toil with respects to, in terms of deploying our various automation frameworks, or I'm sorry, automation assets in their despair across the board in all of our IT organizations, and really consolidate everything into Ansible. On top of that, what we didn't wanna do was what we did before. We'll deploy a number of VMs to be able to manage and really upkeep that, because all the VMs that we needed to do in terms of what we expect the load to be on Ansible, that would be immense under many different types of groups with all their various automation jobs, really just hammering away at this environment. So we wanted to do something different, and that was putting Ansible onto OpenShift. And so we'll talk about that a little later in the presentation. Yeah, you really had a big landscape of opportunity there at Blue Shield. You had on-prem clusters with OpenShift. You had ServiceNow. You had a lot of toil with serving VMs, right? Yep. In some cases it took about a month to get a VM, right? In some cases, yeah. And then we had a bunch of different disparate environments that we were managing and having to deploy to for the whole release process, from development all the way to production. And then we took a look at all that and the big picture, and we determined that the best place for Ansible to be on is OpenShift. Blue Shield was trying to leverage OpenShift more and more, trying to containerize more and more. We just actually put their find a doctor application on OpenShift just recently. So that was the positioning and why we went with Ansible on OpenShift. Yep, okay. So I'll touch on this one here. This is where we are, how we built our strategy. Initially from 2021, 2022, up to where we are today in 23, and what we're gonna be looking at in 24. So back in 2021, we really wanted to understand where our automation was. And right now at the time, it was popular enterprise, but it was also only focused on the middle work portion of automation. And so groups such as our storage teams, network engineering, and a few others, really just focused on what they can do with shell scripting, Python scripting, and pretty much homegrown type of thing. And it wasn't a common framework across multiple teams. And so trying to understand everybody's automation strategy was very difficult. And so as we ventured into understanding what we need to do in the cloud, we really need to rein in everything and understand how we can actually build a common, or adopt a common automation framework. So we started to look at Ansible, or more specifically Ansible Automation Platform. And so we'll get to do, I'll talk about how we began that journey and essentially got to the point where we partnered with the professional services to be able to do that effort. Yeah, so I mean, one of the messages I always say a lot of times is automation, disparate automation in different teams and across the organization and different types of technologies. That's not, in my opinion, automation, right? That's still back in the days of everybody has their Bash Script, right? Just everybody has their different type of Bash Script. So that's not what we're trying to do here. We're trying to have a single platform, a single platform where everybody can collaborate with, reusability, right? And then you saw just earlier event-driven automation is gonna leverage that for remediation, right? You can't do those types of things if everybody has their own kind of cookie and recipe, right? So you have to have that platform and central that platform for automation as a start. It also helps to, and you'll hear about this later, start to build a community around that, right? Which is an ideal way of getting that enablement throughout the whole organization, so. Oh yeah, and then last year and into this year, we again partnered with Red Hat Professional Services to be able to understand where we're gonna do take our puppet enterprise environments, our various modules that we've written and migrate that over to Ansible. So we'll go into a little more detail in a bit, but we wanted to be able to understand where these various groups were building their automation in puppet, and then how did we have to get to the point where they deploy into Ansible. And ultimately get to your cloud vision, right? Which is, it was at a moment when you were trying to say, okay, we wanna get to cloud, but we wanna do it the right way, right? We had this experience with on-prem, not the best was. And we wanna make it a lot better going to the cloud if we're gonna make this decision there, right? Exactly. And then in our decision of why we went to OpenShift for Ansible versus just deploying a number of VMs. So we'll touch on that as well. And then what we're looking for beyond is where are the new tools, new processes that we're gonna be actually looking into? Managed services on Azure is one aspect of what we can probably take Ansible to the next level. But so that's what the future we're looking at. Let's go to the next slide here. So here I'll be talking about how we began our journey, what we did, how we went about going about doing it, and what we eventually wanted to actually accomplish all this whole thing. And the proof of concept was the beginning or the emphasis of what we're gonna move into. So we had a few challenges, but we also had opportunities. And so as I mentioned before briefly, that we adopted Puppet Enterprise internally for some of our automation and really focused really on just middleware. And the groups that did not adopt Puppet Enterprise they shied away from only because of the the immensity of trying to understand Ruby as well as Puppet's DSL in terms of how to develop their automation. And so a lot of groups like networking, storage, and a few others, really they weren't focused on being developers. There were more administrators trying to manage the platform. And so the struggle there was trying to get them to adopt a framework. So Puppet never came to fruition for some groups. Other groups that were more developer focused such as the middleware teams really took Puppet into embrace Puppet, but it had to be a really had a developer mindset to do that. So the opportunity for us with Ansible was the ability to essentially develop our automation without the need for complex code such as Puppet. So we were able to write our YAML which is such a plain English to be able to describe what we want and deliver the actual final product. Excuse me. And then as we ventured on to cloud deployments we also needed some, it was another issue there where we need to understand how we were able to manage to automation. Homegrown scripts, Puppet, they weren't really good use cases for us. And so what was in terms of how we want to be able to deploy assets into the cloud. And so I'll talk about that in the next section but in terms of how we wanted to address the cloud Ansible fit our needs much better than anything we can actually utilize. And then we wanted to rein in all the various applications sprawl that was occurring in our environments. We had so many ways to deploy a J2E environment and multiple groups actually deploying that but then when it came down to it one group were doing it one way, one group was doing it another way but then they're all achieving the same goal. So one of the things we want to rein in with Ansible was to consolidate everything as well as put everything into a single source of truth in terms of hey, this is how you deploy a J2E environment. And if you wanted to do something more customizations we can develop workflows to actually really understand how to deliver a specific area or environment customized for a specific request. Anything you got? Yeah, just the application sprawl and silos bit. One of the things that we introduced is the concept to kind of address that because it's really hard to kind of dive into a customer and say, hey, that application, that application, that application kill them, we're going to move on to here. You just can't do that or at least I'm not there for the length of time it needs to happen. So we kind of talk about orchestration automation and I talk about try to do something today that helps you get to your long journey or your vision. So connect the dots first even if you don't want all those dots in the future but connect them and at least alleviate the manual problems around the integrations between the systems. So they had service now, so we tried to elevate and some type of workflow implementation for orchestration around those applications in order also for them to understand that applications a little bit better and why they do need them or don't need them. So when you bring the community into one application or one connected workflow then you kind of have them all understand what's really going on here. But when each piece of the flow is handled by a different team then nobody cares about anything but that little silo piece, right? So it's one step towards solving the big problems which helped a lot. Yeah, it's part of when we were doing a lot of the migration stuff a lot more collaboration in terms of getting things into Ansible understanding the various teams and what they did what they did and then really just really understanding or breaking down those silos in terms of, oh, this is how you deploy this particular environment. Oh, we can add this functionality to your playbook as part of this whole effort. And so a lot of that was happening as we collaborated in terms of how to rein in a lot of these redundant scripts if you will and really consolidating into a single source of truth in an Ansible playbook. All right. So how did we begin this journey? Q1 2022, we approached Red Hat Professional Services to begin the journey in terms of how do we adopt Ansible? At this point, it wasn't how do we adopt Ansible in OpenShift, it was how do we adopt Ansible? And so we had various groups, as I mentioned before, networking Unix and a few others that really wanted to explore how Ansible would actually fit their use case. They're all specialized use case for automating storage, automating network, excuse me, network assets, you name it. And on top of that, as part of the effort as well, Middleware and my old OpenShift team in terms of how to utilize Ansible to manage those platforms. So we began a journey in Q1, it took an entire quarter to actually look at all the various use cases and really develop that and put that into a proof of concept environment. Our proof of concept environment was actually deployed on an on-prem VM, a vSphere VM, and essentially essentially just deploying AAP there to be able to do what they need to do. And so, but one of the things that we did that came out, came out of that effort was as more and more groups were deploying into Ansible, we did see performance degradation in terms of all the people utilizing that one VM to do what they need to do, which later on made a much more better sense in terms of where we wanted to put it, which was OpenShift down the road, which I'll go into to that factor. Yeah, this collaboration was important and this step was very, very vital because it was kind of like a redefinition of how BlueShield even does their intake process, right? So we talked about application sprawl and stuff. The habit was we buy an application, we use an application, right? In this case, it wasn't, we buy an application, we have this, let's try an application first. Let's not over commit ourselves. Let's just play with it for a second, get used to it and think about how we're gonna use that across our whole landscape, right? So we didn't worry about the installation of Ansible, we did it on the standalone server as simple as possible, as basic as possible, but we focused on the product itself and the value that it brought to the business. So that was a win-win for Red Hat and for BlueShield together and a lot came out of that. Oh yeah, all right, so as I mentioned before, I'm gonna talk about migrating over to the Ansible platform, why we chose OpenShift and essentially talk about what we did in terms of scoping out or working with the development, IT development teams to actually migrate from Puppet Enterprise to Ansible. And so, why Ansible? So I mentioned before the application sprawl, the technical debt, the various amounts of Puppet modules that we developed from various teams to be able to do the same thing. So with essentially the complexity in the code for various Puppet modules, depending on what it was addressing, the learning curve to understand what those modules did was really steep. So a lot of groups really took a long time for them to be able to understand how something got done and replicated. And another thing too was when those Puppet modules were developed by contractors and they leave, well, the guys who have to support it, they still, lot of them did not adopt the understanding for wanting the desire to understand Puppet, so it got that much more complex. Another thing we looked at with AAP, which was great, was the development of REST APIs within the platform. So I mentioned that we're already utilizing AAP to do a lot of our work, but one of the things that we also did was, or utilize, is that we were able to build those REST API calls and essentially incorporate that into our scripting to be able to call out a function, say, deploy a resource group in Azure, deploy a VM in Azure, develop that workflow, essentially through these various calls or a call to that workflow. And so the REST API integration in part of the platform was a great feature for us for able to really execute what we need to execute. One of the things that we're also looking at is how we incorporate these REST API calls into something like Jira. A web book in Jira to be able to execute when a particular Jira issue is created and be able to, say, deploy an environment through the execution of that REST API within the Jira framework. So that's one of the things that we're looking at experimenting with in terms of how do we streamline our operations in the utilization of Jira. And another reason why? Yeah, it was just easier to read. So again, mentioned before, Puppet, now being adopted by various groups, those very same groups that didn't adopt Puppet took to utilizing Ansible much more easier in a less time frame. During the Puppet migration effort, we had like at least four different groups that had built out their entire framework around Puppet Enterprise. And so we had a time frame of three months to be able to get them off of Puppet Enterprise. We were thinking of not renewing the license for that. And so we were able to essentially go from zero to 100 in less than 30 days. We took their Puppet modules, working with professional services to understand what those modules did. And they coded their playbooks to mimic what they exactly did in their Puppet module and put that into Ansible. And roughly three days from concept, from concept to deployment to production and we're managing our environment. So the two teams that were actually, that really proved the use case was our database team and our middleware teams to actually look at where we were, where they were in Puppet Enterprise, to where they need to be in Ansible. And so we were able to get them all up and going inside of a month. Yeah, the last bullet on the top section, the ease of use and adoption, that's so massive and all the engagements I've ever been in. My focus has always been on enablement and adopting Ansible or adopting automation as a cultural kind of knee-jerk reaction. It's something why, for example, we have Ansible Lightspeed, that you just heard about this morning and AI enablement and to write those playbooks because we're trying to get people that aren't coders to write automation. And so to do that, you have to help them bridge that kind of gap. And I would say at least Ansible does that because we're leveraging YAML, we're talking about desired state, we're not talking about if then else functions, complicated coding practices, we're just talking about very high-level descriptive language. So that's why that AI Lightspeed is like, I want to install a VM on Azure, and then it plays out the whole task for you and done. So that's the kind of idea that we wanna do when we work with customers, is try to enable various teams no matter what your skill sets are to get you to start thinking about automation. And then the last part, yeah, so why did we put a Ansible automation platform onto OpenShift instead of just deploying a number of vSphere VMs and like how we traditionally do our various platforms? So one of the toil issues that we have is expanding our VM environments to meet particular performance requirements. Say if you have a J2E environment, you wanna add more processing. Sometimes you add more processes on there like more JVMs and such. And sometimes they're occasioned where we have to deploy multiple VMs to low balance against. Well, that's great, but we wanna do something a little more different and maybe a lot more easier than that. So we looked at OpenShift. What are the scalability aspects for OpenShift? Well, we can auto-scale number of replica sets in terms of number of pods we can actually deploy into a namespace of a particular application. In this case, it's Ansible. So we can set up all scaling that way. Another aspect was if we needed to, we can auto-scale the number of worker nodes to be able to horizontal scale that way in terms of adding more capacity. Like as I mentioned earlier as a setup that when we're doing a POC, one of the major things that we saw was performing degradation in that single POC server, that proof of concept server. So where we saw a lot of jobs being implemented, but then some jobs were taking longer to execute. And that's because we had a small VM to be able to do this proof of concept against multiple groups doing all their various use cases against. And so the, and this is just there for, OpenShift was how do we reduce the 12 of us having to scale all the time depending on the growth of our automation? Well, OpenShift provided that. We'll be able to auto-scale on a various needs to be able to essentially define that threshold, say CPE goes over 80%, well let's deploy another worker node and meet the capacity there. Another great aspect of it was we can also draw down the number of worker nodes or number replicas sets depending on demand so we can throttle up. And then throw all down. That was a big factor for us because we didn't wanna be able to constantly babysit something where we had to keep deploying more and more service to accommodate. OpenShift provided that ability for us to do that. Yeah, and it's also a consuming resource, resources that you didn't have, right? Like you have to also think about a lot of customers that wanna automate. They're not in a situation where they have unlimited resources to do lots of wonderful things, right? Usually they're in a limited resources situation and so they're trying to squeeze in some automation to try to do more, right? That's not the situation when you wanna set up a hugely complex type of infrastructure and solutioning that'll be self-managed by people that don't have time. So we have to think about scalability, we have to think about ease of upgrades, we have to think about reduction of resource demand so that we go back to the top part and say let's enable automation, right? Let's focus on enablement of automation, not focus on just managing a platform all the time, right? So that was one of the big things why we went with that and of course that they had OpenShift and the skill sets already around OpenShift so it made complete sense and they had this thing around, of course some of you have maybe Ansible Tower and it's End of Life so that's like another great opportunity to look and reevaluate where you want AAP. So that's something to think about. The last part is there's of upgrades. We had the VM sprawl that a lot of people, a lot of places have. We didn't have to upgrade various servers to do to put them on the latest and greatest version. We just had to update the Ansible operator in OpenShift and you're done essentially and then really move on from there. So it really became that push button effort for maintaining Ansible on OpenShift. And you can always evolve your infrastructure and your solutioning to be more complex and to be more advanced, right? But try to start with something simple and that's gonna satisfy your needs. Yep. Okay, so this is the puppet migration I wanna touch on this a little bit in terms of what we did. So again, with the help of Mr. Wally over here, we took, we didn't talk about with the various teams, what did you guys do? What, we had a scoping effort. We understand where they were, where they are and what they're currently doing with Puppet and really modeled what that would look like in Ansible. And then that way we prepped them for what they needed to do to do playbook development. And so which really from scoping, scoping I think would took the longest. Yeah, the scoping thing was really an important prerequisite and what that entailed was about six different calls that we had together working with each of the SMEs from the different teams that understood the Puppet modules and code and try to understand at a very business value and business stream direction, what are they trying to achieve? And then because ultimately it's a lift and shift because it's, Ansible works a little bit differently with desired state code. So that scoping kind of session really helped us quite a lot to be able to then put together an engagement that can actually drive through and build those. Yeah, and then we went from there to development which for the groups that were involved took about 30 days to actually go from zero to production and then from there utilizing the platform and deploying the platform out to the various environments. You really wanna understand what is being used by Puppet but more importantly what's a priority and what brings the most value to the business, right? Because it's again, it's a moment to pause, crawl, walk, run, pause for a second and evaluate, did we even need this automated? Did we do it right? I mean, what are we doing here? And then determine how it should be in the new world, right? So again, we were doing it the right way and the flow shield was slowing down. Yeah, I think in one instance, we went part of the scoping effort and part which went into development was one group realized, oh, we don't need this. And there was an epiphany moment, oh, we can take this out. Which was great, which means we reduced the technical debt as part of the whole process. And that was because the application was gonna be decommissioned next year. Exactly, yeah, something like that. So there was no need for effort in that, so. Yeah, so that was actually a great aspect of working with you guys. So what's our roadmap look like? Well, we did our initial purchase of Ansible last year in terms of the first set of subscriptions and we started applying that to interning in a very limited fashion. But as we started to adopt it more, we increased the number of subscriptions and we increased our scope of where we're taking it. Initially, as part of the effort with the POC, that was more focused on on-prem. But as we dived more into the cloud and building our cloud strategy, a lot of the effort now is focused on how do we manage our resources, our IT assets, in the cloud with Ansible. So I mentioned earlier that we're looking at Azure. How does managing resources at Azure look like in terms of deploying a resource group, a resource mapping, and a VM or managed service? So we're looking at those things today in terms of how we're gonna be able to do that. And then really 2023 and beyond is looking at other functionality or which we can actually deploy into Azure 4. Other managed services, other things that can help support our Ansible narrative. So I'll look into the future. So really it's about cloud automation for us understanding where we're gonna be going in terms of how we're gonna be managing our resources, not just Azure, but other platforms as well, GCP. And then really looking at how do we leverage that? How do we evolve our current Ansible environment? Well, today we're on Ansible and OpenShift, but the potential for Ansible on Azure is there. So looking at that managed service as part of probably a potential future strategy. And then really building a service catalog of all of our various REST APIs where groups can just look at our catalog, pick out what they need to perform a particular action, call that REST API, and do what they need to do. So we're looking at how do we organize better our automation in terms of how can other people consume what we develop or whatever group writes and how does other groups consume their efforts. And then today we have a steering committee that helps guide our Ansible efforts. And then building what, and Olivia will go into this in a second, our community of practice. How do we get other groups within Blue Shield to actually to understand how to get onboarded into the Ansible framework, how they utilize it, where they can get resources to help develop their application or their automation, excuse me. And you're essentially going from there in terms of how to support that. I think that's your word. Yeah, okay, I don't want to yell at everybody here. So throughout the presentation we've been talking a lot about the people building a community, adoption. So when we think about the community we're really thinking about, like Ty said, a community of practice. It's not a new term, I'm sure most of the folks here have heard it, obviously according to the pictures it's been around for a long time. But if you don't know the term community of practice it's really just a group, like I said, a community of people that are coming together with a shared interest, a shared passion. They want to address a problem and they can do that through ongoing interaction and engagement with one another. And we at Red Hat unsurprisingly really love community of practices as an open source company. It's an opportunity for us to allow folks to come together and maybe build a partnership that they would not have otherwise. They can spread knowledge through discussion. They can learn about new tools and they can bring that back to their respective customer sites, they can bring that back to their groups, you name it. So talking about it in the context of BSC was really exciting for us because I think John mentioned this word a couple of times, adoption. My job in customer success is really focused on enablement, adoption. I'm not going to ask for a show of hands here but I'm pretty sure if I did. If I asked folks here, have you ever purchased a technology or product or sold a technology or product that became shelf wear, right? You bought it, let it sit on the shelf, we'll deal with it later. I'm sure a lot of you here probably know something about that. So community of practice is a great way to introduce folks to that new technology, that new solution and have people start talking about it, and that ultimately and organically will foster that adoption that you're looking for. So why are we talking about it in the context of BSC? Well, we're super committed to the long-term success of all of our customers and that obviously includes BSC. And when John tapped me on the shoulder when they started this Puppet to Ansible Migration project, we saw that they were already doing it in a really cool way. We didn't call it a COP, but it really was a community. I think Ty mentioned the daily working sessions that they had set up, hours each day. Different application owners would come together in partnership with Red Hat and they would talk. They would talk about their problems. Hey, what issues are, excuse me, what issues are you experiencing today, right? And migrating over to Ansible. Hey, I just learned this really cool thing, right? Oh, I just saw somebody do this. Let's talk a little bit more about it. So they were already naturally coming together and they were getting really excited about it. So we saw a really great opportunity. And so John and I approached Ty, talked a little bit about the concepts, right? Red Hat's perspective. Keep going. Oh, sorry, it's just here. I'll just exit out. Yeah, yeah. But talked a little bit about Red Hat's approach and that's what I wanted to quickly share here. Mission and goals, establishing that at the very beginning is critical. I remember when we had the initial conversation with Ty, he said his goal was to establish Ansible as the enterprise organizational wide automation platform, right? I was thinking about that for the past 30 minutes. That was his vision. That's what he saw. And so now we need to figure out what our tangible goals are, right? How are we going to do this? And then we document it. We document it so it's something that's true to us, true to the group and that we can share that broadly with the team. Sponsorship. Ty also mentioned briefly about an automation steering committee, right? We need a group of folks that have the leverage, right? Do some of the clout at the organization to help us make sure a few things, to help us make sure that we are aligning our community of practice goals with the organizational goals to make sure that we will be successful no matter what, right? We need those folks to help steer and guide the direction but also make sure that we're evangelizing throughout the organization, that we're removing any impediments to make sure that we are successful. Roles and responsibilities is key to identify early on. Poor folks like Ty probably have to, you know, bear a lot of the work early on on their shoulders, right? It's a group effort. It takes a village but establishing those core roles, the leadership roles to really get it off the ground and going. A great example of this we talked about putting together at the early days. Just a quick presentation. Hey, this is a COP or this is what we're trying to do here. This is why it's so awesome. This is why it could benefit you. Somebody like Ty as the key driver of that COP can start to bring that to different groups in the organization. Hey, this is what Ansible is. This is automation. This is what it could do for you, right? Start to figure out ways to bring other folks into the community. Tooling and resources. We want, we want to make it easy for folks to onboard to a solution or to the platform, right? Having a common repository that people can contributely, excuse me, regularly contribute to and take away from is absolutely key. And it could be something super easy. Could be your Microsoft team, SharePoint, whatever it looks like, but have a place where folks can access so they can onboard quickly and easily. It's all about information. That's what it's truly all about. And then consistency. And this is probably the one where everybody's like, oh, yeah, yeah, yeah, yeah, we'll be consistent and nobody ever is, right? But it's figuring out what your cadence is and sticking to it. Community, the purpose, again, like I said, the definition is people meeting regularly together, right? So figure out what your cadence is and stick to it, right? Bring in a variety of topics. You can have a working agenda that other folks can contribute to. Hey, I heard about this cool thing the other day. I'd like to talk about it a future COP. Whatever it looks like, have a place, a common forum and continue to move forward. And the last thing I'll say, and it's not here on the slide, but it's all about measuring your success. I mean, it's in general just, excuse me, important to do that anyway. But I think having a place where we can continuously show to the folks of the community the progress that we're making, the outcomes that we are achieving and striving for, the data goes a long way. It's an incredibly powerful message and it will continuously help you invite other folks into your community and then also be an opportunity to galvanize your community to continue to grow. And so with that, I'd like to pass it over to John and he'll provide a few examples of some of the success metrics that we've collected thus far with this project. Thanks, Olivia. You keep that. Oh, I guess, okay. I got my portable one. And just before I hit that, just wanted to, I like the consistency part. Consistently inconsistent, right? But also on this, I just wanna note, there was a moment on the calls when we had with Blue Shield when I was like, it was an amazing moment that I appreciate doing the delivery side of things. And it was when a Blue Shielder said to another Blue Shielder, I don't know if that's a word, Blue Shielder. It is now. Sure, it is now. Yeah, what did two Blue Shielders say on an automation community? Yeah, fellow Blues, there we go, two fellow Blues. What did two fellow Blues say on an automation community call? It's not a joke. And they said, hey, that is not acceptable. That's not our standard, right? You need to change that code because that's not what we've been talking about for the last month, right? And I was like, I don't need to say that anymore, right? That was the moment when Blue Shield was owning their automation and their standards, right? That was this really sweet moment. Anyway, so onto the metrics. So here's some of the metrics. Some of them are a bit young numbers, I'll say, because they just started, right? But they're awesome numbers. So we have six OCP clusters that are also being managed a little bit by Ansible. We have 120 people already in the community at least, and that's growing today because we're also helping their security team do automation. 2,500 hosts now already in the infantry and Ansible platform being managed. 733 templates, mostly to manage their cloud kind of VMs and everything, right? And networking. 95 users, pretty impressive. Those are active users, to be honest. Yeah, and still 75, it says there. That's 75 Ansible teams. Okay, so 75 Ansible teams, not teams in Ansible platform. And three different regions. So obviously Blue Shield of California, it's being mostly in California, but they're also leveraging Azure. So some really fantastic numbers to kick it off. And with that, the last words, final words as we would say, maybe Ty? Yeah, so we're still at the beginning of this effort that we're doing. And so we're running into issues, but then we're also understanding the challenges and that each one of them are essentially gonna become opportunities for us to do better. And so really, we're at the beginning stages of our effort in terms of Ansible, the cloud and a few other things. And so the point I'm trying to make is, we're just gonna keep improving on top of what we did before. It's a journey, right? It's a journey. Yeah. Yeah, and I would just add to that. It is a journey and like Ty mentioned, they are at the beginning stages, but we are too, right? Lockstep partnership with BSC in this journey. We're, it's amazing to see the progress over the past year. It's just been amazing to see their strategy unfold and we're really excited to continue to work with them to support it. Yeah, my last words is basically, thank you Ty Lim because these types of things are not possible without somebody who's like devoted, devoted as an automation evangelist. I like to use that term evangelist. I mean, there was never a day when he didn't give up, right? And you need that kind of persistence and perseverance, at least from a red hat side to work with, because it's not easy to change a company like Blue Shield and other financial companies and all these other companies that are trying to transform. It takes time, but it takes small changes each day. And if you believe in that over the longer term, it becomes big change. So change can be easy if you do it in small little increments. Change is hard if you think too much, right? Too much at one time. So anyway, I just want to say thanks to Ty on that one great success story and that's it. Thanks guys. Thank you, appreciate it.