Defining the Dev and the Ops in Devops


development and operations roles not well defined

This is a guest post by Matt Watson from Stackify

So what does DevOps mean exactly? What is the Dev and what is the Ops in DevOps? The role of Operations can mean a lot of things and even different things to different people. DevOps is becoming more and more popular but a lot of people are confused on the topic of who does what. So let’s make a list of the responsibilities operations traditionally has and then figure out what developers should be doing, and which if any responsibilities should be shared.

Operations responsibilities

  • IT buying
  • Installation of server hardware and OS
  • Configuration of servers, networks, storage, etc…
  • Monitoring of servers
  • Respond to outages
  • IT security
  • Managing phone systems, network
  • Change control
  • Backup and disaster recovery planning
  • Manage active directory
  • Asset tracking

Shared Development & Operations duties

  • Software deployments
  • Application support

Some of these traditional responsibilities have changed in the last few years. Virtualization and the cloud have greatly simplified buying decisions, installation, and configuration. For example, nobody cares what kind of server we are going to buy anymore for a specific application or project. We buy great big ones, virtualize them, and just carve out what we need and change it on the fly. Cloud hosting simplifies this even more by eliminating the need to buy servers at all.

So what part of the “Ops” duties should developers be responsible for?

  • Be involved in selecting the application stack
  • Configure and deploy virtual or cloud servers (potentially)
  • Deploy their applications
  • Monitor application and system health
  • Respond to applications problems as they arise.

Developers who take ownership of these responsibilities can ultimately deploy and support their applications more rapidly. DevOps processes and tools eliminate the walls between the teams and enables more agility for the business. This philosophy can enable the developers to potentially be responsible for the enter application stack from OS level and up in more a self service mode.

So what does the operations team do then?

  • Manage the hardware infrastructure
  • Configure and monitor networking
  • Enforce policies around backup, DR, security, compliance, change control, etc
  • Assist in monitoring the systems
  • Manage active directory
  • Asset tracking
  • Other non production application related tasks

Depending on the company size the workload of these tasks will vary greatly. In large enterprise companies these operations tasks become complex enough to require specialization and dedicated personnel for these responsibilities. For small to midsize companies the IT manager and 1-2 system administrators can typically handle these tasks.

DevOps is evolving into letting the operations team focus on the infrastructure and IT policies while empowering the developers to exercise tremendous ownership from the OS level and up. With a solid infrastructure developers can own the application stack, build it, deploy it, and cover much if not all of its support. This enables development teams to be more self-service and independent of a busy centralized operations team. DevOps enables more agility, better efficiency, and ultimately a higher level of service to their customers.

mat

About the author: Matt Watson is the Founder & CEO of Stackify. He has a lot of experience managing high growth and complex technology projects. He is focused on changing the way developers support their production applications with DevOps.

About these ads

2 Comments to “Defining the Dev and the Ops in Devops”

  1. Hi Matt, I enjoy your blog.

    I found your perspective here useful and a good attempt to break down the two terms. In my management of ops/infrastructure teams, which were positioned in the roles of supporting R&D and production to make sane architectural decisions for the network and operating environment, the gap I routinely come across is discipline with QA and release. Enabling developers to release directly to production accelerates deployment but without discipline bypasses “independent and impartial review” (QA), may induce security problems or compromise application stability. A release and roll-back process should be documented over time. As the team grows, these checks and balances will become increasingly useful, so processes like pair programming, peer review or delegating release authority to a release group (often the QA department) add to quality. This can be done successfully without much of a delay. In the split you describe, QA would be tied mostly with R&D and interact collaboratively on a daily basis to test code and turn around bugs quickly. A larger gap I’ve found in my career is between infrastructure/operations and QA. There is a gross lacking of experience in the quality assurance process as applied to infrastructure development, but as you say the lines are blurring. More system administrators are involved in the product development process and must become familiar with the basics.

    Cheers

  2. Having a shared responsibility of developers supporting their applications depends on the business and if your business is monitored by internal auditors who demand a separation of duties. While this sounds like a great solution of developers supporting the application, this also can be counter-productive. Take for instance a data investigation, or performance tuning, problem resolution….. Just naming these three examples decreases the time allocated for true development activitiy.

    Aside from that, auditors, especially where data is security is scrutinized will come down hard on you knowing that your developers are also deploying applications.

    Having a development organization that hands off to a production support organization is a good model for large shops.

    With respect to QA, QA can only perform a true “hands off” validation if their QA environment is identical to production. Otherwise you can only build the best case studies with as much sample data as possible and hope for a favorable outcome.

    I also agree with Derek’s comment regarding roll back, but I want to point out that rolling back an application is not merely re-deployment of your application, there also has to be a tie back to your version control system to alert everyone that a roll back of code has taken place otherwise, the potential of using bad code exist.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 151 other followers

%d bloggers like this: