Red Hat’s Cloud Domain Architect, Jason Ritenour, sits down with our Red Hat Sales Director, Rich Savage, to take a deeper dive into automation across the public sector.
Rich Savage: Hello everyone. I'd like to thank you all for joining our podcast today to take a deeper dive into automation with Red Hat in the public sector. I'm Rich Savage with the Red Hat team at Carahsoft Technology, and I'm here today with Red Hat's cloud domain architect, Jason Ritenour. Thank you for joining us today, Jason.
Jason Ritenour: Rich, thanks for having me. Good to be here. Always love coming to visit you guys at Carahsoft and looking forward to talking about automation with you today.
Rich Savage: Great. Jason, the team at Carahsoft often receives questions from our government customers asking what automation is and how does Red Hat solutions enable it, and also what benefits will their agency ultimately realize? For our listeners, Jason, let me start by asking you a couple of questions here. The first one that we hear most often is why should agencies consider automation solutions?
Jason Ritenour: Well, that's a good question, Rich. Back when we first started really getting into the automation space, the questions were, "Are you automating?" Today, the question is more, "What have you already automated? How are you doing so? And how can we help you improve and streamline that process?" Now, what we see a lot of times, we actually talk to a lot of agencies today that are already using Ansible or another tool like that to automate their Linux workloads, but then you have the Windows guys that are out doing things on PowerShell. You have the network guys doing their own vendor-specific automation tools. A tool like Ansible has a chance to break down those silos and bring them all together under one umbrella using the same tool, the same like Rosetta Stone basically to bring everybody on the same page, get them all speaking the same language.
Rich Savage: Great. You alluded to a few of them I think already, but what are some of the critical obstacles to automation?
Jason Ritenour: Well, as far as technical obstacles, there aren't really many. One that's sort of technical in nature, but maybe not completely technical, is not having a clear understanding of what you're trying to automate. You look at something and it might look like a single step, when actually there's many steps behind the scenes to get from point A to point B. Then there's other things in the environment that are automated by what you're trying to impact. Take a self-driving car, for example. I can just plug in my destination and you might think, "Okay, that's it. It's going to take me there. It's going to barrel down the road at 80 miles an hour and that's it." But really there's more play. It's got cameras and sensors to detect where other cars are. It's examining traffic lights and signs. It's detecting what the road conditions are like due to the weather so it can adjust its speed accordingly. There's so many different things that come into play with automating even a single task, and you really have to be cognizant of what you're doing and how it's impacting the environment as a whole.
Jason Ritenour: For example, I worked with an agency several years ago. This was actually pre-Ansible even, and we were trying to automate their deployment of JBoss workloads. It was this massive monolithic process before that took several weeks and we started off, we could have very well gone in and tried to boil the ocean and do it all at once, but it ultimately would have resulted in failure. First we began automating just the building of the servers and installing the software. Once we had that working, it's like, "Okay, let's start pulling in the source code and deploy the application, the actual code onto the application once the servers are up." Once we got that win, it was, "Okay, let's automate deploying the load balancer pool and putting a VIP in front of them." Then we hit our blocker because the next thing we want to do was automate the deployment or the request in granting of SSL certificates. The security team said, "No. We don't want you automating that. We want an actual human being to come in and sign off on it and validate the request, make sure it's legit, make sure it's nothing nefarious going on."
Jason Ritenour: That brings me to the second obstacle that we see with automation and that's culture. Now, sometimes there are reasons for being opposed to automation like in that SSL and the security teams instance for example, it was they wanted somebody to actually be accountable for what they were doing and they wanted a human being to have the final say on granting that certificate. Sometimes it's fear of automating yourself out of a job basically. That particular agency I was working with that I alluded to, we eventually got the win and got the security team to go along with what we wanted to do.
Jason Ritenour: It required a little bit of give and take. We had to assure them that somebody is actually going to be approving all requests at the very beginning and somebody on the ops team will ultimately look at the request, ensure that it's valid, ensure that all the other check marks are in place, so to speak, and they will ultimately sign off and be accountable for what's deployed. It was a matter of bringing some of our high level architects in to talk to their people. It's really, you have to take those cultural battles and make sure you understand the other team's concern and help them to talk through them, to give them some assurances in. Sometimes you have to take a step back and maybe not go as far as you initially intended to, but you can eventually get everybody on the same page, I believe. That's something that both the teams at Red Hat and Carahsoft can do. We can help you assuage any concerns that the people that are maybe opposed to automation or afraid of it and help them take that step forward.
Rich Savage: Yeah, I can definitely see that being an obstacle that many IT organizations have to face over time. I think there's a lot of opportunities for automation within an IT infrastructure environment. I guess, what specific processes can agencies automate with Red Hat?
Jason Ritenour: Well, I mean it's not hyperbole to say you can automate just about everything with Ansible at this point. I mean, it originally started off as a tool for just automating Linux workloads. Today, it can automate Windows platforms. Microsoft actually heavily contributes to the Ansible project and it's helped us build modules for both Windows and Azure. On that note, it can automate building things in cloud environments, Amazon instances, relational databases, what have you. It can automate network gear. That's the big thing we're seeing at this point. A big push into automating, building out the network environments, both physical network devices as well as software-defined networking. That's not even getting into the things you can automate that maybe there aren't official modules for, but we can talk to restful APIs and do things against them. We can use the command and show modules to automate things on a Linux system that we don't have a module for. Really, if you can think of it and you can put it to paper, we can probably come up with a way to automate it with Ansible.
Rich Savage: Great. What are the advantages of using Red Hat Ansible over other automation tools that exist in the market?
Jason Ritenour: Well, I think Ansible has a lot of things going for it. The first of all is the fact that it's so diverse. It really is like a Swiss army knife. There are a lot of tools that can, for example, provision workloads in a public cloud, but all they do is build the instances. They can't get in and really do any configuration on them after the fact. They pretty much they fall back into using a shell script or like a cloud init config file. And after that initial run it's done. It can't go in and do like any updates. It can't push any code to it or what have you.
Jason Ritenour: Ansible can do all of that. The advantage it has other over like configuration management tools is the fact that number one, it can do all that other cloudy type stuff. It can build your instances to begin with. It can automate building out the network, but then you get into the fact that Ansible is number one, it's agent-less, so you don't have to install anything on the systems you're managing with it. That gives it a huge advantage from a security standpoint because it's able to just use the native SSH protocols, the WinRM protocols for Windows so nothing to install, nothing to keep updated, lowers the security profile. It is also able to rely on things like SSL certificates for authentication, SSH key. Again, nothing to maintain there and it's nice and human readable as well.
Jason Ritenour: If you've ever looked at an Ansible playbook and compared it to like something like… I don't want to specifically call out any one vendor, but if you look at like a puppet module for example, it's its own special language and it's good, it's efficient and it works. But compare that to like a YAML playbook, and even somebody who's not technical in nature can probably look at it and get a rough idea of what the playbook is trying to do. It is self-documenting in that regard. Agent-less, self-documenting, fast and efficient using all the native protocols that's already installed on the system.
Rich Savage: Excellent. We hear a lot of our customers are moving to DevOps, Dev Sec Ops methodologies going forward. Does Ansible help customers move that direction?
Jason Ritenour: I would say so. You need some kind of tool like Ansible, and I think because of all the reasons I alluded to, Ansible should be that tool. From a DevOps standpoint, it goes back to what I was talking about earlier with getting everybody on the same page. I think it helps the Ops guys who ... I personally am an Ops guy by nature. I know a little bit about a lot of different programming and scripting languages, but I've never been a developer. But using Ansible has helped me get into that Dev mentality so I understand the principles of like putting everything in source control, versioning it, obviously making good comments so my people I'm working with understand what I'm trying to do. I think it helps get everybody on that same page. Again, it helps the Ops guys understand the Dev world a little bit more and I think it helps the Dev world understand what the Ops guys are doing with how they approach deployment and whatnot.
Rich Savage: Are there any success stories that stick out to you that you feel would be relevant to share?
Jason Ritenour: Oh, yeah. I mean everybody who's using Ansible's winning. I mean that's the bottom line. Now the thing with Ansible is we're seeing now like a second wave of adoption. You take customers like NASA who have been using Ansible for a long time and NASA of course has always like on the bleeding edge and then really forward thinking with their adoption of emerging tech. But they were one of the first government agencies I can recall that was using Ansible heavily in production. They actually did a massive data center migration a couple of years ago using Ansible. Today they're now on that trail of automating all their networks. We see a lot of agencies that they adopted Ansible for Linux a couple of years back and now they're saying, "Okay, what else can I automate? I had so much success with Linux. I want to automate my Windows workloads. I want to automate building out networks."
Jason Ritenour: Tennessee Valley Authority is another big customer in the sled space that are doing just that. Now they're on that riding that second wave of doing it, their network automation. On that note, even though they're not like a federal agency, they're certainly in our space and we talked to them a lot. Microsoft, they actually just put out a case study last year discussing how Ansible helped them automate all their network build outs globally. Think about that for a second. Can you imagine 10 years ago Microsoft putting out a statement saying that they were using a Red Hat open source tool to automate anything? I mean that goes back to that cultural shift I talked about earlier. Under the guidance of Satya Nadella, they're much more embracing of open source. They're big contributors to Ansible and other open source projects so that just shows that when you embrace open source and you embrace that culture of collaboration, the things you can achieve.
Rich Savage: The world is definitely changing in the favor of open source. That's for sure. If the first wave of Ansible was data center migration and maybe the second wave now is networks, what might be the third wave?
Jason Ritenour: Oh, it's hard to say. I mean there's so much stuff Ansible can do. I'd imagine the next big thing is you're going to see more tight integration between things like say Ansible and OpenShift. You're going to see, if you look at like an OpenShift 4, there's a lot of Ansible under the hood doing things like the operators and the configuration of your workloads and that kind of thing. I think you're going to see a lot more of Ansible automating these cloud horizontally scaling workloads and the things that's going on behind the scenes in there.
Rich Savage: Great. Thank you, Jason, for all this great insight. For our listeners, if they wanted to learn more about Ansible, where do you suggest that they go to find that out?
Jason Ritenour: Well, of course go to ansible.com. It's still its own distinct site, separate from the Red Hat site, so that's where most of our Ansible content lives at this point. We've got several great white papers there, several how-to videos. All the modules are well-documented there, telling you how to utilize them in a playbook and going over some of the more advanced things like roles and the new thing that we recently added, the collections, where we certify content from various vendors. That's a great place to start. There's also a nice book if you're looking for either a Kindle book or like an actual hard copy, there's Ansible for DevOps, which you can find on Amazon and other fine booksellers.
Rich Savage: Perfect. Those are great suggestions and Jason, thank you again for your time and all the insights and information. We really appreciate it. For our listeners, please go to the suggestions and the websites that Jason's mentioned, and then also there's some additional resources on the podcast landing page that you can check out. Of course, you're always welcome to contact us anytime at redhat@carahsoft.com or (877) 742-8468. Thank you again and see you next time.