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.
* One-step build and deploy. I'm still waiting for you tell me how these steps will solve my problems.
Because having a fast, reliable, and reproducible mechanism to push application changes is very valuable to most businesses that develop software.
* Culture of respect & trust, good attitude toward failure. How about "culture of stop fucking up"?
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.
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.
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.
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.
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.
A typical developer just wants to code against an api, and shouldn't have to care about the infrastructure. As cloud providers (both public and private) move up the stack from providing just virtualized machines (ec2) to higher level services (dynamodb) to more complete frameworks (lambda), the developer cares less and less about what runs underneath that.
Devops does indeed sow the seeds of its own destruction. :)
