 Welcome back to Red Hat Summit 2023 and AnsibleFest at Boston, Massachusetts. My name's Paul Gillan, my colleague Rob Streche is here with me. And AnsibleFest is pretty important part of this show because two of the biggest announcements here were related to Ansible Automation. And we're going to talk Ansible right now with a company that has been using it in production. Ryan Searles is VP of Solution Architecture and Cloud Migrations at TransUnion. I can't say I've ever met someone before with the title of Cloud Migrations in their title. That's really remarkable. So let's start on that note. First of all, just briefly what TransUnion does and also where you are in your Cloud Migration plan. Sure, thank you. So TransUnion, we are a global information and insights company. We create a true picture of people to make trust possible. So the best example I can think of is a landlord that wants to rent their house to a tenant. They want a true picture of who's going to rent and then once they get that true picture they can make that decision to rent. So that's TransUnion globally 35 countries. I've been there 23 years. So our journey with Ansible, we started out as a build forward shop. So centralized control. We've been doing automation for many years, 15, 18 years. But three years ago we realized that we can't have everything flow through one team. Just was taken too long, it took months. And so looked at Ansible, evaluated it and said this is the tool that's going to allow us move from centralized control to centralized standards and centralized execution with the distribution out to the teams for innovation and for the actual building and maintaining of their automations. And just some context for this direction. How much of your infrastructure are you moving to Cloud? Is it, are you going full bore or are you keeping someone in premise? Is it a hybrid approach? It's a hybrid approach. We have certain regulations that require things in certain countries and in the U.S. on-prem. Let's say 50% of our applications, we are our goal of Project Rises to move into the cloud. Yeah, I was going to say that regulation has to play a pretty important role. And has that helped you, the automation that is, has that helped you really help distribute your governance out to those different groups so that it wasn't so centralized? Yes, yes. So role-based access. So again, we used to have a team that only they had the full power globally. Now that we have automations occurring in places like the United Kingdom or you have GDPR, you have places like in India where there's tight regulation with the Reserve Bank of India, we want to have role-based access to make sure that the people in India have the control of their automations and that it isn't questionable of who can make changes to it and it's audited. So that central team must have created quite a bottleneck. What were the wait times you experienced? Yeah, I mean it was, you know, they were, I don't want to disrespect them, they were an awesome team, but it was a long wait time. And so in some cases it was months, teams would have to wait in line and the execution even would be through the central team. So it could have been months, it could have been weeks. I mean, depending on the priority, it could have been days, but worst case scenario it was months to get an automation implemented and get a deployment implemented. And having in your title as we were talking about the migrations is just having been a migration person and been in that industry. I've worked for AWS, worked with their data sync team and things of that nature. Migration's hard. I mean, it's definitely hard. So kind of help us understand what your journey's been with migrations. Yeah, it's been a roller coaster and literally the process that we built as a team to describe our process actually looks like a roller coaster. So, you know, starting out with understanding a landscape. So we did an inventory of 1000, 1500 of our applications. We looked at kind of a sesty to the applications in terms of the business value to migrate to cloud, technical feasibility, and we developed this wave plan where we had initial lighthouse applications. It's safe to land here. And then you had wave one, two and three. And so that's, we kind of developed that overall plan. And then when the first wave came up, let's look at the business cases. So each application had to understand its costs in the cloud and its costs on premise given the solution architecture. And so that whole solution architecture would describe help us build the business case and also help us build the project plan. And then we managed each work stream independently through a common process of migration. And that's working. Our first year, we had our one pioneer application back in 2021, 2022, we had a goal of doing 10. We did 28. This year we have a goal of doing 100 and we are going to beat that. So when did Ansible come into the picture and how did you learn about what you could do with Ansible? Yeah, for me it came into the picture back in about 2021 where the proposal was, hey, we want to recognize that the automations and the deployment to production, we want to centralize that and keep that consistent. But we also want to go fast. And my goal was, my goal as a migration person is throughput. I want to get applications safely and securely to cloud, to meet our objectives, both financially and technically. So Ansible was the answer for us because it allowed the teams to build kind of gold standard templates, gold standard playbooks and then train each of the individual teams on how to take those and extend those for their applications so that they could run them themselves. We had a milestone in May that my coworker Carlos and I are really proud of a million, million jobs so far, a million automation jobs executed. So we want to do two million hopefully by the end of this year. That's great and I think what's interesting is, like you said, it's all over the world, right? So I would assume that having Ansible being independent open source based on open source but supported by Red Hat and being that it can work with any cloud, that's pretty helpful to what your strategy is. Yeah, I mean we started out using Ansible even before migration to cloud, we used it for middleware and deploying on-prem. You know, we went away from another platform to for our middleware deployments and keeping things consistent. But yeah, because we are standardizing on a single cloud provider for this particular project and we're also standardizing on certain application patterns like a Java application running on Linux, running for using the back end for Aurora Postgres, that pattern allows us to build that once and then reuse that. We have this term we'd call Gumball Machine. So we built a Gumball Machine that has Aurora Postgres with RAL Linux on Java application and so you can generate your own Gumballs because we're going to give you the Gumball Machine to do that. That's the philosophy we use with different kind of build patterns across the applications. Now the devil is always in the details and you had a big organization, you had changing roles, you're giving authority to people to do things that they hadn't been able to do. Your central team probably had been feeling a little out of the loop on this. How did you go about managing all of the organizational difficulties and getting people on board? That's a great question. So that team that took care of the core systems, the shift was you are the team that does all the automation to now you are the team that enables automation and that was a great piece because they started to see themselves as not being the bottleneck but actually being the enabler so that was one piece. But what a couple of the leadership teams did is they actually would build automation teams within their domains. So we call them systems team, we actually call them automation teams. For instance, in US markets, the leader there, her name is Swati, she built a team that was just focused on automations and so they would work closely with the core team to learn the process, learn the tool and then they would work with all the individual US markets application teams to automate the heck out of their deployments. Extremely successful model and so I saw her do that. I went to the international CIO and we said, hey, this is working, let's build an international automation team and that team can take the learnings from the US team who is now disbanded because now the teams have got to do it yourself. Let's build an international team and let's help Latin America, let's help Canada, let's help the UK build their automations and become autonomous themselves. That was our process and that's also working pretty well. Did you run into any glitches along the way? I mean, people taking perhaps too much automation into their own hands? A little bit, yeah, I think there's certain, that's kind of around governance, what are the actual templates that we use are immutable or what can be changed? So there's been situations where these, a lot of these teams are new to Ansible, new to automation in terms of deployments or maybe used to bash scripts or others but so there was that question of trying to decide what is immutable, what should not change and what should be variable or what should be parameterized so the application teams don't hurt themselves. I think that's huge and I think what, because there's a lot of people that are watching this that are on various different points in their journey, especially with migration and I think, we were talking, it's not about the fact that you just lifted and shifted everything, you said you're giving them certain gumballs to move to and certain different deployment patterns. Can you kind of talk to that, how you're helping them not only just bring certain pieces to the new infrastructure but how you're guiding them on those thoughts around the transition? Yeah, I mean, if we were to say to the application teams, what would you like to do? You know, we're going to get a thousand different answers and those answers may be beautiful and they may be, you know, pristine but it's not going to be fast and it's not necessarily going to be aligned to a kind of a corporate standard. So the idea was, let's build a series of kind of types of applications. You know, I mentioned another example would be, you know, ETL application. All right, we like ETL, we definitely need to do that for our company, we don't have batch processing. If you're going to build an ETL application, here is the kinds of servers you're going to need, here's the flexibility and the types of servers and the size of those servers you're going to need, here's the type of storage you're going to need. So we use this template and when you can spin up your infrastructure very quickly by putting parameters in the front end and then you can use that without having to learn about every detail behind the infrastructure because there's this concept of cognitive load. It's people do want to learn about cloud but expecting too much of them to load in a short amount of time so they can meet their migration goals is not reasonable. That template driven or that kind of, you know, pattern driven approach to engaging the teams is what has worked for us. So I'd like to go back to the gumball machine. You don't want to just throw all these playbooks into a pile, you want to organize them and make it easy for people to find the exact playbooks they need. Give us some best practices you learned about how to do that. Sure, so first of all, you know, Ansible has this product called Automation Hub which is a location of all the scripts where they live, all the different automations they live and make that accessible. We also would publish a Wiki that say these are the gold standard. These are the ones that are proven over time. These, and here's what they do and here's the description of what they do. Here's the process you're going to follow to get access to them. And if you have questions and here's the team and the ticket you would create to go with them. So it's a combination of making the gold standards available in the Automation Hub, creating documentation that's accessible both from a access point if you can do it yourself or being able to escalate and reach out to a team if you need help. Those are some of the best practices that we would use. And as far as the cloud migration itself, I mean for the people who are watching who maybe have not migrated to the cloud or are nervous about doing it, what have you learned about an orderly, making that transition orderly? Yeah, I think there's a couple of things that we've learned. I can even talk a little bit about compute. So we had the question, do we need, do we move to EC2? Meaning take like a VM that's running or a bare metal and move that to EC2? Or do we migrate to something like a Kubernetes framework? And for teams that were not experienced with containerization, had not been running on-prem Kubernetes, asking them to totally transform their application and migrate to new types of database software and learn infrastructure as code and containerize was just too much and we just take too long. And so the philosophy was, let's pilot a couple teams that have experience with containers, let them be the vanguard to use for instance an EKS deployment and let's migrate the other teams in maybe not completely modernize their frameworks but give them an opportunity to move to more standard software, move to these patterns we've been talking about but yet leave their application running in EC2 and then teach them how to manage EC2 cost effectively using FinOps. That's probably one of my biggest learnings. What were the major drivers of your decision to migrate to the cloud in the first place? Saving money, flexibility, self deployment? I think it was really, the biggest one was actually improving our security posture. Wanting to continue to keep up with and improve that posture, that was huge because with our cloud migration all applications have to go through the step in the roller coaster process called the security checklist. And that checklist is going to make sure that we're doing the static test, we're doing the dynamic test, we're doing the composition test, we've got the right architecture, the actual what was built was the same thing that was what was approved. And so those are the kinds of things that the main driver was really making sure that all of our application vulnerabilities were going to be moving left and basically being detected earlier on the process as opposed to being found out about when it was really too late. So I think that was probably the main driver. Another driver was TransUnion has to react if there's a big marketing campaign or if there's a, for instance, a breach and then we want to make sure that we give people the ability to manage their own identity. So we had situations before cloud where things would go haywire in terms of demand and we had to struggle to keep up with that demand in a data center. So it was just the ability to hyperscale out to 10 times the amount of servers that we needed in very short order of time that we just would not be able to do on-premise. I think that's the second one. I think the last one is really acknowledging that this is really where technology's going. And we wanted to basically hook our wagon to the cloud providers and other cloud savvy companies and not get left solely on-premise. There's a place for on-premise, but we wanted to basically hook our wagon to the cloud providers to make sure that we're going to keep up with that technology alongside them. Those are the three big drivers. Yeah, I think that makes total sense. And I think there's a lot of people who are just starting that journey. I mean, you were talking about Kubernetes, 60% of the people at KubeCon in the EU were brand new to Kubernetes for the first time. And I think so, you're in good company with that Vanguard program sounds awesome about how doing that. Anything else, I'm curious about the jacket with the project Rise, so. This is the project Rise. So this is Rise of the Occasion, Rise into the cloud. This was really the biggest investment in technology in the company's history. And you know. The jacket? The jacket alone. This is the project, the project is called Project Rise. And that's the name of the program that I get to be a part of. And I lead migrations. Other team members are leading foundation. My man named Sander is leading foundation. We have Meg that's leading program. We have other members, Keisha. Our leader is Shantel, a great team that's driving transformation to the cloud with the company as part of Project Rise. Now I understand you used Red Hat Consulting as part of your migration. What value did they add? I think, I was thinking about two values they added. One is just the art of the possible. New to Ansible as an application deployment platform. New to the concept of distributed collaboration. And so they came in with expertise that helped us see all the things that we didn't even know about. But also just Red Hat in general is an open source company. And so shifting our mindset from hey that's my code, this is my automation to becoming a distributed, kind of inner sourced automation hub. That was also valuable too because that was kind of the unlock that it's safe to inner source, it's safe to open source for this kind of technology because otherwise we're just not going to scale. Two big announcements about Ansible at the show this week, one light speed for Ansible and the other event-driven Ansible, are these relevant to you? Absolutely, yeah. The way we think about, and we're kind of evaluating, transient is evaluating AI and evaluating what we're going to do there, absolutely. We're making sure that we want to do so safely and make sure we protect the data that really belongs to really you and me, ultimately. And so we're evaluating, I think the thing that we see about AI is it's going to help us be more efficient. So instead of having to go and read or having to do this, why kind of learn the vernacular, learn the jargon, learn the esoteric terms, writing an English statement, being able to have that translates into an automation that does what we need it to do, that's a beautiful thing. I also love the event-driven Ansible, self-healing solutions, self-healing platforms. And I was talking to another industry leader today and they told me about how, whenever there's an incident or an outage and they determine that the way to fix it is to do something three times in a row, the problem resolution is write a playbook. And so if that can be automated where it can actually detect an event that's, you know, has reoccurred, execute a known playbook, that's a beautiful thing to improve continuity, business continuity and avoid the manual intervention that people would have to do to respond to it. The rule of threes, that's a great idea. Before we close, what's ahead? What's next? Is your cloud journey going to come to an end at some point or is this ongoing? No, I hope not. I mean, I'm excited to keep working there and keep being involved with this. Yeah, yeah, we want to keep, you know, meet our goals. We want to keep the momentum. You know, we talked to our CIO this morning and the goal is really keep the momentum. But we recognize that in cloud, once you're in cloud, it's actually easier to modernize. It's easier to move to reusable platforms, global platforms, global services, you know, common frameworks. And so I think that's the next big thing in terms of now that we're in cloud, all right, let's now, let's modernize our applications and reduce the amount of redundant functions. And you heard it here first on the queue. Ryan Searls, VP Solution Architecture and Cloud Migrations at TransUnion. Thanks so much for telling your story. It's a great story and one that I'm sure Red Hat would like to run with. Thanks, Bob. We'll be right back in a moment. This is Paul Gillan with Rob. With Rob at Red Hat Summit, 2013. And Ansible Fest. And Ansible Fest, 2023.