The DevOps movement is centered around the notion that we are all here to bring value to our users. Whatever the application, whatever the infrastructure, whatever the bureaucracy, and whatever the process, IT should simply be about providing users with application experiences that add value. To that end, we should all be working together.
The walls of the silos in IT organizations have been coming down for a long time. The days of server admins pointing their fingers at network admins are surely passing. The same is true in development environments, and application programmers have learned to effectively collaborate with UI designers.
Oh, and what about the security guys?
They simply want application experiences that add value.
DevOps is about the entire IT community recognizing and internalizing that, and most importantly, working collectively towards the greater good: better application experiences.
All of that is easy to say, but what does it mean? What problems do we really need to solve? Well, that’s the hard part, because the problems span cultures, not products or implementations. There are toolsets that have been labeled ‘DevOps tools’, and mostly they center around automation. While automation is important, and is definitely something that the IT community is ready for, and in need of, DevOps is bigger than that.
Everything in IT needs to change. It needs to start with communication and understanding. Understanding the challenges we are all trying to solve, and the obstacles we are all trying to overcome. After that, it needs to progress to bureaucracy and process, before we even consider the tools. Including the perspective of all of the groups in IT, and most importantly the way they can all work together for the common good.
The history of Network and IT Management is an interesting one. It has been around for many decades, and while the discipline has matured greatly, the challenges, the technologies and the solutions are less varied. The DevOps movement is an interesting place for a retrospective on IT management. I say this because their goals have always been similar.
For Management tools, the goal has always been “can you provide me with the information and visibility to make sure my users are always happy?” A management tool can tell you when you are trying to use more bandwidth that you have. It can tell you when a device is down, and who it’s affecting. It can even tell you when a particular cooling fan fails (if that’s what you want), but when your users aren’t happy? Yeah, that is a hard one.
After all, users are ornery, unpredictable, and usually not very technical. How could anybody predict their mood? Wait a second — what if they just expect the applications that they need to work, and for them to provide the value that they need to do their job? Maybe that’s all it takes to make them happy.
Maybe after all these years, IT Management tools are the white knight ready to provide the DevOps community with all of their answers. Wouldn’t that be cool?
Well, we’re not — nobody is. There are many, many layers to this onion. But before you can peel away at it, you need to see each layer, and understand them for what they are.
You do need to know if your applications are responding, how quickly, and how much load they are under. You need to know who is using them. You need to know if the resources providing them are working properly. You certainly also need to make sure that they are all configured to be secure. You need to make sure when people make changes, they are recorded, understood, communicated and tracked.
And, by the way, you better know when a fan fails. That could easily be the nail that breaks the shoe, that cripples the horse, that stops the rider, that loses the message, that loses the battle, that loses the war. All for the want of a $5 fan.
So how does IT get what they need in order to ensure they can provide their users with application experiences that provide value?
To do that, you need consistency, you need effective and flexible standards, you need communication, you need executive support, you need the walls to be torn down, and you need to know we are all in this for the greater good of the users.
You need all that, but you also need excellent visibility. You need to know how your users are doing, and what they are doing. You need to know how your resources, and providers, and hardware is working.
You need to know right now, if anything in particular needs anyone in particular’s attention. That is what OmniCenter does for DevOps.
