Several Christmases ago, I was struck by an epiphany. Not the seasonal holiday, but the sudden realization we were in the middle of what I believe is the second-largest disruptive change in the Information Technology field behind the emergence of the Internet and the World Wide Web.
So, what happened? I was starting a new centralized log collection and alerting project at work. At the highest and simplest level: This was a centralized syslog server that was expected to stay up under a large ingest load as well as provide analysis and alerting capabilities. This project had started, stalled, and moved around various groups like a hot potato over the years, so I was both excited and a little apprehensive to tackle it.
Regardless, I put my hand up in a meeting and said, “I can do it.”
As I began to investigate the options, it was increasingly obvious I would be building this system out on multiple Linux systems. I’ve been a Linux user since 1993, and an admin since 1995. I had been in a Windows-only environment for years, so I took a moment to catch up and survey the current state of Linux and infrastructure management.
I don’t recall how I landed on Ansible. It was likely a combination of the usual Linux/Sysadmin subreddits, the Red Hat documentation and Infosec Twitter. However I got there, I decided to learn more about Ansible over the Christmas break.
As I went down the Ansible rabbit hole, I was directed to Jeff Geerling‘s excellent book Ansible for DevOps. I was both excited and a little ashamed to discover new-to-me technologies such as Vagrant for spinning up virtual machines quickly for testing. Where had this been all this time?
I worked through the entire book over the break, then immediately took the lessons learned and applied them to my new project. It didn’t take me long to realize I would never manage a fleet of bespoke servers “by hand” again. Automation, everything-as-code, was clearly the way forward. I was saving time, preventing technical debt loads, and most importantly, felt confident to test and make changes without fear of having to recover for weeks in the event something went wrong. In short, I was sold on the DevOps philosophy. It occurred to me that if an organization was not using these tools and methodologies, then they were going to get lapped on the track by the competitors who had adopted these new ways of working.
I began to read everything I could about DevOps, the Theory of Constraints, Automation, and even business books I’d heard about but never thought relevant. Eventually, I realized I had a choice: I could stay where I was and settle for a comfortable march to retirement, or I could make a change and work with these new techniques and philosophies.
After COVID and working from home, I realized it was time for change. I left the comfort of the known, safe march to retirement, and took the leap of faith. More on that later.