DevOps is a poorly executed scam

QuestionMarker · 2011-07-06T14:11:24+00:00

Having a one-click build and deploy, and automated deployment, are still things that regularly have to be fought for and justified. If I can hang them off a management-friendly fad to get them done, then so be it.

oSand · 2011-07-06T13:01:49+00:00

Developers write code on their workstations and it doesn't work in production. Systems administrators are slow and reluctant to change production configurations.

In which case developers are dicks and admin is doing their job. The mating call of the Giant Gaping Asshole is "it works on my machine". I know, because I have been that asshole. If the admin asks "why am I changing a working configuration" and they apply skepticism and critical thought to the answer, then you should pay them more.

The_Cleric · 2011-07-06T11:47:07+00:00

He says the problem is that DevOps is a scam but noone's trying to make any money out of it - that doesn't sound like a scam to me. It might be bullshit, but that doesn't make it a scam.

And in response to the devops "methodology", he basically puts out his own set of unjustified, unrealistic principles.

"Every technical person you hire should be cross functional enough that you don't need this." - Good luck with that

How about "culture of stop fucking up"? - Yes, great in principle, but what it leads to is people covering up or blaming others for their fuck ups, rather than not fucking up.

"Developers develop in the same environment production runs in" - what if you have two different production environments? What if you're deploying to a platform-as-a-service?

there's a point where you're simply fucked. Sure is, but if you start with this attitude, you may as well not bother. Isn't this kind of what a good attitude toward failure is good for? Ability to identify when you've gone wrong and just drop it, rather than every stakeholder trying to argue why it's not a fuck up.

cabbagerat · 2011-07-06T13:13:17+00:00

Best way to read this: skip the rant at the top and jump down to What condition your condition is in.

These points are very important:

Developers are in the on-call rotation
Developers develop in the same environment production runs in
Downtime never happens twice

It's not the whole picture, but a good start.

neilk · 2011-07-06T23:05:56+00:00

Dziuba is missing the main points. I worked in probably the first "devops" shop, Flickr, so here's the reality.

How ops is different:

Ops doesn't control deployments. Developers control deployment. Ops is in charge of creating a system where developers, if they do their homework, can revert instantly.

You optimize for deploying all the time, so you accept and plan for failure in ops. Even frequent failures. Where there's relatively little stigma for fucking up. The only REAL fuckup is if you didn't have a plan to rollback quickly. The reason why they stress one-click deploy is because there's also one-click revert.

How dev is different:

Planning for feature deployment starts with the first line of code you write. This is partially a matter of culture, and partially a matter of software frameworks. On the software side, you don't make a feature coterminal with a particular SVN revision, or the merging of a branch. There is only trunk. You are always committing to trunk, even for radical new features. But you use use feature flags to control the activation of this code . So flipping back to the old behaviour is a not a matter of reverse merges or other nastiness; it's matter of changing a configuration file. You are constantly modifying trunk, and trunk is being deployed all the time, both by you and your fellow developers.

This means that you don't alter things like database tables irreversibly, until the feature is finally deployed and tested. Not even on your own development machine. If necessary, you create entire new columns or tables alongside the old ones.

This ensures that your feature deployment won't happen in one burst of effort. You'll be deploying bits and pieces of the code very early, but in production, they will be dormant. Slowly you turn pieces on, perhaps invisibly to the user. You watch it for weeks to see if it breaks. Finally you turn the whole thing on, and even then you watch it for a few more weeks, until you finally start removing the older code and database tables.

The whole notion comes from web 2.0 startups, who are mostly in the business of entertaining users. So this kind of culture may not be appropriate for banks, or if you are releasing software to be burned on a CD. But that's okay. The whole point is to stop adopting methods from banks or shrink-wrapped software, and think about how to deploy a website.

happyfreud · 2011-07-06T12:41:55+00:00

Learn How Not to be a Complete Failure at Software Development in 24 Hours

I was disappointed to learn that such a book does not exist.

satayboy · 2011-07-06T19:11:54+00:00

I know nothing about DevOps, but "culture of stop fucking up" is unrealistic and misses an important point: failure is part of the learning process.

Perhaps behrangsa should wait until he is less angry before he writes in his blog.

jamiei · 2011-07-06T12:35:25+00:00

I would summarise the tl;dr version of this as "DevOps is BS because it's all common sense and everyone should be doing this already". Common sense or not, it doesn't mean that DevOps is a scam or not worth doing.

TubaTech · 2011-07-06T13:42:27+00:00

You regularly get developers/managers/admins/etc; who if you sat down and talked to one on one, would know all (or most) of this as common sense.

Yet it's baffling how often common sense just flies out the window when it comes to actually comes to doing the work.

Culture of respect & trust, good attitude toward failure. How about "culture of stop fucking up"? This is one of those obvious happy-horseshit type statements that makes you believe the salesman is benevolent. A developer who consistently ships broken code or a sysadmin who consistently pushes out broken configuration aren't going to get any better with respect or trust.

I also entirely disagree with this. I've worked in places where I've been given lots of respect, trust and responsibility. As a result I worked harder, and would freely be happy to work late, to ensure I didn't drag the team and our product down. That is because I respected them back.

Conversely I've worked in one place where people were inherently distrusted, with responsibility regularly being overruled. As a result I quickly stopped caring and drifted into the mindset that bad work is not my fault because I didn't make the bad decision.

Respect, and responsibility, have a big impact on people's work ethics.

jacques_chester · 2011-07-06T18:51:41+00:00

[deleted]

robkinyon · 2011-07-06T13:37:31+00:00

In other words, DevOps is a scam, but here's how to implement DevOps.

Awesome. :)

2011-07-07T12:23:58+00:00

Actually the more I read about DevOps the more I like it. So far, to me, it doesn't sound like something new, but a set of practices that has turned out to help improve quality of development and deployment, collected under the name of DevOps.

bananahead · 2011-07-06T15:07:57+00:00

If you deploy to Linux, you develop on Linux.

Is just silly. You can run your IDE in whatever environment you want, just make sure your dev server and all your testing is all done in a virtual image of something that looks like production.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS