DevOps Ventured, NoOps Gained: The Natural Progression of Automation Through Collaboration

Coined by Forrester in 2011, the NoOps proposition sees the IT environment "become so automated and abstracted from the underlying infrastructure" that an in-house operations team is no longer needed to service it. It’s a bold pursuit, but one that allows organizations to greatly increase productivity by cutting wastage in the software delivery pipeline. Just as DevOps helps in the move toward automation of the IT environment, NoOps is the arrival at total automation.

All DevOps Roads Lead To NoOps

DevOps has matured as a discipline due to pressure from opposing teams involved in software delivery. Developers want increased speed and throughput, while operations value stability. To achieve both goals, a mindset and culture has evolved bringing about automation tools, typically open source, and practices that can be applied to the software development methodology.

The DevOps mindset centers on learning and improvement through collaboration, breaking down the traditional silos in which development and operations teams reside. Had the effectiveness of a more traditional approach never been questioned, these teams would have remained in an inefficient cycle of handoffs. But the natural impulse to improve productivity has led to a more iterative way.

Automation tools have helped developers achieve greater throughput by improving the efficiency of operations processes. If these processes can be entirely automated, i.e. NoOps, higher levels of productivity can be achieved.

The Evolution of NoOps

There are multiple factors that have contributed to the rise of NoOps. Intelligent IT automation, cloud computing, and proactive monitoring are all important factors. It is also important to note the recent emergence of AIOps, where IT operations are enhanced by using analytics and machine learning to analyze data collected from various IT operations tools in order to automatically identify and react to issues in real time.

Cloud platforms such as AWS, Google, and Azure have empowered users with control over operations traditionally looked after by another team. By providing Infrastructure-as-a-Service (IaaS), on which developers can build and run applications, a major part of operations has become transparent.

Automated monitoring and logging strategies allow for pro-active alerting when your application begins to experience performance degradation. This allows an issue to be solved before it impacts the end consumer and removes another layer of separation between development and operations teams. The benefit of automated monitoring can be measured using stability metrics such as Mean Time to Repair (MTTR) and Change Failure Rate.

Taking advantage of the large amounts of data being collected from the IT Operations tools driving increased efficiency; observational data found in monitoring tools and engagement data found in incident and ticket management systems can be aggregated into a Big Data platform. Analytics and machine learning can be applied to provide insights that yield compounding improvements.

In tandem, the DevOps movement has driven the automation of release engineering, shifting practices typically executed infrequently at the end of a release cycle left, closer to code commits. It is important to note it remains the responsibility of an organization to make this investment.

Building upon the learnings of various DevOps journeys, the likes of Heroku, Cloud Foundry and Open Stack have established Platforms-as-a-Service (PaaS) offerings providing NoOps experiences via self-service. This allows developers to sign up and get coding and delivering straight away, with minimal to no reliance on an external operations team. Open source self-service tools such as Rancher and Rundeck have also emerged to help drive NoOps adoption in the community. Finally, cloud computing platforms that started with IaaS have ventured into PaaS to offer NoOps experiences of their own.

Consistency is King

Self-service of the IT environment increases productivity, but PaaS platforms offering NoOps experiences have their restrictions. Developers using PaaS platforms usually need to adhere to architectural constraints and development guidelines, such as the Twelve-Factor App methodology.

Developers value freedom but do not want to think too deeply about environment management, release processes, or worry about regulation and compliance criteria. With PaaS, processes that fulfill these criteria are baked into the platform and configured by operations teams as standard operating procedures for utilization at scale. There is an inevitable trade-off around flexibility, but organizations are realizing that the more repeatable the software delivery approach, the more they will gain in productivity.

It is also worth noticing PaaS platforms focus on the development of applications that conform to modern architectural patterns. As a result, these platforms are not always a natural fit for legacy applications. If these applications are critical, there is a risk of trying to squeeze applications designed with legacy patterns onto platforms that impose incompatible restrictions. In the worst case, a rewrite of the legacy application is required.

In such circumstances where a PaaS platform isn’t a good fit, falling back on a DevOps culture and mindset is the best approach. DevOps is a mature discipline with tools and practices available for an array of technologies. Making the most of such tools in conjunction with bringing the development and operations of the legacy application together with the aim of identifying wastage in the delivery pipeline can yield great results. Legacy applications can be delivered with both stability and throughput with the application of the right mindset.

NoOps Doesn’t Mean No Ops

A perceived threat posed by NoOps is that it makes an operations team redundant. But this is not the case.

Adopting a PaaS platform may mean Ops are no longer responsible for racking and stacking servers, but these platforms are not a one-click deployment. They need administering so that they are set up in alignment with an organization’s standard operating procedures.

An organization that operates with a DevOps mindset will be prepared for this transfer of skills. Operations teams within these organizations will have adopted a more developer-centric view of delivering software and will understand the need for increased automation as well as knowledge around the tools that make it possible. As administrators of the platform, Ops teams are empowered to improve an organization’s productivity at scale.

So, while many organizations may not be ready to bring in total automation, the learning and development provided by the DevOps methodology, along with the tools and processes that drive automation, can bring about the cultural buy-in that will ease the journey to NoOps. In essence, DevOps is the vehicle, NoOps is the destination.

This blog previously appeared on DZone.