DevOps Barbarians at the Gate
Full disclosure: I am an IT interloper. I didn’t come to Ops because I love nuanced tickling of cranky, unexampled applications and technology stacks. Virtuoso command-line remediation of obscure and novel service issues is misadventure, not a dais for personal accomplishment. No, I began my career as an unrepentant developer, and came to Ops to automate it: to identify and raze manual configuration wherever it slowed down the business or decreased service quality.
Before Y2K, I must have seemed from an extravagant DevOps future, intent on creating a world where human intent and expertise is encoded in repeatable form, change managed, and habitually applied. Software, not human toil, should be the primary actuator of IT. This is much easier said than done.
With DevOps, BizDevOps, DevSecOps, BizDevSecOps, and DevAllTheThingsOps approaching the limits of hype cycle incredulity, it’s perfectly reasonable for IT organizations to be skeptical or even openly developer-averse. Traditional IT pros and developers come from different realms. One is more like a calling to help people (similar to teachers), with a tendency to tolerate the frustration and hardship that often entails. The other springs from an earnest desire to somehow vulcanize technology tricks into something visibly useful. It’s perhaps why developers’ side projects often involve robotics or other hacks with motors, or LEDs converting ephemeral logic states into physical effects.
IT operations, on the other hand, has been making bezels blink and fans whoosh for decades. A thing with a power cord generating waste heat is clearly doing something -- something Ops is proud to own. They think about their tangible charge before bed and at breakfast and are parentally protective. Their wariness of developers is often similar to the way I regard cats. I generally dislike cats, but reserve the right to like a few on a cat-by-cat basis.
Cats don’t help their reputation by shredding furniture when their claws itch, and developers legitimately earn suspicion when they take production down because of a lack of understanding of real-world operations or poor test discipline. Management eager to adopt Agile principles in IT, implement DevOps techniques, or perhaps even actual Continuous Delivery processes, must be understanding. IT teams’ initial reaction to DevOps is more often than not nervously folded arms all around the conference table.
A coding future
DevOps -- and more specifically, Agile principles -- demand trust from all parties. Cross-team trust that everyone is working toward a common goal, trust that task reassignment by leads is based on most efficient long-term optimization, trust that managers really do understand that fail-fast means accepting more failure, but also trust by management that failures will be better mitigated, eventually, by better resiliency. Perhaps the most important underpinning of trust is confidence, and that’s where the development-minded may help IT the most.
Like it or not, eventually your operations team will need to learn how to code. Not simply guru scripting, but actual programming fundamentals. It’s not helpful for developers to wonder, exasperated, “How will Ops monitor let alone install and maintain this app when they haven’t even heard of multi-dimensional tagging or distributed tracing. Geez!” Instead, what’s helpful is to remember -- although hard to believe -- is that there was once a time before they developed coder furor and faith.
For me, I was 11 and wanted to scroll a game horizontally without flicker, and learning assembly language was the only way to do that. I came to trust that I’d be able to learn whatever was required even while failure is part of the process, moreover, a KPI of learning. Most of all I learned programming was powerful, could be applied to almost any realm, and is uniquely able to minimize tedium and toil. It’s that knowledge that makes programmers effective, rather than dexterity with the stack du jour.
At Cisco Live in July, thousands of traditional admins visited the DevNet pavilion, which had doubled in size again this year. Hundreds of accomplished, command-line, graybeard network engineers attended hands-on Python 101 programming classes, API automation sessions, and more. It’s wonderful to see their smiles and renewed enthusiasm in a shared ah-ha moment of realizing nearly any process truly can be captured in code. These admins will be welcome in IT for years to come.
Empowered IT professionals with deep operational knowledge, but also a fresh desire to learn new skills well outside their comfort zone, are the future leaders of IT teams. With management trust and a little protected lab time, they will break longstanding organization and technological logjams. They are the barbarians at the gate, here not to hasten the destruction of IT from outside, but to save it from within.
Recommended For You
An important key to network management is comprehensive visibility, with advanced performance analytics, all through a single pane of glass.
The demand for real-time business interactions is driving deployments to the “edge” of the Internet where scale is high and latency is low.
Quick deployment of new technologies across enterprise networks is aided by the embracement of cloud technology architectures.
The use of SaaS applications for critical business functions in enterprise branch offices is placing a strain on most traditional WAN infrastructures.
Network automation for deployment and management of digital nodes will be the key to enabling infrastructure transitions to deal with increasing bandwidth demands from subscribers.