Alex Jacocks
Principal Ansible Specialist
SHARE:
We interviewed Red Hat's Principal Ansible Specialist, Alex Jacocks, on getting started in the software industry, his career path, and his experiences with Ansible Automation and OpenShift for public sector organizations. Check out the full video recording and the interview breakdown below.
Background & Career Journey
How did you get started in the software industry?
"How did I get started in the software industry? It's a little bit complex. I am mostly self-taught, but I got started actually back in high school. Friends of mine and I used to play around with early computers in the 1980s, and there were things that we wanted them to do that they didn't necessarily do. So back then, we didn't have a lot of money, and there wasn't nearly as much software out there, so we started creating our own.
I started by learning BASIC, which my mother taught me after she took a course from MIT in the, I guess, early 1980s, and did work with that. What really got me started is we decided we were going to write a better image viewer. Now, you know, the ability to have a beautiful screen and to be able to do anything you want with an image or a video or whatever is kind of taken for granted, but back then it was very challenging. We decided to write a better image viewer for displaying high-quality nature images and things like that on screens of computers people could actually afford at home. We got together, my friend taught himself the mathematics necessary to do it, and then I taught myself how to program in C.
And that's how I got started in software development, and not too long after that, I got an internship by a teacher at my high school with the National Institutes of Health through the National Science Foundation, and that's how I got started professionally."
Was there a particular moment or project that made you realize your passion?
"I think that was even before I got started in the industry, believe it or not. My mom was a professional in the 1960s and 70s, and she worked in satellite communications, but her specialty was publications. She worked a ton, some might even say she was a workaholic, so she would go to work on the weekends voluntarily, and she would take me with her.
As a developing little geek, would see all of this amazing computer equipment, which she would take me into labs, and I could see some of the tools used to develop satellite communications and some of the amazing UNIX equipment out there, and she would just put me in front of things to keep me occupied, but I very quickly ran into something fascinating. My mother put me in front of a system that ran UNIX, this is a late 1970s early 1980s system, and it had a game that some of you may have heard of called Colossal Cave Adventure on it. I fell in love. Just amazing. It was just a text screen, there's no graphics, but it took me away into this magical world, and then after playing it for a while, I discovered, well, wait a minute. There's a way to jump out of this into what's called a shell, a UNIX shell. And I found this powerful system underneath. And I fell in love right then with the complexity and the flexibility of everything having to do with UNIX."
What drew you to automation and open-source technology?
"What drew me to automation and open-source technology? Well, two separate things. Open source was initially out of necessity. As I mentioned before, I didn't have a lot of money like a lot of us who are self-taught, so the UNIX systems that we could afford were the ones that we could find parts for free. So, these would have been old systems, so we weren't going to run any modern, brand new UNIX systems out of the box because in the 1980s and into the 1990s, UNIX systems cost tens of thousands of dollars in those days' money, so incredibly high money.
None of us who are independent, what we called hobbyists, were going to be able to afford that, so we ran into solutions like what's called BSD, or Berkeley Systems Distribution, which is UNIX systems that were free, created by University of California, Berkeley. And then, in 1992, I was introduced by a friend to a thing called Linux, which was just getting started. So, I didn't hear about it right at the beginning, but in August of 1992, a friend told me about that there's this UNIX system that you could go online and download, you could write some floppy disks out and install your own system and have a full-fledged UNIX workstation. And that blew my mind. So, I spent months getting it all working on the old PC that I had, but I did eventually get it working, and that drew me in. And that was my start in open source.
Automation was a little bit of a different thing. I worked professionally as Systems Administrator for many years, and very quickly I realized that automation was key to systems. So, from the beginning, I would install something and configure it, and then something would get changed, and I'd have to go do it again and do it again, or somebody wants something new, I'd have to do it again.
And I realized the way to do better than that was to write shell scripts, and that's how I started my automation journey. But then, not many years after that, I ran into a product called CFEngine. It's a configuration management automation tool that not many have probably heard of, but while it was complex to get started with, once you created a CFEngine configuration and applied it to a system, you could repeat it endless numbers of times. For me as a Systems Administrator, that was world-changing.
I ran into Ansible in 2014, when Ansible is fairly new. I was working for NSA, and a coworker of mine introduced me to a thing called Ansible that he said was really amazing! I still remember it because I thought, well, I'm a science fiction fan, I know what an Ansible is, it's faster than light communication. So, okay, I'll try this. And I was able to create something useful within an hour of setting up Ansible, and that blew my mind.
About two years later, I joined Red Hat, and then I actually got to start working on Ansible itself, met some of the people involved, and the rest is history."
Can you walk us through your career path leading up to Red Hat?
"My career path probably started super early. When I was in elementary school, my librarian introduced me to Apple IIs, and I started realizing, well, wait a minute you could program these things. You could create things.
I didn't learn much about how to do it other than what I learned at home, as I mentioned with my learning BASIC, but that got me started with the idea because I saw the librarian actually reeling the systems out and hooking them up to early video systems where they would use the Apple IIs to do titling on videos. They couldn't do video processing, of course, but you could put titles on them, you could introduce some very simple transitions with the Apple II, and you could manage your recordings. And that was pretty cool.
When I got to high school, that same librarian was there and introduced me to the high school librarian who saw a kid that she could get to help her with some of the library information systems. And myself and a few of the other students who were interested and passionate about this stuff were willing to volunteer their time. The teacher said, absolutely. We'll give it a shot. So, we got to build a lot of the library information systems, terminals and, you know, dial-up systems and things like that that we don't use anymore. It got me working in a world of adult things. So, it wasn't just things I was playing with at home, but creating functional systems that work together, were usable by other people, and I got to really enjoy building functional complete systems.
Not too long after, an internship with the Montgomery County, Maryland school system, and my job was to teach teachers how to use computers. And that was the first time I actually had to try and explain to someone else how something worked. It was a very different world, but I realized through that, even though it was frustrating, made me feel like it was worthwhile. When a teacher said, "Oh, I get that I see what that's for," and then they did something with it, and then I knew some student was going to learn from that. That was really cool, and that really motivated me.
Not long after that, I started fixing computers for people in college, and I got my first full-time job as a Systems Administrator, as I mentioned, at the National Institutes of Health. And that's really what put me into the path of UNIX systems."
Experience at Red Hat
What has been your most rewarding project at Red Hat so far?
"That's a challenging question because there have been an awful lot. I ran into Red Hat in 1996, long before I actually joined the company, and I fell in love instantly. It was a very easy-to-use system, the logo was funky, I didn't initially understand what it was, but it was weird looking. I have the shadow man tattooed on my shoulder because it's such a powerful thing in my life.
The most rewarding project at Red Hat, one of the early instances, and actually fits in with this interview with Fierce Software because I met Eric Updegrove at an early event, not long after I joined Red Hat, and he invited me and a coworker to speak to a user group. And I was fairly new to this, I hadn't done any sort of sales-related work before, so I was still adjusting, but Eric welcomed me in. He really gave me the confidence to do it, and folks who were there responded really well to my presentation and made me feel like, okay, this is cool, somebody else can learn something from something that I experienced! Maybe I can pass it on, maybe I can teach, maybe I can help people get on the right path as far as computing. As we sit here, it's 2025, so I've been working with Red Hat since 2016 and with Fierce Software as a partner since then. That's been a really rewarding and long-term project."
What trends are you seeing in the U.S. Public Sector when it comes to open-source adoption?
"The US public sector, when it comes to open source, it's been kind of a long and varied history where initially they were very reluctant. There was this question of, can the US public sector even use what's called free software? Because there were regulations about the US government paying for things and having to have support for things, which again makes sense for such critical systems. So, it took a long time to get past that, but once we got over that hill, people fell in love with it. The initial traction was individual people in the government developing IT solutions around open-source software. And that's great, but it's not really manageable at a large scale.
So, we have seen the growth of enterprise open source with the sort of work that Red Hat and Fierce Software are involved in over the last twenty years. What's really helping now is its hyperscale, it's obviously folks like Amazon and Azure and things like that. They've really taken control of what drives infrastructure nowadays. So, we have to think about everything in such a large-scale manner that almost the entire world is defined by security, especially in the public sector and automation.
You cannot possibly maintain modern, very complex information systems and hope to be somewhat secure without a really well-thought-out, secure, and automated system. Because human beings make mistakes, so we have to do everything in that area. So that's what's defining a lot of the efforts now. We hear about all these hacks that are going on. We've got various wars in various parts of the world. We have various nefarious groups trying to break into systems constantly, and it's everywhere, constantly. You can never fool yourself into thinking your system won't be a target, because it will, every system will be. And there's no such thing as a 100% secure system, so we all have to do what we can to make it more secure. And the number one thing that I think is driving a lot of those contracts and a lot of those efforts is securing systems, especially our healthcare and our infrastructure in this country.
Automation and security drive so many efforts. Obviously, we're in the world of AI now, but I think that it's a thing that will definitely change how we work, but it's still going to be dependent on automation and security."
What’s a typical day like for you at Red Hat?
"Another challenging question. I'm not sure that there is such a thing as a typical day at Red Hat. Sometimes my days are what you'd expect. I'm a sales engineer, so I'll talk to a partner, like Fierce Software, or I'll talk to a customer, or I'll talk to our services about some consulting engagement they're working on, or I'll talk to a customer about a problem they're having, that they're having trouble having our support engineers understand, so I'll give the sort of the business support engineers or translate what the customer's thinking.
So that can be a day, but also, I have days when I spend the entire day teaching someone how to use one of our systems, and that's always that's amazing. I'll spend a day where all I'm doing is listening to a customer complain. And silly as that may seem, that's actually interesting too because when you listen to the problems people have, it really helps you to understand their perspective. Even if you don't necessarily think that they are correct in the way they see things, you can learn how they perceive them and that really matters a lot."
Or I might be all day on a plane, you know, you never know. The one thing that's universal is at some point every day, I'm talking to someone. My day at Red Hat involves talking or writing and speaking to some person. That's what I do."
What challenges do government agencies face when adopting automation and containerization?
"There's quite a few. The first challenge is that there's still folks in the government who don't understand that these things are critical, that you can't really have enterprise-scale open-source software deployments without automation for sure, and that containerization is not a scary thing. It's not this, you know, bleeding edge technology that, you know, maybe they have to be careful of, that maybe there are negative security implications for, that it really exists to make their life simpler. So, you can deploy things as, you know, completed functional blocks rather than just all these little pieces that do a single thing. So, you can you can deploy a whole system in a container, whereas if you're installing all the individual bits of software, it's very hard to make that scalable to modern hyper-scale systems.
So, I think that one of their biggest challenges is understanding. But it's also that we have a lot of legacy technology out there, and as it should be, actually. People like to use legacy as a bad word, but it really isn't. If you think about it, if we changed out all of our tech for what's new and what's on the cutting edge every year, we'd never get anything done. But also, again, I'll go back to the security implications. There's no way we could ever secure such a system.
So, you really have to think about how you evolve existing systems and how you integrate them with new technologies like automation and containerization. And again, automation can help you do that. But the combination of educating folks and having them understand dealing with the security requirements of US public sector systems, and bringing those new technologies into play is, I think that's one of the biggest challenges we have with those technologies."
Red Hat Ansible & OpenShift
How have you seen Ansible evolve over the years?
"So, when I first encountered Ansible, as I mentioned, I was at the NSA. When I was introduced, it was a command line tool for creating what they called playbooks, you know, reference to American football. It wasn't well understood beyond that, and that's really where it ended, where you would write a playbook and you would hopefully put it in a configuration management repository like Git or like SCCM. It was a single-user creation project, and other users would then consume that automation.
So, the first evolution was the fact that multiple users would contribute to one automation. That wasn't necessarily something that had happened as much in the past of automation, because as I mentioned previously, old tools like CFEngine and to a lesser extent, tools like Puppet and SALT, they're very powerful, but they're complex to learn, so you wouldn't have had all that many folks who could create effective automation. But you would have a few folks create it, and then a whole bunch of folks would use it. But with Ansible, it was simple enough that I could create an automation, and then folks on my team who worked for me could actually understand what I was doing with it. They would say, "Hey, Alex, I ran this thing, and I have to do this extra thing. Can we add that to the automation? Or have you considered this possibility? You know, I ran it 50 times last week, and this, you know, it doesn't quite do this right." And then I realized they could contribute to it. So, we started with that.
We started with the contribution of multiple folks to a simple automation, and then we got into the world of Ansible Tower, which was the web-based user interface and, central management point. That was the next big evolution that brought Ansible away from the purely command line, UNIX systems administrator-type world that I grew up with into the world of software could be used by less technical users. They could use to bring automation to a wider world and to solve business problems, not just technical problems.
So that was an evolution. And then we've had a second evolution when it comes to the modern Ansible Automation Platform. We integrate all of these solutions together. The Ansible Controller, which is our management framework. We've got Event-Driven Ansible, which is real-time automation, which is an amazingly cool thing. We have automation linking into development frameworks and massive auto-scaling of environments using Ansible. So really, I think there have been at least three different revolutions when it comes to Ansible to get where we are today."
Can you share an example of a major success story where Ansible made a big impact in the public sector?
"When I was at NSA, we had an extensive deployment of Puppet, and it worked well. It was great for deploying systems, but the only people who understood Puppet were folks like me, the experienced engineers. For anyone who's not worked in the public sector or particularly in the intel community, which is where I came from or the DoD world, you probably may not understand that the most challenging thing is to find trusted folks for these positions. This is the most critical part. You may have heard of a security clearance.
You may have heard of the interview process. That is the most important thing that the US government has to look for when finding a new engineer is can we trust them. Obviously, we want people who have experience in the area where they're working in, but the most important part is that trust. The fact that the person can keep secrets, can continue to do this this classified work, and not make mistakes that endanger US government missions. So, what that produces is a system where you do have some people that are very talented in areas they work in. There are a lot of folks that are there because they're trustworthy and they're consistent, not because they're experienced in an area. That made automation super critical.
Not long after I was introduced to Ansible, I was able to take that Ansible and automate the deployment of the systems that I managed. I worked on a very important program where we deployed regularly to the internal cloud all the way back in 2014 for folks who think that US government systems aren't advanced. We deployed a large number of systems regularly to new environments, but every time we did it, even though there was Puppet automation, there were a ton of manual steps.
So, we had a three-ring binder, believe it or not, that had all these steps, and each time you would do a step, you would check it off. Each step, check, check, check. And as you can imagine, once you've got 300 plus of these steps to deploy an environment, including all the Puppet automations, there's a lot of room for mistakes to be made. So, I was able to very quickly go from learning Ansible to creating automations to deploy that environment. We took our deployment time from a couple of weeks plus, you know, remediation of errors and pulled it back to deploying environment in, you know, a couple hours, and then having our security automators understand it and then review it and make sure it worked. And we moved our deployment time up by an order of magnitude.
The other important part was that because Ansible was fairly simple, we could actually start to show it to the security certifiers. They didn't just have to verify the result and see, yes, we can check the box, we can run a tool against the environment, see all this list of issues that we know about, all the required controls, and what's called the STIG, which is the US Government Information Security Standard. But we could actually show them, and they would understand this is how it's done. So, we could show them the Ancel playbook because it was written in English and something they could internalize as a person whose specialty is security systems, not necessarily programming or any of these other things.
They could understand and accept that this was the definition of how a system was secure, and that sped things up more significantly because then I could write the Ansible automation, we'll do a demo, secure an environment, and then they check the box, say, yep now every environment deployed by the system passes initial security checks because we know it can't vary. So that was a huge, huge change."
What’s one feature or capability of Ansible/OpenShift that you think isn’t talked about enough?
"Features of Ansible are OpenShift that I think aren't talked about enough. Well, there are a couple of them.
One actually is Ansible and OpenShift together. If you have an OpenShift environment, you don't ever have to worry about Ansible infrastructure again. It's an amazing thing. Ansible is a very powerful tool, but like all other software tools, you got to deploy it. But there's an amazing thing if you have OpenShift called an operator.
You can just click the button, Ansible environment appears, it is scaled to your requirements, it moves around, it is resilient, and you don't have worry about any infrastructure ever again, which is what you want out of an automation system. When you're using an advanced automation system, you want to worry about what the system does. If you can never care about the system itself ever again, that would be perfect, and the OpenShift deployed Ansible really helps with that.
On the OpenShift side, OpenShift and container-based solutions like it, container management with Kubernetes, and advanced developer integration, that's the future of infrastructure right there. I'm a UNIX systems administrator. I've been doing this for more than thirty years. We think about a system as a virtualization platform or a piece of physical hardware or something like that. But the future of those platforms is deployments based on Kubernetes of multiple, what we call pods, of containers working together to create infrastructure. That way, we don't have to worry about any of that low-level stuff. We'll set up an initial system. OpenShift will then manage all the hardware, be it physical, virtual, or cloud. Then you can just deploy your applications. You don't have to worry about anything but an application. So OpenShift is the future of what we think of in the past as infrastructure. That's what it's going to look like."
How does OpenShift simplify application development and deployment for government agencies?
"OpenShift simplifies application development employment by making a level playing field. So, in the past, when we developed applications, either as US government employees or government contractors or consultants or whatever, we had to think about what system are they running. In the old days, it was things like, is it HP UX or Solaris or Windows 2,000, or Windows NT going back to many years past. They were all very different. So, every time you deployed the system, you had to work with all the folks working at the agency and any contractors, and you come up with this agreement as to what the system was going to run on, all the software versions.
A few years later, we got into, okay, what version of Java are we going to run? But once we've done this in a world of containerization on a platform like OpenShift, you only have to worry about your application. You make your application work, you make sure it fits the US government's required security frameworks and integrations with other existing government tools, legacy government software, things we call GOTS or Government Off-The-Shelf Software, and commercial solutions or COTS. But that's all you have to do. You don't have to worry about what the architecture is or what software someone's running outside of OpenShift, what hardware they might use, whether they might move the platform. Today, they're running on Microsoft Azure. Next week, there's a new cloud provider. You can migrate to them almost instantly because OpenShift runs all those places. Does not have to matter even a little bit to the developer. The developers can concentrate on what they do well, which is creating applications that solve US government problems.
And then the problem of how it's going to run or how it's going to function in the infrastructure is taken care of completely by OpenShift. US government employees and contractors and consultants and government appointees worry about the mission of government and don't worry about how the software is going to do it. They just accept, okay, it's going to, and that's that."
If you had to explain the value of Ansible and OpenShift to a government IT leader in one sentence, what would you say?
"Automation is fundamental to modern system success, and Ansible is easy automation, it just works, it works every time.
OpenShift means a level playing field everywhere, so developers can develop what's needed for the government.
That's it. That's all you have to say. These are the tools; these are the easy buttons to get government missions done."
Lessons & Advice
What’s the most important lesson you’ve learned while working at Red Hat?
"Well, there have been a lot. The most enduring lesson I've learned is that it's your responsibility to make your own career.
So, when you join Red Hat, you'll be hired for a position, but you have the freedom to do anything that you really think is important. So, if you see something that's not being done correctly, which I got involved with early on, again, I mentioned working with Fierce Software at the very beginning, I started developing what we called workshops, which were interactive learning sessions. We would work with Fierce Software and some government customer, or some other partner, and they would come to learn. We would set up this whole environment, this virtual infrastructure, for the most part on cloud, and deploy an infrastructure, and the folks would work on it for two hours, four hours, or a day. Then we'd have to tear it down, and we'd do this over and over and over again.
So, we called these environments workshop environments. So, I helped to create some of the early Ansible and OpenShift workshops, and then, actually, Microsoft sponsored me to create the first Ansible workshop on Azure Gov. Those were formative experiences, and those are things that I've worked on that I think are pretty darn important."
If you could give one piece of advice to an organization just starting its automation journey, what would it be?
"Think about what you want to accomplish and plan it out before you get started. Come up with an enterprise automation strategy.
Think about what do you need? What do you need to succeed as an enterprise? Think about your strategy before you take any technical steps. Solve the problem of what your business plan is first, and then Red Hat and Fierce Software can help you provide tools to get it done."
Personal & Fun Questions
What’s one thing about your job that people might find surprising?
"While I am an engineer, I'm an engineer and I've been a UNIX engineer for over thirty years, most of my job has to do with talking, explaining things to people, even simple things.
Most of my job is not coding or creating demos or any of that. It's really helping people, talking to them, and helping them understand advanced technology."
What excites you most about the future of automation?
"I think it's simple is that more and more folks are going to be able to do automation. You have some really advanced AI tooling out there. We have current tools like Ansible Lightspeed, but even more coming. It's going to democratize the creative automation.
My vision of the future world is someone will create an idea, will think, okay, I want a system automation to patch up the system and make sure it deploys everywhere once we've approved them. And then they shouldn't have to put it into a technical language at all. They've got this idea, and obviously, it's a simple scenario, but I would love to see a world where artificial intelligence and machine learning help us to take that idea from a business leader's mind, from a CIO's mind or someone like that, and then make a technical prototype.
And we're almost there today where they can do that. They make this technical prototype, and then the engineers refine it. Or, additionally, where a technical user who has a lot of experience in one system, new system comes along, you know, normally, it's that's a scary day. Right? We all think, oh my gosh, I know this old system so well, now I've got to learn a whole new thing. But what if there's a tool that's there that helps you to translate what you already know?
Imagine a world where you grew up speaking English, and then, you know, you have to learn Italian. Well, but there's a tool speaking in your ear that's saying, hey, you say this word in English, and here's the equivalent in Italian. That's the same thing we're looking for with automation, where we want to translate ideas into actions without requiring knowledge of technical jargon. Ansible and Lightspeed are really on the road to do that, and I think we're going to see a lot more amazing tech and a lot more amazing solutions that'll help people to do that without having to understand syntax and formatting and things like that."
If you could automate anything outside of work, what would it be?
"Well, we had kind of a cold winter here in Maryland. I can think about writing an Ansible automation playbook to shovel my driveway.
We used to have an event in Red Hat public sector called Kingsmill. It was a really amazing time for partners and Red Hatters to come together and just discussing how we do things and reviewing, you know, and feeling like a team and pulling ourselves together. We had a partner do a demo where they actually controlled a drone with Ansible. I thought that was really amazing.
So, we're closer than we might think to that. But yeah, automate some of those everyday tasks that aren't technical, but yet we all have to do. When you like to automate taking out your trash or simple things, automating some of those non-technical problems in our life would really be lovely."