Gartner Blog Network

The state of DevOps — according to me

by Joerg Fritsch  |  August 31, 2017  |  3 Comments

I recently had an interesting discussion with a client around DevOps. The client felt that for DevOps to happen they need to remove all barriers, security checks, etc., provide full admin right on runtime and infrastructure to the developers and hope the best. Then they will really benefit from this thing.

I took the opposite position and my client seemed to be a bit . . . shellshocked. DevOps is not the mythical thing that dissolves all borders and afterwards all will work. DevOps is an animal with stringet rules that frequently depend on the underlying tool chain. The tool chain depends on how you develop software.

In this blog entry I will explain why I say that.

The term DevOps was conceived in 2009 with the aim to express that things work best if developers and administrators are not enemies. Shortly afterwards a small number of best in class enterprises demonstrated teams where they had brought developers into the position to design, develop, deploy and operate both software & infrastructure. To achieve this teams would need to be managed almost as if they were a close religious group sharing common beliefs into uptime and customer service. The basis for this to succeed was not freedom but rules that need to be followed meticulously. Rules for developing software, testing software and deploying & operating software.

At thsi time, on DevOps conferences you met people telling how the increased responsibilities led to de-layering, the removal of inconvenient stumbling blocks and enrichment of their lives. Just about the same people you met in the first Linux conferences back in 2000 where there was always a session telling people that developing software will enrich their lives to an extend that we can soon uninvent money.

The fact that the first DevOps tools were geared towards systems management and expressing systems/system changes as code only contributed to the client’s confusion.

Five years later, around the year 2014, things took a turn. Larger enterprises had recognized that a DevOps approach where they would integrate teams and manage them semi-religiously would not work for them. DevOps started to become all Dev using the CI/CD pipeline (Figure 1) and a focus on automation as the key to increase efficiency and streamlining software development and deployment. As along as automation works no one really cares any more whether they have unified teams that enrich their lives or not.

CI CD Pipeline

In essence you have two sets of automation that are linked to each other:

  • Automation along the CI/CD pipeline up to the deployment server (deployment servers could be eg Octopus for large complex software deployments or Puppet/Chef for more straight forward deployments).
  • Automation for infrastructure operation to configure infrastructure (containers, VMs, SDNs, Security, etc.) that are provided by a combination of first citizen DevOps tools and API driven infrastructure such as software defined data centers/HCIS, etc..
  • In this context IT infrastructure operations are providing an environment on that the chosen toolchain is supported and running. The SLAs are on this environment. That is the demarcation line. Decisions need to be made as to what a release is and when new software(components) are deployed. Deployment servers such as Puppet or Octopus offer a number of options for this that include traceability features such as who deployed what, were they authorized, etc..

    An exception can be (but do not need to) environments that are based on microservices. Microservice environments can use micro service routing platforms, such as that make testing and operation possible on the same production platform. The name for this is canary testing. Also here IT infrastructure operations has the role to ensure that the underlying platform and required tools are running, patched, etc..

    It is of course not all black and white and structures and processes are thinkable that are a compromise between the two positions. However, the assumption that DevOps is this mythical thing that dissolves all structures to let the magic happen is based on a misunderstanding of DevOps. Hope I helped to make this clear.

    Additional Resources

    View Free, Relevant Gartner Research

    Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

    Read Free Gartner Research

    Category: devops  it-cost-optimization  

    Tags: agile  application-developement  devops  itil  

    Joerg Fritsch
    Research Director
    1 year at Gartner
    15 years IT Industry

    Joerg Fritsch is a Research Director in the Gartner for Technical Professionals Security and Risk Management Strategies team. His specialties include information security, data center and cloud security, big data (analytics), cloud computing, PaaS, distributed systems, messaging and event-driven systems, and very fast networks and servers. Read Full Bio

    Thoughts on The state of DevOps — according to me

    1. Ruth Gibbs says:

      Well Said….Thanks for sharing

    2. Congratulations. You have grasped the “A” in CALMS. Keep going and you will understand the other 4 areas one day.

      • Joerg Fritsch says:

        CALMS, that is yet another pre-2014 acronym. The point I make is that somewhere around the year 2014 was a turning point and things have moved on. Simply speaking: since then DevOps has become all Dev. Some acronyms were not updated of course. Including the acronym DevOps itself 😉

    Comments are closed

    Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.