Why You Can't Avoid DevOps

Some consider DevOps to be an almighty panacea, a highly cited firmament on which the ops world turns without friction in the unfathomable ether. Most network and application admins, however, take one of two positions: “Yes. DevOps is pretty useful, what’s the surprise?” or “Ugh, I don’t have the time, patience or the team for voodoo. We work here.” There are plenty of vendors showcasing how their wares accelerate all the DevOps, then jump right into Agile, continuous delivery for networks and more, without taking a breath to even build interest for enterprise IT teams new to DevOps.

When I look at our internal IT team at SolarWinds, which is one of the most conservative I’ve ever encountered, I realize it’s also possible for any IT organization to use DevOps to become a vital asset to business, not just close help desk tickets. And as it happens, you don’t really have a choice; it’s coming to enterprises of every size, like it or not.

IT slowness kills

With traditional, siloed, procedural IT, it’s not hustle, frenzied firefighting or even resource exhaustion anxiety that kills team enthusiasm. It’s projects moving at a snail’s place. What IT management often misunderstands is that we don’t spend a month getting new network racks online because we want to, but because monolithic, history-based or poorly designed projects incur risk, and the acceptable IT risk mitigation tool in most enterprises is work by committee. We’ve all been there: Projects that should take a couple of days to actually do, take weeks of roundtable meetings with a dozen or more attendees in the room, and as many more on the speakerphone.

Right about now those of you who already know how to swarm or work a  task board may be wincing, remembering the bad old days before you accepted Agile into your life. You’d say to network engineers, “Guys, create two-pizza teams for your major efforts, segment them into short-term chunks. You can do it!” But the majority of you may be thinking, “Okay, I’ll admit I’m beginning to hear my peers talk about DevOps, but we don’t even know where to start.” Fair enough.

Case in point

Our IT team is incredibly risk-averse, and as a result, very traditional. True, they have to manage a global operation, regulatory compliance and more, but in general, if it ain’t broke -- and there’s no benefit to the bottom line -- don’t fix it. So when they adopted DevOps practices of their own volition, I took note. Their first success was migrating the IIS server architecture in the co-los to continuous delivery.

Ops was managing nearly a hundred instances of IIS in a myriad of roles mostly by hand, from the front door of the .com site to information services, proxies, load balancers and more. IIS on the whole is demonstrably fit, but the Windows server it sits on makes some admins nervous. There are permissions and patching, intrusion detection uncertainty, and general uneasiness about what to do in the event an atypical state is detected.

The existing team, not hotshot new kid contractors, learned Chef and some Ruby for recipes. They created dev/test/staging networks where machine images were built, tested and packaged by scripts. They delegated script configuration from the network team to app, virtualization and storage experts. They created small cross-functional teams to oversee the project, and ended up surprised by something amazing. Every night, on a schedule, without human interaction, entire battalions of fresh IIS machines were spun up, production tested and added into the load balancer pools. Existing servers where pulled out of the pools and purged, and their IPs released programmatically by IPAM. Ops got all fresh IIS/Windows servers, every day, automatically.

More than an epic hack and project success for the team, this first project did the truly impossible: it enchanted management. It demonstrated the real benefit of DevOps in production, which is speed without fuss. DevOps had significantly shortened deployment cycles without additional headcount while decreasing risk through automation. This is the Holy Grail of safe, efficient speed that makes moving to DevOps acceptable for skeptical businesses.

Getting started

The primary DevOps goal is speed, and unfortunately many IT organizations remain the slowest aspect of businesses to change. Today a business’ ability to quickly adapt to pursue new opportunities and new revenue streams is what differentiates it from competitors. Increasingly, senior leadership is observing DevOps’ transition from theory to an indispensable tool.

If your operations team has already at least begun to embrace central Agile tenants of DevOps, and your manager is reporting real benefits up to the CIO, you’re already on your way. But for teams stuck in a traditional world of ticket based, it-takes-a-village-and-six-weeks approach, time is running out. Sooner or later, your enterprise will realize the advantages of DevOps and remodel operations.

network-geralt.jpg

Change may come organically. Perhaps your executive leadership will learn something from external peers, encouraging and empowering your team to learn and explore new skills and techniques. Or perhaps it'll just be you with a chance to be independently strategic, implementing new processes and demonstrating new value or opportunity. Both are great outcomes. But transition may also come abruptly with the arrival of a young CIO who already relies on DevOps, and in six months replaces the “legacy” team.

The goal, then, whether you’re part of a 300-person IT arm of a global corporation, leading the network arm of a tight-knit band of versatile admins in a medium-sized business, or an army of one, is to explore how you can take advantage of DevOps techniques. Take a skepticism-release workshop and break out a book on Agile. Ask yourself if there’s a time-sucking, sprit-crushing manual network configuration process that’s a candidate for automation.

Reach out to peers in technical communities and see what’s working for them. Learn a little Perl, set up Chef, try building systems in your lab from scripts instead of the command line and you’ll likely discover why DevOps techniques are an inevitable answer to increasingly complex IT that’s expected to deliver networks and systems quickly and reliably.