Why is DevOps so important?

Article written by Ian Morrison: DevOps Consultant

I’ve been to countless conferences where the sport of the day was seemingly for speakers to take it in turns defining DevOps. As a recovering system administrator who revered the old Sun Microsystems slogan “The Network is the Computer”, my peers and I had pretty much always practiced what these corporate managers were trying to describe. Before it was called DevOps, the folks that were running large systems effectively had their stash of secret weapons; scripting, automated deployment, incident handling runbooks, monitoring, name-spacing, documentation, and collaborating over IRC. To us it was just best practice, and it’s been very interesting to see the wider world adopt these ideas as their leadership teams start to insist on increasingly higher standards of reliability, flexibility, scale, and performance. These days the tools and platforms have changed, but the principles remain the same.  

It is very easy to get caught up with the technical details when talking about DevOps; as somebody that has been on both sides of the coin, built systems and trained people on how to use them, I have seen that the temptation is to focus on learning more specific tools. There are dozens of mature DevOps tools out there today, and a modern organisation will likely see benefits from making use of many of them. However, in my experience, it’s best to resist the glamour of these tools to begin with and instead try to zoom out and view your challenges from a higher level. The question I ask myself and customers continually is “what is the problem you are trying to solve?”. Once you have explored that a little, the right tools and techniques should naturally follow. 

By stepping back and analysing the specific challenge you are facing, taking into consideration the challenges you have faced before, and are likely to face in the future, we can start to arrange our efforts so that challenges get easier over time. Each time we iterate over a process it gets better, and confidence in the system grows in return. 

Think of a thing you do regularly at work. Do you have a documented process? Have you tested the documentation by getting a team member to follow the process? What is the information that you will need while working through the process? How does the process change each time you do it in slightly different circumstances? The key concept to streamlining these problems is consistency. By analysing the process, minimising variations and potential permutations, it becomes possible to take a documented process and automate it. Automation in turn provides many benefits, not just labour and cost savings, but to me at least, automated processes simplify the environment, and therefore the systems you are managing by enforcing consistency. 

The basic idea is to identify chaotic business processes. Every organisation and their departments within, have things they do regularly that would benefit from automation and consistency. Start by defining the problem clearly and document the existing process as best you can. Identify the parameters that change with circumstances. Make it repeatable. And finally, when you can run a process at will, optimise it. Make it easier to maintain, more robust, inter-operate with other components or processes. Look for areas where human intervention is required; what information do they need? What do they need it for? And how can it be represented in the system? Can you describe the situation with a simple true false statement, or if more granularity required?  By identifying these operational information requirements, the whole ecosystem can be enhanced to make work life easier for everyone. 

For example, you have automated the build and configuration of a typical company laptop. At the end of the process a simple alert which says if it has worked or not might be enough. But if your builds are complex, and take a long time to run, your analysis might reveal a need for a decent logging solution so that if things go wrong, you can search through the logs to understand and resolve the problem.   

People will continue to try and define DevOps. To my mind, it’s simply about developing a better operations practice. Work out what the problems you’re trying to solve are. Identify the things that make life more difficult, and design solutions that minimise or mitigate entirely. If you would like a hand with that, please feel free to get in touch with the Towers Associates team.