All the ISVs and Enterprises are having the same question, who/what is DevOps. We get in a virtual room and talk about it, but we are often all scratching our heads at the same time. We are not confused from a technology or definition standpoint. There is so much chatter about this thing, it’s just hard to find the person or group that is doing it.
My response to when I’m asked about DevOps is always the same. Are you are talking about DevOps the movement, or the function? The movement is what we are all hot and bothered about, but the function is where it really comes together and problems are solved. And even if you hate the movement, I guarantee your dev and operations team are inching in that direction, and some portion of the work already being done is in the DevOps spirit. So what is it? Nope I’m not going to write another post defining DevOps. Instead I will tell you where to find it.
The movement includes culture, and the merging of two, once separate functions. This is where the greatest push back comes. However the function, tools and processes, besides continuous delivery (CD), generally are accepted by everyone. CD is often seen as a disaster waiting to happen, and really not great unless you have HUGE user volume, continuous integration however, that is all good.
The problem in finding the DevOps function today is the exact problem DevOps tries to solve. No one person owns it. Some is owned by dev, some by operations, sometimes they are both duplicating efforts at the same time. Developers get annoyed and start grabbing tools, while IT has a well thought out plan to move to them. God that is annoying.
What DevOps acknowledges is that the relationship between IT and Dev has been rocky. But to be effective in software delivery it needs to be solid. And because software is more and more a part of the bottom line, it is serious stuff.
If you are outside this world you think Dev and Operations are the same damn thing. Crazy technology stuff. But we know it is not the same. Although Developers know a lot about the computers and stuff, they should not spend time on it. And if they do, it should be automated, not manual. IT knows what coding is, they even like to script from time to time, but generally not a fan, and really not a fan when developers have wonky infrastructure requests, and a lot of them. In smaller groups where the application is mostly front-end dev, the conflicts become something about right-brained and left-brained. A people problem.
But both are working on the software delivery pipeline, usually IT on the SLA side. Focusing on preventing fires, and putting them out when they happen. And Dev, is all about making magic with code. But dev also has to respond to fires, and they HATE it.
So really they share very similar pains, but they seldom have the same goals. Why the hell not! Why should developers KPI be features, but ITs uptime. They both should be focused on results.
This is where the DevOps tooling and processes make it happen. Because a lot of IT teams are already considering QA automation tools like Applitools, release tools like Jenkins, and orchestration tools like Chef, and Stackato. And they all seek to make the process faster and less expensive ( well unless you are in one of those organizations where budgets are power ). So you are doing DevOps, but you are not calling it such.
And even if you don’t label it this way, the general trend is he same. And I suspect that by bringing in the tools and processes developers and IT will HAVE to communicate better to get them implemented. So you might just have DevOps culture as well, without even knowing it.
Wham! Just like you started having stand-up meetings and sprints, without calling it Agile. Remember how much people hated Agile? DevOps the movement will come naturally, no need to force it. But today the functions are already there, just need to emphasis how important results, and automation are, and you will be a DevOpser like everyone else.
