Rightscale just published a report called “State of the Cloud Report: DevOps Trends“. The report focuses on the adoption of DevOps and containers across both enterprises and SMBs. To nobody’s surprise, adoption rates of both containers and DevOps are on the rise. What is interesting is the rate of adoption, especially in large enterprises. Here are a few charts that got my interest.
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.