ArchMen - Fotolia
Where does NoOps fit in the future of IT Ops?
NoOps might stand for No Operations, but the goal is to improve processes, not eliminate them. Learn how steps toward automation and cloud migration can change IT operations.
DevOps. DevSecOps. And now NoOps. They're all methodologies with a common goal to improve the overall experience in IT teams.
Trying to optimize work processes within a framework is a worthwhile investment, but not all practices work for all IT teams. So where does NoOps fit in? And does it even make sense?
As a DevOps practitioner on the operations side, I'm unlikely to agree that a company can survive without operations staff. However, despite the literal meaning of No Operations, the term was invented as a goal to strive for, rather than an achievable ecosystem. In NoOps, you seek to lessen operations requirements via automation.
This nuance of the NoOps term is akin to the actual meaning of serverless: Servers are still involved, they just belong to someone else. NoOps is partially about making operations tasks someone else's problem.
Any decent operations team should already be aiming for NoOps' two key goals: automation and cloud migration. Not all things can or should be automated, though, nor should an organization's entire IT ecosystem move to the cloud. But devoting resources and money to repeatable tasks doesn't help anyone.
Consider Netflix's Chaos Monkey application, which pushes engineers to improve their systems' resiliency to failures, which in turn decreases work for the operations team. This type of resiliency and efficiency is what IT teams aim to achieve with NoOps: Make choices and implement systems that don't require someone to manually check if things are running as expected.
Automation
Developers and engineers should design self-healing systems and a clear alert system for when that self-healing happens or fails. A self-healing issue must fix the underlying root cause -- such as a crashed service restarting -- but the effect on operations should be minimal to none.
If an engineer discovers a problem with a piece of software after deployment to production, they can write a PowerShell or Bash script to monitor for an executable's failure. The script can trigger various commands to reinitiate and run, along with an alert to advise engineers of this particular issue, should it reoccur.
What happens to IT operations in NoOps?
The question is where operations fits in this process. Should staff follow up on fixes to ensure they are resolved appropriately? And when self-healing fails, should IT operations staff receive notification to manage the fallout? It's hard to imagine a company that promises 100% uptime -- if you can even find one that does -- that won't need some degree of operations involvement.
IT operations typically handles certain processes, such as user management and the help desk. User management -- new users, moves and departures -- should be automated. But there is always a necessary human element to onboarding, which scripts cannot handle alone.
The help desk, of course, is the most commonly experienced part of an operations team's duties. A service department could be broken off from the IT operations department, but the two pair so strongly that it would be to the detriment of help desk management to not think of everything they do as operational.
Cloud's role in NoOps
Many companies have taken a cloud-first approach to their new implementations and upgrades. As-a-service tools reduce a company's operations requirements drastically across many layers of the software stack -- provided the vendor is doing a good job. In these scenarios, IT operations teams' tasks sometimes have nothing to do with actual engineering or development work.
Companies are rarely completely happy and trusting with every vendor they use, and those relationships can and do change over time. A vendor might have performed well five years ago, but that doesn't help if it had three outages this quarter.
IT operations teams are often responsible for vendor management and liaising with other companies. They understand how the business as a whole works because they engage in regular communication with users and business-side leadership through the help desk and other avenues.
IT operations can use those skills and experiences to get the most out of a cloud-based managed tool, even though they don't have to worry about the underlying technologies or things like CPU, disk space, disk I/O and available memory.
What is the future of NoOps?
Like the other aspects of NoOps, cloud migrations might reduce operations requirements. But it's probably because other areas of IT aren't built with the NoOps goal: Hardware failures still aren't considered a developer's responsibility; engineers aren't usually responsible for programming errors.
This all begs the question: Is NoOps designed to get the rest of the IT department to do things in the interest of IT operations, rather than leaving it as a problem for operations to resolve? And if so, shouldn't we have been doing that all along?
