What is DevOps? What is it that is so difficult for people to grasp?
First of all, I think we all need to understand that DevOps isn’t a single thing. It is a variety of things, that when run in concert, create the DevOps experience. If you miss out on one of those you will probably still call yourself DevOps but you’re not quite fully realized. If you are missing out on more than one? Then you are farther away then you think.
DevOps is a combination of processes, tools / technology and people, that are, in essence, the operational response to Agile development. Agile started to deliver applications faster and faster. How do you build faster and faster? Well, in one area you start decreasing the size of the change because the smaller the change the less you had to test.
How did this affect DevOps? One of the building blocks of DevOps is continuous integration and continuous delivery. (Mixed in with that is also continuous testing.) By integrating more often and delivering more often results got put in front of the user faster. Small changes, implemented quickly. DevOps said, “yes, let’s do this“. And thus was born the automation aspect of DevOps. If you can automate as much as possible you can deliver faster. By integrating continuously, and testing, you can delivery continuously.
Each one of the sections in the top diagram can be automated to an extent or at least the process can be streamlined. DevOps isn’t just one thing, it’s a lot of things. You may have the capacity for continuous delivery, but if the business cannot handle continuous change then it doesn’t matter.
Processes. The processes need to be streamlined (and automated) so that only what needs to get done is actually done. Re-evaluate all of the processes, examine what is being done and why and then make a decision as to how to make it more efficient. There may be a manual process that you just can’t automate (ex, formal approvals) but be cognizant of the fact and understand the reasoning behind it.
Tools / Technology. Yes, there are very likely going to be a whole suite of new tools that an organization is going to have to acquire or, as is sometimes the case, they will need to more fully understand an existing tool that they already have. But tools change. Pick the right tool for the right job and don’t be surprised if a couple years down the road it is the wrong tool. Embrace the change.
People. The culture of an organization has to accept DevOps, warts and all, for things to work properly. This is usually accomplished by little successes on the way to the end goal (which will never be reached.) But don’t forget the people. Don’t assume that with new processes and new tools that they will automatically become DevOps savants or that they will even accept the change. The people have the biggest impact on the success or failure of any DevOps initiative.
A lot of people call themselves “DevOps” when they are not. Just because you have a team of developers and these developers also do operational work does not make the team a DevOps team. Do you continuously integrate? Is automated testing in place and functioning? How often do you deliver? Monthly? Weekly? Daily? On demand?
It would be awesome to have a definitive list of attributes, but that doesn’t exist. And while you may not be DevOps, you may be the closest thing your organization has.
All the more reason to change and become better.