[clavalle]

>You can’t have DevOps and still have separate operations and development teams. Period.

I cannot disagree more. You can't have developers of your product knee deep in DevOps and be effective (at a certain size, smaller teams with less demanding operations needs can).

DevOps should have very clear demarcation of responsibility in an organization. What the OP describes is an blending of responsibilities and that is the root of his problems.

DevOps /is/ operations. It is just that simple. It is design and automation of support systems. Nothing more, nothing less.

[efuquen]

If 'DevOps' is operations, that what is the point of the term? Ops teams have been doing automation of support systems for a while, so what exactly does it mean to be DevOps? I think that's part of what the OP is getting at, if your fancy 'DevOps' team just ends up being separated and isolated from the dev team you're back at square one, you've accomplished nothing and the same divide exists with a new label.

As someone who works on the dev side, the ops side, and the mixture of the two I feel the OPs pain acutely and have had mixed experiences. People on the dev side need to understand and willing to learn about ops, it's not rocket science and you don't have to be knee deep in it to get the basics down. When ops becomes this black box and becomes a bottleneck is when you start to see dysfunction.

[clavalle]

>If 'DevOps' is operations, that what is the point of the term?

It is taking more of a gestalt systems approach to the entire support structure. This means more intelligent support programs and treating it like designing and delivering a software project (or, more accurately a series of subprojects) as opposed to a loose amalgam of scripts.

This also requires the product development team to be keenly aware of that support architecture and how their decisions factor into it especially in terms of testing, deployment, and module interactivity.

> Ops teams have been doing automation of support systems for a while, so what exactly does it mean to be DevOps?

DevOps has been around for a while -- way before there was a word for it. I think DevOps has come into its own, recently, though because platforms have become hugely more flexible while at the same time a consensus built on what it means to manage those systems. The difference, I think, is whether things are built to remain somewhat static or if change is designed for. Are development ideas like encapsulation and decoupling etc designed into the system? Smart sysadmins have been doing this stuff for a long time but now organizations are taking the approach into account all the way up and down the chain. And, yes, that means that product developers need to be fully aware of operational needs but, in my opinion, I don't think that means they build the operational tools themselves.

>your fancy 'DevOps' team just ends up being separated and isolated from the dev team you're back at square one

Demarcation of responsibility doesn't mean demarcation of information. The product development team will need to be intimately aware of what is happening in operations and vice versa. In a DevOps implementing environment it is unavoidable.

> the dev side need to understand and willing to learn about ops, it's not rocket science

These days it's getting pretty close. I don't think it is fair to product developers to say "Listen, we like the idea of what Docker can do for us so you are going to learn it inside and out." Somewhere you have to say "Hey, we probably want to implement Docker. Ops, dig in. You know how our product is currently structured and how operations currently works with that. Try to figure out what needs to change and what doesn't. X and Y from the dev team will be made available for deeper discussions and testing as needed. When the overall gist of what has to change is known, we'll all get together, ops and produce dev, to get everyone on the same page." It's a bleeding of information, not a full on 'shake it all up' scenario.

Neither side can be a black box anymore if the current state of software development and delivery is going to be taken advantage of. But neither can everyone know and do everything or context switch as needed.

Keep in mind: I am not a DevOps theorist -- maybe I have it completely wrong according to the people that came up with it but this is my practical understanding of the movement.

[wtbob]

> DevOps /is/ operations. It is just that simple. It is design and automation of support systems. Nothing more, nothing less.

I disagree; although there's a huge value to consciously automating and designing support/deployment systems, there's even more value to developing products to be deployed ab initio.

You need automated production systems, and you also need developers who understand how their code is deployed and run. Really, you need smart, productive people, not interchangeable Java monkeys.

[dragonwriter]

> DevOps /is/ operations. It is just that simple. It is design and automation of support systems. Nothing more, nothing less.

Design and automation of any systems is "development". It is just that simple. Nothing more, nothing less.

So, from your description "DevOps" is really development whose application domain is operations.

(Though I'm not sure I agree with your description -- I think that's part of DevOps but that DevOps is somewhat broader; in the same way that many approaches that fall under the general agile/lean umbrella have pushed erasing role-based team boundaries and, even within the lower level teams, role distinctions within the broader development realm -- e.g., between programmers, analysts, testers, etc. -- DevOps is about erasing, or at least blurring somewhat, the team and role boundaries between development and operations; this doesn't mean that people don't have distinct competencies, but it means that people with those competencies work together at lower organizational levels and in a more tightly integrated way focused on overall mission, rather than throwing things over the wall at each other.)

[amouat]

Well, no. DevOps is (or should be) as the OP describes it. Just because you disagree with the concept doesn't make the definition wrong.

[late2part]

I mostly but not completely agree with your opinion. But, put it into context, there are more than one "right" definition of devops, just like there's more than one "right" definition of "Cloud" or "Cloud Computing."

I think the author's story is more an admonition of blind foolishness and deceit than it is an indictment of the automation.

[dreamfactory2]

hmm I've worked with some of the people who invented the term and this is a bit off. devops is bringing dev practises into ops as you describe - e.g. replacing ad-hoc bespoke shell scripts with more standardised automation frameworks leading to full infrastructure-as-code phoenix-pattern deployments. It is also breaking the dev and ops wall in the same way that agile is intended to break the bus/dev wall. An example of this would be continuous deployment and automated testing (e.g. the kind of things that IMVU did with automated performance testing on commit to live with rollback if problems started to appear as changes cascaded through the infrastructure). and like agile it is meant to describe a mindset rather than a role or department. and also like agile, it is horribly bent out of shape by most orgs and comes to mean different things to many people...