DevOps is one of those buzzwords where if you ask 20 people what it means you will get 20 different answers. Despite the hype surrounding it, I think it will have an enduring and important legacy. The reason is that the DevOps approach offers real, practical benefits for IT quality. At the core of this approach is a simple idea: developers build more operations-friendly applications, and operations people adopt a software development like process for IT management. The result is one integrated and harmonious process instead of two distinct and often conflictual ones.
It doesn’t matter if one of these groups is missing in your shop; you still benefit from this approach. If you are a software development only shop then designing and building your software to better support operations will enhance your application’s quality. Software developers tend to focus on features and implementation details rather than all that operations stuff. Adopting an operations view balances that normal bias. In practice this means providing better tools for deploying, configuring, monitoring, and managing the applications. For example, developers can provide:
- Useful log messages that help administrators troubleshoot issues instead of impenetrable low level code debug statements
- Integration with the existing management and monitoring systems used by the administrators of your target platform. For example, use syslog instead of a custom solution on Unix platforms
- Instrument the applications so that they can be properly monitored by IT monitoring systems
- Provide administrative APIs to allow administrators to automate the management of the application using tools such as Puppet and Ansible. Keep these simple and use an administrator-oriented vocabulary. Offer a command line API.
- Provide comprehensive application self-tests, especially for configuration files. Administrators should be able to validate that a configuration file has the correct syntax, and that the configuration has produced the desired state of the application. Both of these tests should scriptable just like a unit test for the code.
- And of course the documentation should be good, and by good I mean task oriented. Poor documentation is the rule in open source projects so here is area for considerable quality improvement.
On the operations side it is more about process. The DevOps approach asks operations people to adopt a software development methodology as part of their change management process. The first step is to have a formal change management process. All the new tools in the world won’t matter if you don’t have a good process. There are plenty of standards to follow (see for example, the ITIL Service Transition processes or IEEE 828-2012). You don’t have to create one on your own.
Once this process is identified and documented then operations can automate it just software developers do. Or as I should say, good software developers do. This means treating all changes like a code base which is configuration managed (CM), uses version control, integrated through a CI server, and thoroughly tested under realistic conditions. This software development like process applies to all IT assets: OS configurations, application configurations, databases, VoIP phone systems, switches, routers, and so on. Every change goes under CM, every change goes through this process, and, ideally, every change is automated.
Of course, even when operations has put such a process in place it cannot achieve this level of process maturity if the developers haven’t supported it in their applications. This is why it is DevOps and not just “Ops”. Both communities are partners in quality improvement. Both communities have something to learn from the other.
As a side note, I use the term quality often here and in my other posts. By quality I mean the excellent definition provided by ISO 9126. The ISO standard for software quality is concrete and measurable. Developers and operations people can use it as a guide to their quality improvement process and I highly recommend it.