I have seen far too many definitions of the term DevOps. Everyone, including myself, has their own definition. Worse, I have seen even more interpretations of what “doing DevOps” means within enterprises. Here are a few examples of what some people think DevOps is:
- Automating infrastructure
- Building out CI/CD pipelines
- Writing Chef scripts
- Creating a new silo called DevOps
- Doing anything on AWS
All of the above-mentioned items are tasks that are common when a company embraces DevOps philosophies but by themselves are not DevOps. DevOps is much bigger than these specific tasks.
Automation and orchestration are two terms we are hearing more often, especially when discussing virtualization and cloud computing. As virtualization and cloud computing technology continues to mature, so have the automation and orchestration that are such an intricate part of the solutions presented from this technology. As such, an increasing number of products and services are built around automation and orchestration. This article focuses on the underlying technology as a prelude to discussing the different products. The information below should be of interest to anyone looking to expand their skillset to compete and excel in a technology world that is traveling full speed up into the clouds.
Steve Flanders (@smflanders) and I had a late-night Twitter conversation over the complexities inherent in cloud-native applications. My take was that we need to broaden our view and see the entire picture before we can delve into the weeds. Steve’s was that we need DevOps. I countered by saying we need better communication. In essence, we may have been saying the same thing, but we were on different planets, which led to a useful analogy. During the race to the moon, who were the systems engineers, the ones who saw the big picture of a program with well over 15 million moving parts, not to say people, involved?
In my first article of this series on Support in the 21st Century, I laid out my thoughts about the baseline expectations for the corporate support model and structure established at most companies. This is where I first brought up technology silos and presented the correlation between the number of technology silos and the size of the infrastructure.
I wrote a couple of articles many years back about building an agile and flexible enterprise using a set of models, principles, and design rules that address the need to maximize financial return, improve performance, minimize risk, and enhance business agility. I want to revisit the premise of that article and view it through the lens of DevOps.
There is a huge disconnect between the DevOps world and most current enterprise IT organizations. One element in the gap is that developers do not want to know about infrastructure. Another is that the operations team does not trust developers to make changes to the production infrastructure. Developers want to focus on their application and the value it delivers to the organization. Developers want to know the characteristics of the infrastructure but do not want to build it or operate it. As a result, DevOps does not mean the end of the operations team. In fact, I see the reverse as being essential. The operations team is absolutely critical to the success of DevOps methodologies. The developers must be able to trust that the infrastructure has specific characteristics: characteristics like performance, connectivity, availability, and uniformity. To enable this trust, I believe that the operations teams are going to need to become more like developers. I call this OpsDev.