What is the difference between devops and ops for developers?

The definition of devops is poor, and its meaning varies depending on who you ask. It has been misused as a buzzword by training consultants and as a marketing gimmick to sell more units by SaaS platforms.

Devops

The definition of devops is poor, and its meaning varies depending on who you ask. It has been misused as a buzzword by training consultants and as a marketing gimmick to sell more units by SaaS platforms.

Devops is a work culture, and as with all cultures it is difficult to get everyone to sign off on the same definition. It will mean something entirely different to a 100-person organization, with traditional ops, QA and development departments, than to a 5-person startup run by developers.

But in amongst the noise, there are some good, sensible, common principles. Devops is a work culture where everyone in an organization agrees to:

  • break down silos (both data & departments)
  • have empathy with their co-workers across departments, and with their customers
  • increase personal accountability, responsibility and knowledge sharing within the organization.

In my experience, a common goal of delivering value to customers in a holistic way is probably the single most important and unifying element of devops.

In many ways, the traditional ops department tries to optimize for continued, uninterrupted service for the customers, which means they typically have an adverse relationship towards changes in general. Developers on the other hand favor change as it’s the way they can deliver improvements to customers.

The point is that everyone works together on solving a common goal for the customer, and this in-turn impacts upon all decisions faced by a business. This means operations accepting that change is required to satisfy customer needs, and developers understanding that sudden major changes can disrupt the service for existing customers.

Opbeat ops illustration

Ops for developers

In the early days of the Internet, “classic ops” people ran applications on bare metal servers, and companies who were large or lucky enough would employ dedicated employees whose job it was to manage, monitor, maintain them and negotiate colocation and bandwidth deals.

But in today’s cloud world, more and more organizations are hosting in the cloud. They have outsourced classic ops to AWS, Heroku and DigitalOcean. And knowing how to configure, manage and scale web applications in the cloud is fast becoming part of the required skill set of the modern developer.

For a developer to set up a new application in the past required waiting on (or bribing) a system administrator. Today it’s as easy as writing heroku create in your Terminal.

Developers today write, test, deploy and operate their own code. In some sense, developers are the new ops people.

With the upcoming launch of our metrics service, Opbeat will have realized ops for developers. A complete ops service built from the ground up for modern development teams, not classic ops people.

We have incorporated some of the devops practices into our platform, such as breaking-down silos, because we think this is a useful and sensible thing to do. But we don’t claim to be a universal devops solution.

The first complete ops platform for developers is here

About the author
Ron Cohen is co-founder and CTO at Opbeat. A founding member of Django Copenhagen, Ron enjoys sharing his experiences with code and ops around the world.
You can follow him on Twitter or GitHub.