Log in Account
Log in / Register Account
All Red Hat


Technically Speaking: Automation and hybrid cloud

About this Video

Burr Sutter and Graham Mainwaring of Red Hat discuss Automating the hybrid cloud and Red Hat Ansible Tower in episode 1 of Red Hat's Technically Speaking.

Video Channel
Services and support
Run time
January 16, 2020


[Burr] We'll be speaking to Graham Mainwaring. Graham is a Principal Software Engineer responsible for Ansible Tower technology. What we're seeing, though, is customers' interest in this automation because of their interest in moving workloads across the hybrid cloud, right? Either from cloud to cloud in a multi-cloud kind of architecture, or even back to on-prem or from on-prem back out to a public comm provider. What can you say from a Ansible Tower standpoint? How do we enable that? How do we think about that? Where are we going from a product standpoint?

[Graham] The challenge there is you did data-centered migrations basically at the speed of real estate deals. You know, you have your data center in Salt Lake City, been there for 20 years. And then somebody decides, "Okay, we've bought another company or we're doing something "and now we want to have our new data center in New York." And nobody knows how to configure all the stuff so it becomes this sort of sacred little thing that you can't touch because everybody's terrified if you do anything, it'll break.

[Burr] Right, that's when you create the snowflake server, right? It's kind of this unique, pristine thing. You mentioned that everyone's terrified to touch it. And they don't know what happened to it. I see that as a huge issue with the industry right now.

[Graham] With public cloud, you really want to be able to turn on a dime, so it has to be able to happen at the speed of cloud agility, not at the speed of real estate deals. So the idea with automation is that instead of manually doing all of those steps when you build the thing in the first place, you'll write Ansible playbooks that do those things for you. And that over time, as you need to change the configuration, you do it in a style more like writing code than like traditional system administration, where you've always got this repository of, "what is the actual state of my servers?" and you can reproduce it.

[Burr] Now, there's something really cool about Ansible that people tell me all the time that this is a big deal. So, you can tell me if it's a big deal.

[Graham] It probably is.

[Burr] It's the fact that there's no agent pre-installed on that image, that that's a big, big win.

[Graham] Yeah, so the advantage to that- There's kind of two main things that come out of that. First of all, you can talk to boxes as long as you can talk to them. Like, the same way that you would have connected to them as a human, you can connect to them to run a playbook.

[Burr] Like SSH.

[Graham] Exactly. If you just have a username and password, you can SSH and using a username and password in your Ansible playbook command. And you don't have to go through this extra step of prepping your infrastructure to be automatable. The other big part of that is that Ansible can talk to devices on which you can't install software.

[Burr] Okay. There's definitely situations I've seen where different DevOps teams are responsible for a certain group or just even one application and they're not responsible for everyone else's applications so therefore, you do want to sequester them in a way so they can take advantage of moving their app to this cloud or that cloud and install it, but they can't really impact anyone else's workload.

[Graham] The hope is that we can provide organizations with the ability for each part of the team to be able to have control over their stuff that they actually need control over and then for everybody else to treat that as a deliverable but they don't necessarily have to know how to do all of the things in all of the parts that aren't their focus.

[Burr] And so having that nice segregation is really nice and of course, the audit trail is incredibly valuable also. And that's all part of Ansible Tower.

[Graham] Yes.

[Burr]  When I run Ansible Tower within my data center, where would I run Ansible Tower as a customer?

[Graham] You can choose to run it wherever makes sense for you. Probably, it makes sense to run it close to the things being automated. So Tower adds a role-based access control system that allows you to delegate those kinds of responsibilities to people who can then either go to a web UI or use some other system that communicates with Tower through a REST API to make Ansible-type things happen in a controlled way. The other side of having control over that is where I want to have an audit trail- I want to know who did what in my infrastructure and what were the results.

[Burr]  And that's an incredibly important point. We definitely see within our customers they have these regulatory concerns, these security concerns, whatever compliance and to whatever multi-letter acronym that they have to pass a test for. That is a big issue, right? Knowing who did what and when and having that audit trail is super critical.

[Graham] The simple fact is you can't trust everybody and you have to have some kind of management control over who's doing what because there's a lot of enterprise value at stake.

[Burr] You actually really have taught me something new today 'cause I was unaware of that aspect of using Tower for that style of use case. Thank you so much for the conversation today. I learned a lot and I had a great time talking to you and I definitely enjoyed, you know, hearing more about Ansible Tower and the nature of automation and what it means to the hybrid cloud.

[Graham] Sure, thank you. I enjoyed it as well.