Personally, I love DevOps. I've played on both sides of the fence. More ops than dev, I'll admit.<p>The way I view DevOps is that you have end-to-end guarantees about software delivery. A lot of this draws from personal experience, so YMMV.<p>Story:<p>I was working in an organization where engineering had built a custom solution with their own database to a problem. It was using their own DB system, with the JVM, etc.. I was oncall for said service, because their DB kept getting into a poor state. My only real recourse to a page was (a) escalate to the devs (b) restart the service. I ended up furiously rewriting the service in Erlang over a weekend, and ended up getting told that my replacement was too complicated, and the previous one worked okay, because we could just restart it.<p>Take-aways: Without feeling the pressure, and side-effects from being woken up, and having to respond to on-call incidents for a service, it makes people put more value on the development time than operational time, although a service is very likely to be in operational time much longer than development time.<p>I have two other stories, but it'll take some time to write, and it's getting late, so I'll type it up only if someone is interested. Just so I remember - the tale of LD_PRELOAD and HDFS, as well as the networks and root access.<p>1. I think that ops staff should provide shared services to services organizations (hosting, deployment, etc..) when N services need the shared service (when N>2, depending on how many resources are available in your org).<p>2. I also think that ops staff should be able to "consult" on projects, as members of those teams during development. This is going to mean that those engineers are probably going to need to do some more development! Or, alternatively, the project team needs to be able to backpedal on some decisions if those ops consultants come in later on the project.<p>3. I think dev folks need to have end-to-end responsibility, including oncall, AARs, and on-call remediation. They need to take feedback from ops folks and act upon it, just as they would if product told them to do something.