cancel
Showing results for 
Search instead for 
Did you mean: 

A Fool’s Errand: Standardizing DevOps Tools

The other day, as is often the case when an engineer is deep in a troubleshooting task that requires a restart if interrupted, I got a request for advice. “Hey, if you have a second I wanted to ask a question about standardizing DevOps tools. Should my friend use Chef, Puppet, or something else to get DevOps going?” He couldn't understand task-switch loss, so I did my best impression of the wisest help desk gurus on THWACK. I took a breath, found a smile, and answered the question.

“Standardizing” the tools of DevOps is anathema to the goal of DevOps; a bad habit carried over from old-school, under-resourced IT. With waterfall-based, help desk interrupt-driven, top-down IT, there’s too often a belief that if only the organization would adopt a Magic Tool, all would be well. DevOps, and more correctly the Agile principals that beget DevOps as an outcome, is bigger than a tool, vendor, or any technology.

For an organization to successfully make DevOps work, especially to achieve its promise of breaking logjams blocking the digital transformation enterprise so desperately wants, standardizing Agile principles and methods should be the real goal. For example, if the Ops team adopts Scrum and comes to value ScrumMasters who resist corrupting urges to grow scope after sprints begin, it doesn’t matter if the team chooses Ansible, Chef, Puppet, or AWS or Azure services for automation.

If critical teams standardize on methods that result in predictable, quality outcomes, they can each choose the tools that work best for them, or change them as needed to take advantage of new features. Tools selection or replacement becomes just one more element in the product backlog, to be balanced against business goals, like everything else. It substantially reduces the tendency to paralyze the team waiting on The Penultimate Tool of the Ages, before it can even get started.

Where standardizing DevOps methods over tools really pays off is assured quality. If a team standardizes on a principle of Minimal Acceptable Monitoring, they will ensure throughout Dev, testing, deployment, and Ops that the right tools are used to quantify performance and user experience. This crucial measure of service quality then informs sprint goals, increasing quality and even efficiency over time. Even better, by adopting effective, (verses impossibly idealized), Continuous Deployment, IT can help ensure DevOps, in which often overlooked goals like security awareness are always a part of every change rather than an occasional review project.

If your aspiring pre-DevOps organization makes only one decision on a standard, make it this: everyone learns the 10 key principles of AgileNote: I’m not saying anything about Scrum, Chef, stand-up meetings, or the Kanban board that runs my house chores. I’m not talking about actual adoption, timelines, project division, team realignment, or even two-pizza teams. The point is not to be prescriptive in the early stages. Resist the IT urge to go immediately to implementation, resolution, and ticket closure.  Let.. this.. soak.. in.  Dream about how you’d build IT if you could start over without any existing technology or processes. How would you solve the macro requirement: How do I delight humans who use technology? And a final pro tip: Standardization on Agile principles is best done over several sessions as a team, offsite, with adult beverages to go with the pizza.

25 Comments
rschroeder
Level 21

Imagine developing a computer or an operating system with too many cooks in the kitchen, each using their own favorite tools--none of which are standard, and most of which aren't interchangeable, nor are they compatible with each other.  All with profit or recognition as their sole goals.  What will you get?

DOS.  Windows For Workgroups 3.1.  Flight Simulator bloating Excel.  Apple OS 1.  HP OpenView.  Nortel code around 2007.  The Edsel.  Enron.

Do you really want your business to get these kinds of reputations?

It's not rocket science.  It's hard work, innovation, trust, being trustworthy, and understanding/endorsing altruism.

tallyrich
Level 15

Everything we do in this business is double-edged. If we don't standardize then there is more to learn, more chance of mistake and replacing a team member gets that much harder. If we do standardize then we miss the mark on some of our goals and possibly cannot do some of the things we'd like to because the chosen tools don't provide all that we need. How do you decide - TCO. What's the cost of standardizing vs not. What's the costs associated with training, staffing, maintenance, etc.

And please don't just look at raw dollars - look at total value for spend (in time, money, talent, sanity, hair and satisfaction (of the team and the customers))

tallyrich
Level 15

I have this at my desk, maybe you should get one.

IMG_20170424_154213.jpg

shuckyshark
Level 13

i miss dos...

vinay.by
Level 16

Wonderful article sir

jm_sysadmin
Level 13

I can't believe I want to use a Kanban at home, or that I never thought of it.

deverts
Level 14

It's sometimes difficult to wrap your head around the paradigm shift occurring in IT these days. Standards breed stability yet, depending on the level of self-inflicted red tape that comes with it, can be extremely inefficient. The polar opposite, in my opinion, is Agile. Extremely efficient, but sometimes you sacrifice stability. Has world society truly become so polarizing, that a solid moderate approach to something is unthinkable? Approach things with a standard when it makes sense, and be Agile when it makes sense. Or "hybridize" the two and make a standard process more agile with less red tape. I guess all I'm saying is, you can be agile and still have standards....no sacrifice needed.

tinmann0715
Level 16

You mean that you don't have a Kanban board in your kitchen? *gasp*

tinmann0715
Level 16

Dumb question from a dumb infrastructure guy with 20+ years of infrastructure background. Why couldn't it have been called "OpsDev"? Why does Dev have to be first? Yea, I have an inferiority complex. So what?

gfsutherland
Level 14

Standardization works when people appreciate the fact that "we are all in this together", as these are adopted they become acceptable.................. UNTIL

A new "idea" comes along to challenge the standard. This leaves us to evaluate and re-appreciate the new.

Kind of like the tale of Sisyphus!

mtgilmore1
Level 13

Ditto on DOS.......

Image result for photo of DOS

rschroeder
Level 21

Security can be an additional bit of collateral damage that's easy to accidentally incorporate when going "agile".

Folks just don't know what constitutes a problem, and they move forward with best intentions, unaware they may be building a security breach during their daily work.

Security? What security? Four million data records are stolen or lost every day | ZDNet

rschroeder
Level 21

pastedImage_0.png

gfsutherland
Level 14

Brilliant sir!!!!

deverts
Level 14

This is exactly what I'm talking about, moderate standardizing with agility. We all love salt on our food, but the Dr says salt is bad for us...moderate your intake so you can still enjoy it without causing yourself a stoke!

ecklerwr1
Level 19

I still think devops is just a new word for doing things a little differently.  It seems in IT we need some new vernacular every few years to follow.

deverts
Level 14

Cloud (Private, Public, Hybrid, Mushroom!), Converged, Hyperconverged, ITIL, DevOps...etc. I'm so with you on this. And then we all sit around the campfire, talking about it, justifying their existence only to sit back and laugh when it falls away quietly into the abyss...only to be reborn/renamed something else. For those old enough, the .com bust in the 90s...can you now say "Cloud!"?

UGH!

D

Jfrazier
Level 18

rebranding...so that a new buzz word can be created and sold to the execs in order to drive new business....

mcam
Level 14

devops is great when devs understand ops - most of the time they have no clue about all those server/network thingys and doohickies that somehow connect our apps to users.

and as for that security nonsense, that's just there to slow them down.

All agile does is prevent the servicedesk from keeping up with app changes so "devs" are now "app support" because agile is something only devs do.

Then the devs don't use the servicedesk so customers call them direct, then they start using jira to record issues instead of the real servidedesk which skews the stats reported to customers and hides the error rates from mgmt.

It only works when the entire IT organization has shifted.

rschroeder
Level 21

Here's another one, adopted by Open Source types, that I like:

pastedImage_0.png

rschroeder
Level 21

Standardizing DevOps sounds so good, but we've likely all seen "improvements" and "newer, better technologies" cause problems.

Perhaps the problem is that people go try to reinvent the wheel when they don't understand the wheel already exists.  The problem then becomes ignorant people reinventing the wheel.

If you don't know a wheel exists, and you don't research the problem and previous solutions well, you'll waste time and probably miss some of the improvements that have happened to the wheel during its history.

But when thoughtful analysis is performed by people who already know about the wheel, they won't "re-invent" it; they'll improve it, make it more suitable for the new needs.

pastedImage_0.png

Never be that person who provides a "new" solution through ignorance of other solutions already being available.  Be someone who says "Here's how others have solved the problem, and filled the need efficiently."  Then be ready to take it one step further:  "And here's how I believe we can improve on their design!"

deverts
Level 14

DevOps?

pastedImage_0.png

rschroeder
Level 21

A classic case of someone not looking to see if the needs have been previously filled successfully.  This particular implementation might be useful if the goal were to:

  • Enhance the thorough mixing of a milk-shake held by the driver
  • Reduce the likelihood of a run-away tricycle on a hill or in a breeze
  • Decrease the potential for theft of an unattended trike
  • Increase the leg muscle development of the rider (hey, it could happen . . .)
  • Punish the driver for inappropriate behavior
  • Generate ridiculous thoughts and comments about the image
tallyrich
Level 15
mr.cheng
Level 7

Do a search for "OpsDev" here: DevOps - Wikipedia  and you'll see that you can be the one who can start this with the first page!

About the Author
I'm the Head Geek and technical marketing director at SolarWinds, (which basically means I'm an mature geek in the services of the product team). When I say geek I mean Geek, with extreme prejudice. I started writing assembly on my Apple II, got a BITNET email account in 1984, ran a BBS @ 300 baud, survived X.25, abused Token Ring, got some Netscape.com JavaScript award love in '96, and my hack flight notification service still backs aa.com. These feats of course made me quite the chick magnet for many years. Along the way in various jobs I’ve been a developer, SE, PM, PMM, and now principal evangelist. (Let us all join hands around the server.) Over 10 years at SolarWinds I’ve hatched our online live demo systems, managed the SolarWinds Certified Professional program, launched the Head Geek program, helmed SolarWinds Lab, and these days I’m focused on Cloud, DevOps and helping IT admins learn the new skills they’ll soon need not just to get ahead, but even maintain their roles. I’m always looking for new and more fiendish ways to use our products- just like our customers. And when I have a few spare minutes I fly a little, when the weather is good.