There is no such thing as NoOps: it is an awful word
There is no term I detest more than "NoOps". NoOps means nothing runs, which means the business comes to a halt.
"NoOps" is provocative, alienating, patronising and demeaning to those who care about Ops. There will always be a science of making it run good and safe. There will always be Ops as an activity and function and skillset. Please erase this hideous word from your vocabulary.
I suggest if you want to have actual influence in the field of large-scale web engineering, I would do this: 's/NoOps/OpsDoneMaturelyButStillOps/g'
...how you're using the words "No" and "Ops" together is almost certainly in opposition to how almost everyone I respect uses them
The term "NoOps" is tainted by people seriously proposing it means no Ops at all, which is as daft as no IT. I went right off at Mike Gaultieri from Forrester. I'm not sure how much of that rant I have changed my mind on in the intervening three years - I'm still pondering that question, but I haven't come to like the term any more.
"NoOps" is also dangerous because of its implication that we don't need to worry about ops considerations, that Ops is somehow automagic.
most leading thinkers in the DevOps space dislike the term NoOps for a number of reasons. First and foremost, it implies that operational expertise is unnecessary this new cloud/web-scale world. The term is also divisive in replacing “Dev” with “No.” However, like it or hate it, this similar and reactionary terminology implies unity.
From Gene Kim's upcoming DevOps CookBook*:
Here are some DevOps myths: ...
"DevOps means NoOps":
DevOps is sometimes incorrectly interpreted to be NoOps (i.e., IT Operations is entirely eliminated). However, more precisely, DevOps will often put more responsibility on Development to do code deployments and maintaining service levels, this merely means that Development is taking over many of the IT Operations and operations engineering functions.
In order to support fast lead times and enable developer productivity, DevOps does require many IT Operations tasks to become self-service. In other words, instead of Development opening up a work ticket and waiting for IT Operations to complete the work, many of these activities will be automated so that developers can do it themselves (e.g., get a production-like Dev environment, add a feature metric for production telemetry, etc.).
Ops are as essential as ever, to:
- Set policy for Production
- Embed that policy in automation and testing
- Become a toolmaker for Development, to give them the self-service Gene talks about
- Monitor the overall Production environment
- Own and run the physical infrastructure (servers, racks, storage, networks, facilities etc) or their suppliers.
- Clean up the litter of virtual environments that I bet Dev teams will leave lying about
- Pick up custodianship of the application when the business loses interest in funding any more improvements and the Dev team/project is consequently disbanded
- ...oh, and risk, change control and scheduling, operational readiness and acceptance, IT infrastructure, availability, capacity, access security, threat security, problem management, all the support disciplines, service level management...
What do IT Ops do? We manage IT risk on behalf of the business. Thinking Ops is about servers is like thinking Dev is about code cutting.
Successful Agile development involves close collaboration between Dev and Ops to provide Dev with the flexibility they need in dev, test and prod environments, whilst still protecting the organisation's interests through ring-fencing the change to prevent anything else getting broken, managing the risks, defending security, ensuring integrity and so on.
Businesses didn't build this immense IT Operations infrastructure for no reason. And contrary to some opinion, the reasons are still there. You'd think we would be grown up enough to get past this "but the rules are all different now" bovine excrement. IT Ops is about managing IT risk on behalf of the business, and most Dev folk wouldn't recognise operational risk if it licked them.
My understanding of the vision of the ideal DevOps world is that Ops toolmakers build infrastructure ("on prem" or cloudy) and build the automation tools to allow Dev to create (and destroy) environments on that infrastructure using infrastructure-as-code instructions to the automation tools. (In reality, there will still be Ops human involvement in Production deployments, at a minimum to approve scheduling of the change). Ops own the infrastructure and enforce organisational policies on the environments: they monitor what's happening and they embed policy in the automation tools to protect the business from operational risks. So Dev don't have to go cap-in-hand to Ops to get stuff built, but Ops is still there and still in charge and still very important for the protection of the organisation.
So enough with the "NoOps" B.S. ok?
* To subscribe to updates about the DevOps CookBook release and receive an advance draft of the manuscript, sign up here.