Like the Tao Te Ching, those who seek DevOps often come up empty-handed.  Both the Tao and DevOps are elusive.  (Recruiters find it particularly so.)  And yet, if they open their minds, there it will be, right in front of them.

The DevOps that can be spoken is not the eternal DevOps.
The name that can be named is not the eternal name.
The nameless is the origin of Development and Operations.

Today, DevOps is a buzz word.  The term has as many different meanings as the number of people you ask to define it.  Many people today are captivated by the word, but they fail to see beyond, to the essence of what it means.  They seek to find practitioners of DevOps, but are disappointed when they can’t find any.

Officially, I began my career as a systems administrator in 2001.  At that company, the high-level view of the technical organization was as follows.  I worked within the Technical Operations group.

 
                        +-------------+
                        | Software    |
                        | Development |
                        +-------------+
                          /          \
                         /            \
                        /              \
            +------------+             +-------------+
            | Technical  | ----------- | Release     |
            | Operations |             | Engineering |
            +------------+             +-------------+

From the beginning, I had begun to apply many of the principles that would later become tenets of the DevOps movement.

• Automation of our operating system installs (Kickstart and Jumpstart).
• Lots of scripting (Perl, Bash, Python).
• Configuration management of servers (CFEngine).
• A central management server, with password-less SSH access to all the other servers.
• A whole lot of monitoring tools (too many to list here).
• Code and configurations were in a revision control system.
• As a company, we also automated our code builds and deployments
  (done by our Release Engineering team).
• Technical Operations met weekly with our colleagues in both Software Development and Release Engineering — to discuss upcoming releases, the potential impacts of new features to our infrastructure, how best to design those features so that they were scalable, how best to monitor the new services and features so we could identify problems early, as well as planning for additional infrastructure capacity.
• We also communicated with each other though IRC chat.

That was nearly a decade before the term DevOps was eventually coined in 2009.  We were already doing these things, not because it was cool, but because it was common sense.  We saw the value of investing our time and efforts into doing these things.  We were highly productive at what we did.  We were able to manage a large installation of thousands of servers and storage nodes with a surprisingly small number of people.  We were early adopters of DevOps principles, years before it became fashionable to do so.

Another important point worth mentioning.  The company I worked for invested time and money into training and developing the employees within the Technical Operations department.  As “ops” people, we were encouraged to learn scripting and coding.  In essence, the company developed the people it needed to accomplish the work that needed to be done.  It was a mutually beneficial arrangement.  There was very little employee turnover within the Technical Operations group.  I worked at that company for 8 years, and many of my colleagues had similar tenures there.

So, the next time you find yourself looking for those elusive DevOps engineers that you can’t seem to find, you should think about what you are really looking for.  Ask yourself whether you are really looking for the right things in the right places.  For most of you, I suspect you are not.