Cloud was the catalyst for the schism between IT Operations and Development Teams. Slow Ops processes drove rogue Dev activities. The people passionate about (or addicted to) execution became dissatisfied with the process and searched for alternative development paths to avoid inefficiencies.
Cascadeo SVP Thomas Burns Reflects on the Evolution of DevOps and Teamwork
During the dot-com boom (2000-2005), I worked for a startup software company. There were approximately 20 members on the software development team, including developers, graphic designers, and project managers; there were roughly 5 members of the IT Ops team including infrastructure, data center, and security. I sat in the middle as a Sales Engineer.
We worked well as a team. We understood each other’s responsibilities to the process, the importance of their effort, and we depended on each other to do it well. This was a collaborative team effort every day.
As my career progressed, I was exposed to different areas of the IT industry, like project management consulting, data center, cloud infrastructure, managed services, and then back to software development. However, there had been a 13-year gap between working intimately with software development teams. I was surprised by the animosity that had developed between the Ops, the Devs, and the Secs. They had all become heavily specialized and saw the other as the origin of everything evil. IT Ops wanted arbitrary control. Development needed speed and flexibility. Security wanted constant oversight. Nobody wanted to work together.
The Cloud Era
Cloud was the catalyst for the schism between IT Operations and Development Teams. Slow Ops processes drove rogue Dev activities. The people passionate about (or addicted to) execution became dissatisfied with the process and searched for alternative development paths to avoid inefficiencies.
Yet, which way does water flow down the mountain? The easiest most effective path. Software development is a force that can only be constrained for so long before leaks form in the dam and rogue development activities begin to spread. The accessibility of infrastructure in the cloud was a fertile environment to promote productivity over security and process.
Uncontrolled cost sprawl brought the Ops team back into the game. When cloud OPEX costs soared, CFOs started to mandate operational control again. Although the pendulum swung toward IT Ops again, the proverbial cat was out of the bag. We are never going back to test dev server acquisition forms and multi-tier manager approval processes ever again.
Here We Are Again
IT Ops and Software Development teams need to work together, collaborate, and continuously accelerate deployments.
Just like technology itself, IT Ops has evolved. We have created new roles, tools, and methodologies to suit the software development modus operandi. Now we have Site Reliability Engineers who build automation. We adhere to Agile project management practices that allow for flexibility and change. We have immersed entire teams in the continuous development and continuous integration process. We utilize low overhead technologies like microservices, containers, database services. Ops builds security and redundancy into the application architecture itself–it is no longer an afterthought that needs to be resolved at the end of the software development process. AIOps has become the standard in observability. Ops uses data and machine learning to avoid operational failures and ultimately provides application uptime.
Are DevSecOps teams moving in perfect harmony? While I wouldn’t go quite that far, the collaborative effort feels much more like the early boom days. We’re getting there, though, and just in time for the new battle between NoOps and NoCode!
