DevOps is the now widely used practice of having Developers and Ops work closely to enable faster, shorter releases to production. Instead of waiting longer times and preparing elaborate, risky releases, DevOps shortens the release process while still upholding quality and system integrity.
Then what is wrong with DevOps? Why would we need something like NoOps?
There is actually nothing wrong with DevOps, save a couple of operational challenges. NoOps is not built to tackle any limit but rather forge the path to higher organisational and operational maturity. Hence, it would make sense to think that unless you have a solid DevOps practice, there should be no strategising towards NoOps.
NoOps, exactly as the name says is very much the removal of Ops from the process. There are a few rationale behind wanting this.
1) Developers who monitor production environments are likely to catch issues much quicker than Ops who would rely on the customer to report.
2) It enables even faster releases and puts the onus of quality and environment protection on the developers and the tools in place for NoOps.
3) NoOps frees up the developers in DevOps to work on features or do something else.
4) Ops is difficult to scale. When you deal with more complex features and products, getting Ops to scale is a difficult process which needs a lot of adapting to the DevOps mindset.
How does one transition from DevOps to NoOps?
This would seem quite obvious, but this is very crucial to start moving to NoOps. There must be a non-production environment (like a sandbox) which completely mirrors the production environment. No exceptions. This would ensure that the final regression and functional quality checks are going to hold good in production as well. Without this, no amount of automated testing or tooling will ensure that you won’t need ops to keep looking over their shoulders after every release.
2) Cultural shift
Getting to NoOps is no mean feat, and hence a lot of friction needs to be absorbed. There may be reports of “but this is not working”. For any such instance, diagnose – > revamp -> redeploy. The core issue (say a missed bug in production) can be caught the next time by improving the process or strengthening the net to “catch” better. Of course, a great vendor is imperative to help craft and re-craft these improvements. But the key thing is to keep plowing on. Remember, NoOps is 0 ops, not sometimes 1 or 2 ops.
3) Empower the developers
The developers will own the production environments’ issues in NoOps. It is important to keep their hassles to a minimum. This can be done using tools to analyse and report production problems. With the right tooling, the majority of issues can be preemptively reported. It does not stop there. Tools can also help take minimise impact by running some pre-configured scripts upon report of specific issues. With the right tooling and strategy, you will see a matrix of different problem scenarios and the processes and the tools that kick in for each of them.
4) Get everyone on the same page
Developers, testers, product owners, senior management- must understand and accept the NoOps implications. There will be a phase of “pain” when the NoOps practice kicks in, not to forget the apprehension. Hence, it is important to cover all concerns in separate workshops with the stakeholders. “But what about that weekly report that the Ops used to send?” “What will happen to customer requests and not bugs?” “What will happen if no developer is available?” Get all those pesky questions out (make sure your IT partner tags along for these discussions). Each questions’s answer (if needed- because we will also prioritise the concerns based on cost, impact, frequency) will help the process to become sharper for your business context.
All this sounds like a lot of work? Well it is! But the good news is that, NoOps practices are slowly taking shape in the industry. So, chances are that you would move very smoothly and none of the things that worry you would actually come true. If you don’t believe us, then why don’t you drop an email to firstname.lastname@example.org and we can discuss what your thoughts are and find the best NoOps strategy for you.