In his Behaviorally Speaking series, Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior.
DevOps was front and center throughout the past year with many organizations working to embrace deployment best practices—sometimes referred to as agile systems administration. At the beginning of the year, Scott Ambler predicted that 2012 would be the year of DevOps.
Frankly, I shared that sentiment and expectation. However, as the year comes to a close I do not believe that DevOps has come into its own as an industry best practice. I believe that in some ways, DevOps has failed and we need to hold our own retrospective to understand how we can best improve. This article will take a look at what worked and what didn't in DevOps in 2012.
DevOps focuses on improved communication between development and operations along with integration with QA and data security among other stakeholders. Most of my own efforts this past year have centered on implementing DevOps to support critical systems, including large-scale banking and financial systems.
I have also been watching as job descriptions for DevOps have evolved over the past year as well. What I see from the job requirements and many discussions with colleagues is that DevOps is not well defined at all and, in many ways, really misunderstood. In my opinion, DevOps has failed to communicate its goals, methodologies, and values.
The need for DevOps is great. Many large banks have suffered major outages often related to failed attempts to upgrade or integrate systems (after a corporate merger). Major airlines have had similar issues also related to upgrading and integrating systems.
The most notable DevOps disaster this year was the failed implementation of NYSE-related trading software by Knight Capital Group. As reported by other publications, Knight Capital had old networking software that impacted a systems upgrade, resulting in the purchase of billions of dollars of unwanted stock. The resulting loss was over $440 million dollars and the company is now in the process of being sold. If the deployment engineers had read the IEEE 828 configuration management standard then they would have noticed that retiring unwanted software is just as important as upgrading and installing new software. These are tough lessons learned and Knight Capital is not alone.
DevOps is widely misunderstood. Also, known as agile systems management, DevOps is not an excuse for having developers deploy to production, and frankly reading some of the job specifications out there leads me to conclude that some folks have really misunderstood the role of DevOps. Establishing IT controls and maintaining a healthy separation of duties is essential and legally required in many industries including banking, finance, and defense.
DevOps meets a critical need in deployment engineering and addresses a common source of errors. By moving the process upstream we use deployment automation to support build, package, and release to test environments starting with development and QA test, which continues with UAT and ultimately production. By moving the deployment automation upstream to support developers, we embrace the full development lifecycle and give ourselves the time needed to fully automate the build, package, and deploy. This is really the spirit of DevOps.
Too often developers have the expertise and only bring in the operations guys at the tail end of the process, which does not leave sufficient time for operations to learn the new technologies involved. DevOps breaks down these barriers and gives us a chance to automate our entire application deployment process. DevOps also does not skimp on IT controls. We still need source code management along with automated application build, package, and deploy. Most of all we need good communication.
As IT professionals, we need to identify and include all stakeholders in the DevOps process, including development, QA, data security, and operations. We also need to include our business users. Recently, I attended a holiday party in New York City and had an opportunity to chat with one of the end users who was on the other end of my late-night deployments for a cloud-based technology. I learned a lot from that discussion which led me to understand how we should be approaching deployment automation quite differently.
DevOps needs to come into its own in 2013. We need to improve our training approaches to DevOps and help technology professionals understand its benefits and effective methodologies. Perhaps we should say that DevOps got rolling in 2012 and our goal is to cross the finish line in the coming year!
