Though the notion of DevOps has been around for years I still see folks struggling to articulate what DevOps really is. Like recently in our user group meeting the participants highjacked the session for 30 minutes debating what DevOps stands for without really arriving at a conclusion. Similarly, I have seen architects, sales teams and developers, struggle to explain in simple terms to their management as to what is DevOps. In this post, I will share my thought process and would like to hear from you if you have a simpler way of communicating the DevOps intent.
Traditionally software development has been a complex process involving multiple teams. You have developers, testers, project managers, operations, architects, UX designers, business analysts and others, collaborating to create value for their business. The collaboration among these teams requires handshakes which often cause friction (leading to non-value adds). For instance, the handshake where UX designer develops UI and then developers add code, or the handshake where analyst captures requirements and project team builds desired features, or the traditional handshake between developers and testers for code validation, and so on. One such critical handshake is between developers and operations where developers typically toss software over to operations to deploy it in upstream environments (outside of developer’s workstation). Unfortunately, members of these two teams have been ignoring concerns of each other for decades. Developers assume code will just run (after all it ran on their machine) but it rarely does. And that’s where DevOps comes in to rescue.
Considering above, it would be safe to summarize that DevOps is any tool, technology or process that can reduce friction during the handshake of Developers and Operations (thereby creating more value for their business e.g. faster time to market). Now this could be app containerization bundling all dependencies into single image, or it could be setting up Continuous Integration and Continuous Delivery pipelines to allow for robust consistent deployments, or adopting microservices architecture for rapid loosely coupled deployments or it could be infrastructure as a code to allow for reliable version-controlled infrastructure setup, or AI enabled app monitoring tools to proactively mitigate app issues or even reorganizing teams and driving cultural changes within IT organization. But once the DevOps objectives are clear it’s easy to devise your strategy and approach.
Does this resonate with you? Look forward to your comments.