By Mike Johnson, Performance Business Leader
Much of the existing literature about DevOps, both in the trade press and in the publishing world, focuses on how the paradigm is the next evolutionary step in software engineering, succeeding agile development in the same way that agile displaced earlier, more formal software methods. While it’s true that many organizations are transitioning from agile to DevOps to improve reliability, scalability and development costs, an overemphasis on the “Dev” side of DevOps underplays the important changes that have taken place in the world of enterprise IT that inform the “Ops” side of DevOps. Modern DevOps methodologies owe as much to these changes as they do to improved strategies for software development; consequently, organizations adopting DevOps have a lot of lessons to learn from the IT world.
While development and IT have always been intertwined, separate pressures have led to a different set of trade-offs and approaches. Development, with its high up-front costs and concrete deadlines, has always emphasized productivity and time-to-market, sometimes at the expense of quality, reliability or user experience. Further, the traditional coupling of software “versions” with marketing, sales and production efforts has favored a paradigm of large, well-defined releases full of new bells and whistles. In the IT world, maintenance and support costs have often exceeded those of acquisition. As a consequence, software has traditionally been deployed slowly, after thorough testing, and with full lifecycle support in place. A variety of manual activities including security engineering, helpdesk and configuration management have added time and cost.
Over the last decade, the IT world has heavily embraced SaaS, cloud and virtualization strategies as a way of reducing the traditional bottlenecks in enterprise computing. This adoption has caused a shift in IT priorities, of which DevOps adopters should take notice. The first lesson to be learned from enterprise IT is that consistency is key. Organizations can dramatically reduce support costs and increase reliability by deploying a minimal set of configurations that enable the needs of most users, rather than infinite configurability. This approach runs counter to the traditional attitudes of developers, often the first and most frequent users of their software, who want to maximize their own productivity. Virtualization enables consistency by providing a stable configuration base that can be replicated exactly in both development and production environments.
The second lesson to be learned is to lean on automation for every repetitive and non-creative task. Significant productivity gains have been made in the IT world through the adoption of automated patching, antivirus management, security scanning and deployment of new servers and desktops. This kind of automation makes sense for feature deployment, testing, and configuration management in the development world as well. Despite this, software engineers often still rely on private and manual processes to carry out daily development activities. While the impetus to “automate everything” may seem wasteful or unnecessary during the early stages of development while there is still significant “churn” in features and technology, in the long run automation is worth the investment by providing higher code quality and increased release productivity improving customer satisfaction and reducing development costs.
Finally, DevOps adopters can benefit from shifting their sense of done to match the attitudes of enterprise IT. The high ceremony releases of traditional software development, with champagne parties or planned vacations at the end, still color our sense of accomplishment in the software engineering world. While there are highs and lows, an enterprise IT environment is never “done” and always “under construction.” Much like the continuous patching and incremental rollouts of enterprise IT, DevOps teams release new features on a more or less continuous basis, while also taking responsibility for the deployment and ongoing maintenance of these features. While there may not be as many big parties to look forward to, developers, like their IT counterparts, will share in the sense of accomplishment that comes from users adopting and enjoying their features.
