Is NoOps the End of DevOps? Think Again [Infographic]

April 11 2017
 

Despite the cries of DevOps demise, NoOps is not the end of DevOps. In fact, NoOps is only the beginning of the innovations we can achieve together with DevOps.


Automation, a key pillar of the DevOps movement, frees IT operations to focus on higher-level work and collaborate with cross-functional teams. But what if your automation is so good that developers don’t need you anymore?

Mike Gualtieri of Forrester Research coined the term NoOps in his controversial blog post “I don’t want DevOps. I want NoOps.” In the post, Gualtieri says, “NoOps means that application developers will never have to speak with an operations professional again.”

During his time as a Cloud Architect at Netflix, Adrian Cockcroft expanded on the definition of NoOps in his blog post “Ops, DevOps, and PaaS (NoOps) at Netflix.” “There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent actually doing ops tasks than developers would spend explaining what needed to be done to someone else,” Cockcroft says. In short, NoOps means automation of deployment, monitoring, and management of applications.

Five years later, the debate surrounding the NoOps movement continues. If you’re a DevOps professional, this may scare you. Is your job still relevant? Does business still need you? Don’t worry.

DevOps isn’t dying. It is evolving.

Before we look to the future, let’s take a look at the origins of DevOps to give us a better foundation for debate.

A brief history of IT Operations, DevOps, and NoOps

In traditional IT organizations, developers and system administrators have opposing goals. Developers’ primary focus is to build features, while operations’ focus is to ensure the availability, reliability, performance, and security of the features in production. The Wall of Confusion, an iconic image in DevOps folklore, illustrates the barrier between development and operations, which leads to an unending series of outages, fire fighting, blame shifting, internal tension, customer frustration, and business failure.

In the late 1980s, IT Infrastructure Library (ITIL)—a set of standards and best practices shared by the highest performing IT organizations—emerged. While practicing ITIL promised high change success rates and prevented typical disasters associated with software deployment, it did so at the expense of speed. With a reliance on manual controls and bureaucratic procedures, implementing successful changes meant slowing down workflow.

Meanwhile, the software development community was busy forming their own best practices for the rapid development of applications. In 2001, a summit of prominent software craftsmen drafted the Agile Manifesto, kickstarting the agile development movement into full gear. The agile principles empowered small, cross-functional teams to build high-quality software faster than ever before.

The rise of the internet during the 1990s was the catalyst that fueled the demand for better, faster, more sophisticated software. In addition to the process advancements, many technologies advancements, such as version control, continuous integration, configuration management, and virtualization, gained traction during this period.

In 2006, the need for better processes and tools reached a critical mass with the public launch of Amazon Web Services. With the advent of cloud computing, software teams could now outsource their physical infrastructure entirely to cloud providers, and instead manage virtual infrastructure resources via APIs. This infrastructure as a service (IaaS) model allowed development teams to move faster, no longer having to wait on IT to order and provision new hardware.

One year later, platform as a service (PaaS) solutions, such as Heroku and CloudFoundry, made it possible for a single developer with no operations experience to launch a scalable web application over the weekend, because the platform automated everything from commit to deploy.

The day the earth stood still

The pivotal moment in DevOps history was the groundbreaking presentation from John Allspaw and Paul Hammond at the 2009 Velocity Conference—10+ Deploys Per Day: Dev and Ops Cooperation at Flickr. Seeing how a large company with complex software could successfully deploy a product multiple times per day was both a shock and a call to action for the IT community.

Riding the momentum of the ’09 Velocity conference, Patrick Debois organized the first Devopsdays conference in Ghent, Belgium. Devopsdays is a worldwide tour of locally organized conferences for developers, sysadmins, and other software professionals to meet and share their stories, ideas, and challenges. Some common themes discussed at Devopsdays include fostering a culture of community and collaboration, blameless post mortems, and applying agile practices and lean manufacturing principles to IT operations.

Since the first Devopsdays, the movement continues to accumulate success stories and widespread adoption including:

  • Docker
    An open-source container management platform that brought DIY PaaS solutions to the masses
  • Kubernetes
    A popular container orchestration framework
  • AWS Lambda
    The first widespread example of Serverless computing in which functions run on demand without the need for a server to run continuously

7 Reasons DevOps Is Not Dying

Now that we know the origins of DevOps, let’s return to our original question: Is NoOps the end of DevOps? Of course not!

1. DevOps is a journey

Attend any Devopsdays conference, and you will certainly hear the phrase, “DevOps is a journey, not a destination.” What you should see from our brief history of DevOps is that many of the techniques and practices were in use or being developed long before DevOps arrived on the scene. In fact, the first NoOps solutions were in use years before DevOps even had a name. And yet more than seven years later, the DevOps movement is still growing stronger.

2. DevOps adoption is growing

According to RightScale’s 2016 State of the Cloud Survey, more than 80 percent of enterprise companies and 70 percent of small businesses are in the process of adopting DevOps best practices. Companies are investing in DevOps more heavily than ever before, and as Puppet’s 2016 State of DevOps Report demonstrates, the investment is paying off. High-performing IT organizations practicing DevOps have 2,555 times faster lead times (the time it takes to go from idea to working software in production), three times lower change failure rates, 24 times faster mean time to recovery (MTTR), and 10 percent less rework than their underperforming counterparts. Needless to say, your DevOps job is likely safe for the foreseeable future.

3. NoOps is not one-size-fits-all

If businesses see those kinds of gains from DevOps, why not skip DevOps and go directly to NoOps? For starters, NoOps is limited to applications that fit into existing PaaS solutions. Many enterprises still have monolithic legacy applications that would require massive upgrades or total rewrites to work in a PaaS environment. Furthermore, new technologies that have no suitable NoOps solution will emerge. As some claim, NoOps is really the next level of DevOps, and we should use DevOps principles and techniques to build NoOps nirvana into all new products.

4. NoOps fits within the three ways of DevOps

In The DevOps Handbooks, authors Gene Kim, et al. describe the three ways, which are the principles all DevOps patterns can be derived from. The first way is Flow: the movement of features from left to right through the CI pipeline. NoOps solutions remove friction and increase the flow of valuable features through the pipeline. In other words, NoOps is successful DevOps.

Thesecond way is fast feedback from right to left as features progress through the pipeline. Because NoOps allows us to ship defects as quickly as features, automated controls are necessary at every stage of the pipeline to ensure defects are caught and remediated early. At the scale of modern software applications, even a small defect could have damaging results for a business.

The third way is continuous learning and improvement. NoOps is exemplary for focused learning and improvement over many years to achieve an ideal of frictionless software deployment. NoOps is a culmination of new tools, techniques, and ideas developed through open and continuous collaboration. To say NoOps is the end of DevOps is to say we have nothing left to learn and nothing to improve.

5. Operations happens before production

With DevOps, much of the traditional IT operations work happens before code reaches production. Every release includes monitoring, logging, and A/B testing. CI/CD pipelines automatically run unit tests, security scanners, and policy checks on every commit. Deployments are automatic. Controls, tasks, and non-functional requirements are now implemented before release instead of during the frenzy and aftermath of a critical outage. Having sysadmins, auditors, security personnel, QA testers, and even key business stakeholders involved from the beginning ensures these automated tasks and controls are in-place, correct, and effective before it’s too late.

6. DevOps is people

More important than any particular tool or technique is the culture of DevOps. You can’t practice DevOps in a vacuum and expect to succeed. DevOps began when developers and system administrators met at a conference to share ideas and experiences and work toward a common goal. Over time, the community realized it could build better software faster by including members from all areas of business, including QA, security, marketing, and finance. And the community continues to learn and evolve by sharing ideas at meetups, in online forums, on blogs, and through open source software. No matter how many advancements we make, the law of entropy will take over and erode them all if we forget the importance of DevOps culture.

7. DevOps requires continuous learning and improvement

A major pillar of DevOps is the spirit of continuous learning and improvement. When failures happen, a strong safety culture that practices blameless post mortems is vital for learning from mistakes. Rather than punish and assign blame, which destroys team morale and doesn’t solve the underlying issue, we must understand and improve the systems and processes that allowed the failure to happen in the first place.

Learning and improvement shouldn’t happen only when things go wrong. Everyone should strive to improve their daily work, and organizations should provide incentives for individuals to share their discoveries with the wider organization. With modern IT being a key driver of business success, companies must recognize that turning 10 1x developers into 10 2x developers is twice as effective, and much more realistic, than finding the elusive 10x engineer.

In conclusion, DevOps is forever

Despite the cries of DevOps demise, NoOps is not the end of DevOps. In fact, NoOps is only the beginning of the innovations we can achieve together with DevOps. The movement started long before DevOps had a name, and the core principles will live on as long as businesses require software to succeed in a fast-paced, rapidly changing technological landscape. In a few years, the name may fade away in favor of a new buzzword, but the culture and the contributions of the DevOps community will live on.

Share this Image On Your Site

Jordan Bach
Jordan Bach is a DevOps engineer and full-stack software developer in Dallas, TX. His favorite technologies include Ansible, Docker, Ruby, Rails, Redis, Vim, Go, Hubot, and Jenkins. When he is not building fantastic products, he enjoys playing guitar, hooping it up, escaping to nature, and smoking ribs low and slow.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form