Jack of All DevOps, Master of None
A few years back, a developer wrote a post about how ‘DevOps’ was killing the developer. This started a chain reaction of collective…
A few years back, a developer wrote a post about how ‘DevOps’ was killing the developer. This started a chain reaction of collective nazel-gazing about what DevOps even means.
This of course led to a number of posts about what else DevOps is killing like development and productivity and all other things within the universe. In all of the back and forth however, we seem to have lost touch with exactly what DevOps means. Here is one definition:
DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
What you do not see is a lot a technology mentioned. DevOps is not about the hottest CI/CD tools. It is not some management trick to get people to do even more work. And it is not some all encompassing, life-changing transcendental zen experience to collectively elevate your developers into the next plane of reality. Nor is it according to one Redditor “bugs, delivered continuously”.
Development is already complicated enough. The speed and complexity of code is not decreasing over time. Nor do the languages and frameworks used remain common practice for very long. For example, see how fast these technologies fell out of favor with developers.
It is for this reason that DevOps is such a hot topic. DevOps is bringing order to the chaos of deploying new stuff. As Tom Limoncelli described in a talk at DevOpsDays NYC, customers expect new features and fixes faster, businesses are pressured to deliver faster, and the cycles of innovation are getting faster.
That require organizations to get out of their own way. The core of DevOps is about deploying a set of practices that enable change to happen faster, in a more coordinated way. In part, there is a cultural shift that is happening that extends ownership for what a developer ships, bugs and all into the world of operations and production. This is sometimes referred to as “shift right”.
In practice, this shift is not simple or easy to implement. There is simply no easy way to get multiple teams all aligned under one ideal methodology or set of practices. However you can make it easy for teams to collaborate and share information faster as a first step. By making information more transparent and accessible, teams reduce mistakes, reduce repetitive questions, and allow for the wide dissemination of DevOps practices are to increase adoption.
If you are an enterprise getting started in your DevOps journey, get involved in the community. At the global level, there are conferences like the DevOps Enterprise Summit (DOES) hosted in London and Las Vegas. At the local level, there are events hosted by DevOpsDays (I am a co-organizer for the NYC chapter) as well as meetups like the NYCDEVOPS group. There are also online communities such as the DevOps Stack Exchange site. And lastly there are really smart people like Tom that contribute often to the industry and I would highly recommend you follow.
Are you doing DevOps in your company? If so, how are you implementing DevOps practices and where do you go for guidance?
How to help DevOps Engineers feel less like a lone wolf?
How to help DevOps Engineers feel less like a lone wolf?
I have just been speaking to a DevOps guy who raised some really good points about the struggles of being a DevOps…devops.stackexchange.com
Since we are on the topic and all, and yes, we have a Stack site for DevOps…
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.