August 1, 2018
Wikipedia defines DevOps thusly:
“DevOps is a software engineering culture and practice that aims at unifying software development and software operation. The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.”
While the definition above is accurate, it focuses solely on the technical, process, and tooling aspects of DevOps, but ignores the important organizational communication factors which DevOps enables.
Back in the “bad old days”, before DevOps, the typical relationship between a development team and an operations team in a large organization could best be described as indifferent.
The dev team would work on their application design and code without much thought given to how the operations team was going to implement that application at scale. When an executable was ready (a war file, for instance, if we’re talking about a Java app), the devs would just throw it over the wall to ops. It would be up to ops to make it work in their production environment.
This can result in any number of downstream operational issues caused by either design decisions which didn’t account for application performance at scale, or other considerations which simply didn’t get addressed because the dev and ops teams tended not to talk to each other much.
DevOps tools and processes are meant to fix that communication gap and create a much fuzzier line between who is “dev” and who is “ops”. Both sides of that fuzzy line need to understand what the other side does and provide feedback in both directions as early as possible in a product’s development cycle, so as to avoid the consequences which typically result from a lack of that kind of communication.