Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
I’m all for DevOps. Sometimes, however, I have a hard time talking about DevOps. The reason is because many of the key terms related to DevOps lack clear and precise definitions.
Let me explain …
DevOps is such a big deal that it has bred its very own lexicon. Search Google for “DevOps terms,” and you’ll find a slew of “dictionaries” and “glossaries” dedicated to defining the various terms that go hand in hand with DevOps.
Yet despite these resources, some deep ambiguities remain regarding the actual meaning of various terms that you hear frequently in DevOps-centric conversations. Let me walk through some of the biggest.
Continuous
DevOps is all about continuous this and continuous that. Continuous integration. Continuous delivery. Continuous deployment.
To me, the problem with the word “continuous” in this context is that it lacks an exact meaning. No one is integrating, delivering or deploying software in a literally continuous fashion. That would mean having zero delays between different releases, which is not the case. Even organizations that do CI/CD really well manage deliveries and deployments of only once per day or so.
Maybe instead of “continuous,” we should just say something like “fast.” Because that’s what “continuous” really means in most cases.
CI/CD
Speaking of CI/CD, that’s another term that is ripe with ambiguity. It’s clear enough what “CI” stands for (continuous integration). But does the “CD” stand for “continuous delivery,” “continuous deployment” or both? Or does it not matter?
Moreover, does a your application delivery process qualify as a CI/CD pipeline simply by including a continuous integration server (to do the CI) and some kind of automated deployment tool (to cover the CD side of things)? Or does a CI/CD pipeline also necessarily include build and test automation? I think most people would say the latter, but the term itself does not imply that.
Microservices
Microservices are all the rage in the era of DevOps. Depending on how you define a microservice, however, they have been all the rage for decades, long before anyone was talking about DevOps.
The idea of distributing applications into multiple services is not new. That’s what SOA was all about in the 2000s. Going back further, there were microkernels, a concept popular in the 1980s. In microkernel architectures, the operating system kernel runs as a set of distinct services, rather than as a monolith.
The question, then, is what makes a microservice, or a microservices architecture, different from other types of distributed, service-based architectures. Maybe it’s the size of the service, but there’s no official definition of what distinguishes a microservice from a non-microservice.
Agile
It is often said that DevOps builds upon the principles of agile software development. Those principles were defined, at a high level, in the early 2000s and spelled out in the “Manifesto for Agile Software Development.”
It’s clear enough what agile means, but I’ve long struggled to piece together the exact relationship between agile and DevOps. Is DevOps “agile applied beyond the software team,” as one DevOps company puts it? Or are agile and DevOps distinct practices that just happen to have similar goals?
It’s hard to say, because there is little consensus about what exactly “agile” means in the context of DevOps.
DevOps
Last but not least is “DevOps” itself. Different people have defined DevOps in very different ways. AWS says it is “the combination of cultural philosophies, practices, and tools.” Other definitions focus on philosophy, and leave tools and specific practices mostly out of the picture.
Blurring the definition of DevOps further is the fact that virtually every tech company in the world calls itself a DevOps company today, with little concern for how, specifically, its products or services meet that nomenclature.
What does DevOps really mean? I don’t think we’ll ever have a singular answer to that question.
Conclusion
In fact, I don’t think there will ever be clear definitions for any of the terms I’ve listed above. I’m not suggesting there should be.
But I do think it would be helpful to the DevOps community as a whole to recognize the ambiguity in many of these terms. We use these words as if everyone knows what they mean, but the reality is that that is often not the case. If you want to use terms like “continuous” or “agile,” do so, but remember to clarify what those terms mean to you, because you can’t assume that they mean the same thing to others.
