DevOps: Threat or Menace? (Video)

The title above is a joke. Mostly. We've heard so much about DevOps -- good, bad, and indifferent -- from so many people who contradict each other, that we turned to Alan Zeichick, one of the world's most experienced IT analysts, to tell us what DevOps is and isn't, how it can help get work done (and done right), how it can hinder progress, and how to make sure DevOps is a help, not a hindrance, if you or your employers decide to implement DevOps yourselves at some point.

Comments

What about the cloud?

[bsdasym]

That's what "DevOps" is to me. A meaningless buzzword. I did once see a "DevOps guy" lauded as some kind of hero for changing a haproxy configuration and reloading it.

Re: What about the cloud?

[pla]

The old guy stopped learning IT in the 1990s. The new guy understands when you want to run your app in a docker container.

And on the same subject, hey, how about that moron Harold II, for not deploying his F-14 Tomcats at the Battle of Hastings? What a maroon, eh? Right up there with Pheidippides for not just pulling out his cell phone to call Athens.

You understand, of course, that the "old guy" wrote that mess of unmaintainable scripts out of necessity? And he quite likely hasn't just let his skills atrophy, but instead, now makes even more money helping companies move away from those old messes and into something more manageable (since newbies just look at them and cry)?

Meaningless Bullshit

[segedunum]

Devops is one of those meaningless bullshit terms that seeks to create something complicated out of something simple. Basically, if you want shit to work, which is the goal here I'm guessing, you put your developers and sys admins working the same room and get them to run something that will work in production. Simple.

Devops has also been used to give them impression that system administration can be abstracted away as some kind of quasi-cloud-development thingy. That is not the case nor will it ever be so.

Re:Meaningless Bullshit

[KGIII]

Well, this is a fine place to interject my opinion - for what it's worth... I'm not an authority (obviously) but I did manage to get things done and was successful at it.

First, this is absolutely horrific - not the subject but the process of watching this video. I've never watched a /. video before - I've read transcripts. This required so much effort to allow so many things in uMatrix that it was absurd. Between Disconnect and uMatrix I wasn't sure that I'd ever see the video. There were nearly 1000 requests. Just with the new page loaded (this one with the comments) and not watching the video, Disconnect shows 1062 requests and uMatrix is now much lower at 84 requests. That's bullshit and unnecessary.

Second, this is not new. It may be that my shop was heavily oriented to processing large data sets and working with the results and doing loads of manipulations but our dev team worked very much in hand with the ops team - one could say that there were representatives of either and some cross-talk always taking place. My hiring reflected my opinions and so I almost always ensured that there were enough people available so that someone was always able to be freed up to work with the rest of the crew. They were in "teams" with specialized rolls but those lines were often fuzzy.

Finally, I'm going to have to use a lose definition of "cloud" here as it's not very well defined. To me, much of this cloud shit is nothing more than a return to dumb terminals (in some ways) and not much different than hosting your own data - from the perspective of those who work with the data. We had a locked server room and a locked comms room and whatnot. Locked doors didn't mean a whole lot as they didn't really need to be locked and people interacted with one another frequently. Doors would probably be locked if a client was in the building, for example.

So, it seems to me that if they're having issues with this then the problem is likely the process they're using or ill defined goals. He's right, the IT staff, structural IT if you will, don't need to know until after the dev team has a working model that's fairly close to feature complete. We did internal provisioning, I'm sure this is a little slower, but I imagine the process is much the same.

To my eyes this looks like Yet Another Management Problem (YAMP). It seems like piss poor managing, improper goal setting, and generally wasting time for no real efficiencies. Funny enough, if you hire good people, pay them well, and shut the hell up and listen to them so that you can give them the tools they need - they usually do a really good job at getting stuff done when you give them the freedom and space to do so. If they know what it is they're meant to be doing and you give them the tools to do it and then get out of their way then they get the job done. If they don't get the job done there's all sorts of problems but it's usually the fault of not giving them the ability to do the job you wanted - be it communication, realistic time periods, or the appropriate tools.

Also, the tools aren't what the vendor suggested. They're the ones they users requested. Strangely enough, keeping people satisfied and engaged enables them to do good work and actually have an investment in doing good work. Imagine that?

At first I tried the sort of micromanaging and the whole helping thing. This was because I'd started as just one person with a single other employee. So this was my baby. Fortunately, I was smart enough to hire people more capable than I. They were honest enough to tell me to stop helping. Given that I'm not usually an idiot, I listened. They were better at it than I was - that wasn't my area of expertise and I really had too much work to do elsewhere which is why I'd hired them in the first place.

So, to all you managers out there, take it from me... Shut the hell up and listen. Give them the tools they need and the space to do what you asked. Articulate and ensure that they know not just the process but the goals. Guide - d

Re:Meaningless Bullshit

[lgw]

Devops isn't "ops people who code", it's "fire all the ops people, and make your software devs do that ops stuff too". It works about as well as you'd imagine - lots of automation, but the lack of real ops experience (and desire to do that for a living) really shows. And yes, you'd be on call - it's not devops if someone else has to wake up if you break it. That's the whole point, really - one team that has to live with the results of their choices. It's less than ideal, but better than any approach that lets dev blow off the concerns of ops.

DevOps my understanding

[Mybrid]

Hi! Happy Tuesday

My understanding is that DevOps was coined by a manager at Etsy who recruited developers for managing IOPs and other costs in the Amazon cloud via software designed to do just that. DevOps meant someone who was saavy enough to write system level code.

Somewhere along the way this notion got morphed into being the system administrator and the developer.

DevOps:
1. Developers optimizing Amazon and other cloud environment costs by using application code specialized to manage system administration aspects of the cloud; including managing switches, spinning up VMs, etc.
2. Developers with system administration responsibilities.

The reality is that Etsy moved off of Amazon to an in-house data center and left us with a messy legacy of a term, DevOps. :-)

DevOps = ??

[rkhalloran]

DevOps is a model where developers can spin up a VM via some cloud mechanism, throw in their code and launch without having to get an SA involved. This is great for lower environments, and lets you use CI tools like Jenkins to do a build/test/refine loop, but once you get near production, presumably you don't want the code churning so much. Then you want the SAs in the loop to manage environments for stability and to tune for performance. What the suits want is an "easy-button" solution that does all the provisioning/tuning/deployments so they can drop all those knowledgeable, expensive SAs and just let the developers handle it all. This is probably suboptimal as you don't necessarily get the benefits of performance tuning and looking at the overall structure.

Bullspit

[s.petry]

DevOps is a specialization which used to be part of standard system administration. Developing custom tools to do custom tasks, in this case related to "Ops" (another specialty that used to be standard sysadmin territory). The term is a great dummy term, but really does not distinguish someone's ability to manage servers and infrastructure.

You seem to be the 'new guy' who preaches that everything should be run in a generic docker container, complaining about the 'old guy' who wants none. Meanwhile, most of the people worth their salt understand that sometimes generic works and sometimes it doesn't. If there was some magic perfect layout everyone would be using it. Instead, we have a huge array of both hardware and software being used in the market. Knowing a dictionary of buzz words does not make you good, and usually indicates just the opposite.

misplaced bastard child of perpetual revenue

[nimbius]

devops was spawned from startup culture. imho it was never intended to be something that lasted longer than a few hundred users or internal need. The needs of ops and developers, while similar in some ways, vary dramatically in others. devops is a compromise designed to foster quick, often unscaleable delivery of a service. Once larger companies caught on that you could make devs to op work, and vice versa, the trend became unstoppable. its still an insufferable title.

As an op, i dont write the kind of code that would get into a formal repo with a standup and peer review. im writing a script to automate something that either pisses me off or takes up too much of my time. I write breakfix code too, but its not designed to upgrade or mod easily and i dont share a ton of comments or documentation because im busy handling the infrastructure. piping my one-liners and quick functions through the holy trinity of git/gerrit/jenkins for review by real developers is a demoralizing pain in the ass. it also slows down fixes and deployments by subjecting talented coders to a confusing ratsnest of code that isnt meant to become a fundamental part of how a user interacts with the brand.

and making devs subservient to ops isnt something you should do either. scrum and kanban and swimlanes are boring 15-30 minute reminders that marketing drives the bus. We need to be part of the rollout process to make sure things, if they break, are handled appropriately. its nice to have validation the codes been tested as well, but all these things are an email or a quick chat and dont need to involve a manager.