* Automate configuration with Puppet or whatever. You should be doing this anyway. Not earth shattering.<p>Yes and it's very helpful to have a dedicated team of SMEs doing it. Otherwise you distract engineers who have to context switch to 'devops' mode and will, invariably, do a mediocre job. It's not earth shattering but I've yet to see an organization automate their infrastructure, configuration, and deploys without a team whose job it is to do it.<p>* One-step build and deploy. I'm still waiting for you tell me how these steps will solve my problems.<p>Because having a fast, reliable, and reproducible mechanism to push application changes is very valuable to most businesses that develop software.<p>* Culture of respect & trust, good attitude toward failure. How about "culture of stop fucking up"?<p>People fuck up. That is a constant. The challenge is building tooling and business processes that reduce or eliminate the impact of inevitable fuck ups.
My biggest issue with "DevOps" is that it seems like it should fundamentally be a profession/methodology that rapidly renders itself into obsolescence if its creators and practitioners were actually any good at it.<p>The whole point is to provide automation, tools, and abstractions that basically make "Ops" fade into the background as a thing you never have to explicitly deal with or have its concerns leaking up to the application in obtuse ways.<p>It seems to be a thing that should be executed once and then be pretty much done until some entirely new radical kind of computer, network, and/or datacenter innovation happens that completely breaks the mold of how we need to organize machines to run software.<p>But instead of "DevOps" being this thing where you run the plumbing, test the pipes and valves, and then basically leave the whole thing alone for generations to come; save for inspection (which can be automated) and minor maintenance. "DevOps" seems to often manifest itself as a completely parallel development effort with just as many weird science projects, half-broken integrations, and high rate of change based on chasing some new shiny thing.<p>Put succinctly, my biggest issue with "DevOps" is that as a marketplace of products, services, and practitioners it seems to fundamentally misunderstand its raison d'être.
This article could make sense until you've seen a bunch of engineers attempting to figure out how to move the production instances to a VPC, and then you think, christ, dev ops would be super handy right now.