A developer friend of mine recently lamented that his boss liked to throw around the term "devops" without having a clue what it means. I give him my five-second definition -- the tools and processes to make agile real -- and he made a face.
"Really, devops just means that ops becomes part of the dev team," he said.
This is a common perspective in and around Silicon Valley. Pretty much by definition, the cloud infrastructure upon which most newish tech companies deploy their applications and services is software-defined. Thus, it's operations' job to "program" that software-defined infrastructure.
That is, if there's an ops at all, because in startup-land the developers often shoulder the stuff ops used to do. The so-called full-stack developer may write code to manage VMs, deploy virtual networks, administer databases, and so on across Amazon Web Services infrastructure or wherever.
As developer and blogger Jeff Knupp has observed, this approach to devops can be less than helpful. "What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (while doing less, less useful work), and lower-level positions simply don't exist."
That's a shame. We don't need top-tier Go developers messing with the bottom of the stack. What we need is a new breed of operations personnel that, as my friend says, becomes the part of the dev team that codes the infrastructure.
Software-defined infrastructure must be in place, of course, and culturally it won't work everywhere. But making ops part of the dev team has the potential to bring the two sides closer together than they've ever been, as well as shorten configuration times for dev, test, and production. Call it "new ops" instead of "no ops."
I realize this might sound like gibberish to an ops person at a small to midsized business. So much leading-edge enterprise technology -- including Puppet and Chef, NoSQL databases, and SDN -- caters to large-scale, customer-facing Web/mobile/cloud implementations where it's all about scale. It's overkill if you're running a few or even a dozen servers.
On the other hand, more and more companies have realized that they need this sort of hyperscalable public presence, and the public cloud has dropped the barrier to entry lower than it has ever been. Call them "devops engineers" or whatever you like, but we need legions of new operations folks who know the new tools and environments and know how to code.
Right now, qualifying as a member of the "new ops" team might mean being deep into Puppet, Chef, Ansible, or Salt. Looking ahead, imagine being first on the block to know Kubernetes and Mesosphere inside-out. The less risk-averse might jump on the really new stuff specially designed for ops, such as the microservices operations and management solution from Nirmata.
Just as American programmers once feared all the jobs were fleeing to India and China, operations has gone through a couple of years of fear and loathing as the cloud seemed to threaten to automate ops out of existence. Yes, the data center is moving from the physical world to the cloud -- including, say, a VMware cloud that might reside in your own data center. But operations isn't going away; the nature of the job is simply shifting to become more dev-like in nature.
Ops folks have plenty of opportunity to step up, sharpen their coding skills, and jump on the latest tools. Get ahead of that curve and you could be overpaid for years.