An Introduction to DevOps

What is DevOps

You can ask 10 people for a definition of DevOps and likely get 10 different answers.

If you want to find a definition of your own, your research will probably begin by asking Google, “what is DevOps”. Naturally, Wikipedia is one of the first result so that is where we will begin. The first sentence on Wikipedia defines DevOps as “a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals.” Well, that’s a fairly dense definition, yet still pretty vague. I think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way.

So let’s delve into how DevOps works and can better adjoin two traditionally opposing departments.

Growing pains

When you are responsible for large distributed applications the operations complexity grows quickly.

  • How do you provision virtual machines?

  • How do you configure network devices and servers?

  • How do you deploy applications?

  • How do you collect and aggregate logs?

  • How do you monitor services?

  • How do you monitor network performance?

  • How do you monitor application performance?

  • How do you alert and remediate when there are problems?

Combining the power of developers and operations

The focus on the developer/operations collaboration enables a new approach to managing the complexity of real world operations. I believe the operations complexity breaks down into a few main categories: infrastructure automation, configuration management, deployment automation, log management, performance management, and monitoring. Below are some tools I have used to help solve these tasks.

Infrastructure Automation

You no longer have to build a server from scratch, buy power and connectivity in a data center, and manually plug a machine into the network. After wearing the operations hat for a few years I have learned many operations tasks are mundane, manual, and often have to be done at two in the morning once something has gone wrong. DevOps is predicated on the idea that all elements of technology infrastructure can be controlled through code. With the rise of the cloud it can all be done in real-time via a web service. Infrastructure automation solves the problem of having to be physically present in a data center to provision hardware and make network changes. The benefits of using cloud services is that costs scale linearly with demand and you can provision automatically as needed without having to pay for hardware up front.

Configuration Management

Configuration management solves the problem of having to manually install and configure packages once the hardware is in place. The benefit of using configuration automation solutions is that servers are deployed exactly the same way every time. If you need to make a change across ten thousand servers you only need to make the change in one place.

There are other vendor-specific DevOps tools as well:

In the operations environments I have worked in there were always strict controls on who could access production environments, who could make changes, when changes could be made, who could physically touch hardware, and who could access what data centers. In these highly regulated and process oriented enterprises the thought of blurring the lines between development and operations seems like a non-starter. There is so much process and tradition standing in the way of using a DevOps approach that it seems nearly impossible. From an operational perspective, my first instinct is to understand the application architecture so I can start thinking about the proper deployment model for the infrastructure components. From a development perspective, my first milestone is to make sure the ops team fully understands the application and what it takes to deploy it to a pre-production environment.

DevOps isn’t just a set of tools, but a philosophical shift that needs that requires buy-in from all folks involved to truly succeed. It’s only through a high-level of collaboration that things will change for the better.

About the author  ⁄ Dustin Whittle

Dustin Whittle is a Developer Evangelist at AppDynamics where he focuses on helping organizations manage application performance. Before joining AppDynamics, Dustin was CTO at Kwarter, a consultant at SensioLabs, and developer evangelist at Yahoo!. He has experience building and leading engineering teams and working with developers and partners to scale to meet demand. When Dustin isn't working he enjoys flying, sailing, diving, golfing, and travelling around the world. Find out more at dustinwhittle.com.

3 Comments

  • Reply
    Juan
    April 2, 2014

    Why are you leaving out CFEngine as a configuration management tool?

  • Reply
    JP
    April 9, 2014

    Dustin,

    I believe you have identified some appropriate characteristics of DevOps, which is a fine way to define / describe something, but one of the most important characteristics was overlooked in your piece–quality. Ultimately, DevOps is a Total Quality Initiative for the organization. A way to reduce outages, downtime, and failures of production-based systems. Without this a guiding factor, DevOps really doesn’t produce any qualitative gains relative to the investment of time and money to implement.

  • Reply
    Tony
    July 17, 2014

    In Devops, is the deployment done to the real working customer environment? If so, does it make the customer (Operations) working difficult?

Leave a Comment

CAPTCHA Image
*