As we get more calls about networking in a “cloud-ish” environment, particularly around SDN and programmable networking, the concept of staffing and DevOps is creeping into more discussions. Not surprisingly, all major networking vendors now have an SDN story and Puppet/Chef support is quickly becoming common-fare on data center switches.
Most networking leaders have heard of DevOps,but have only a very basic feel for what it is. Thus, a deeper understanding is often required. Further, DevOps is often positioned as the panacea to all staffing ills in building a cloud environment, as Ronni Colville sums it up nicely: DevOps seems to be the new shiny object with the promise of “automagically” improving the longstanding divide between development and operations… (Source: Seven Steps to Start Your DevOps Initiative, http://www.gartner.com/document/2847717).
Prior to Gartner, I spent 15+ years as a networking/security engineer/architect in mostly ITIL-based organizations. Upon first hearing about DevOps, I had many questions and some initial skepticism, such as…
- It sounds cute, but what the heck does “infrastructure as code” really mean?
- How is DevOps different from a “SWOT” team responding to an important application rollout or P1 application issue?
- How is DevOps different from how midmarket organizations handle IT (i.e., everyone pitching in and wearing multiple hats).
- Aren’t we supposed to embed security into everything – so wouldn’t DevOpsSec be a better term?
So first the Why and then the What…
Why Do I need it?
This is summed up best in a September 2012 research note: Businesses need to innovate faster to meet the needs of the market, and are increasingly concerned when their IT organizations can’t meet their needs….With the best interests of the customer in mind, development seeks to enable the business and, as a result, often needs to move rapidly. In diametric opposition, IT operations is typically risk-averse because its mission is to protect the sanctity of the production environment, and the controls it implements to do so tend to slow down the transition of new or changed IT services (Source: Leverage DevOps by Starting With Organizational Change, http://www.gartner.com/document/code/236104).
OK, Now What is it ?
DevOps is a philosophy about collaborative culture, in which we treat “Infrastructure as Code”. It is not a specific technology, or even a staffing model. Since the phrase “Infrastructure as Code” can be ethereal, I like to think of it as this: Treat Infrastructure (network, servers, SAN, etc) similar to the way we handle application development (i.e., code). Culturally, this requires that we stop thinking of App Development and Operations as separate silos (or hosting function/software function). Cameron Haight described it way back in 2011: DevOps is an evolution in thinking with regard to how IT services are delivered and supported… which also attempts to bridge the traditional organizational process divide between development and operations teams (Source: Deconstructing DevOps, http://www.gartner.com/document/code/211649). And oh yeah; automate wherever possible. Anytime you find yourself doing the same thing more than twice, it should be automated.
Read Complimentary Relevant Research
100 Data and Analytics Predictions Through 2021
Over the next few years, data and analytics programs will become even more mission-critical throughout the business and across industries....
View Relevant Webinars
Data Center Modernization and Infrastructure Agility Trends
IT infrastructure professionals must plan for business transformation by leveraging modern data center technologies such as flash-based...
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.