DevOps terms: where they came from and what they mean
Our glossary of DevOps terminology
DevOps started as a simple concept of breaking down barriers between teams. The main problem with DevOps was the name. DevOps – Development & Operations. What about Testing? Security? Design? Finance? Marketing? This is why we have so many DevOps terms now. The intent was simple, the meaning was simple, but it was not inclusive.
As Cloud & DevOps solutions experts, we help you avoid confusion with our DevOps terms glossary and by explaining what each of them means:
Popular DevOps terms
DevOps: Development and Operations, working together to release software effectively, efficiently while fostering a collaborative work ethos.
DevTestOps: As above but including Testing.
DevSecOps: As above but including Security. One difference here to DevTestOps is how the security engineers are embedded in teams as typically security sat outside of development. Embedding security engineers means they can work iteratively. Companies may also have a separate DevSecOps team that integrates across the organisation.
DesDevOps: You’re building software, testing it, making it secure, but don’t want to design it? Of course you do, so DesDevOps is about a tighter integration of design into the development process, not having it lead the development process by a few weeks but having it working within the development process to ensure it can deliver iterative improvements in design.
AiOps: The integration of Ai into Ops, allowing you to feed your observability metrics into the system and allow it to make decisions in the name of uptime (such as rebuilding an instance or rebuilding a solution). You can also feed your logs into the service and have it tell you a problem is coming based on the information coming in.
NoOps: This is a combination of some of the others but on steroids. The aim here is to build a hands-off operations team, requiring an independent developer platform (IDP), self-healing, centralised monitoring, logging etc all feeding information to the development teams allowing them to solve their own problems.
ChatOps: Embedding the control interface for your services into chat tools like Slack so you can see alerts of incidents and have the chatbot manage your incidents or environments. One use case here is to manage dynamic environments by having the chatbot reach out to the owner of an environment and allow them to extend it or else the bot will terminate.
FinOps: With the advent of the *Ops movement, cost control spiralled a little as people became very eager to make use of the cloud, but they forgot key details like the visibility of what is happening in the cloud (who is the owner? How do budgets flow for the cloud account?). FinOps is therefore concerned with right-sizing instances and using different technologies to reduce costs.
SRE: Site Reliability Engineering is a concrete implementation of DevOps. It is opinionated on how you should run your DevOps team, the actions they should take and the work they should do. One common difference here is allowing the site reliability engineers to make code changes to the product to fix live issues. This cuts down on the time needed to get a fix and keeps uptime high, which is the function of SRE.
Platform Engineering: This is a specific way of implementing DevOps as a centralised team that provides tooling, technology, and best practice to multiple teams. Not as concrete as SRE, but the focus of the team is to enable other teams to be as successful as possible through the use of common tooling and frameworks.
Are these terms important?
The short-term answer is no. Each of these terms has DevOps’ fundamental philosophy of ‘make it work, make it better’ behind it.
The long-term answer is yes.
One of the challenges when you are talking about DevOps as a whole is the breadth and depth of what it has come to mean. When something is big and broad it is very hard to get people to understand the full impact of what it can and will do. It becomes a cult or a religion where you must have faith in the process and the outcomes before you can get behind it.
By creating very specific terms you can tailor the meaning to a team. It is far easier to articulate to a CISO that security is a focus for the DevOps team if you have a DevSecOps team. The work is the same, and the people are the same (give or take experience and tooling) but the focus is different. Therefore, the CISO understands that by having a dedicated resource working with the teams, security will be dramatically enhanced, and it will mitigate a perceived risk of ad-hoc unmitigated changes in a standard DevOps approach. Whether those issues existed or not does not matter – it was easier to sell.
As such, consultancies leverage these terms because it allows them to focus on specific pain points a customer has and other specific solutions. This is far easier than saying “You need to implement DevOps” because, from the organisation’s perspective, they already have (even if they missed key elements of it).
The same is true from an engineering point of view: you can highlight the importance of testing in a release cycle by focusing on DevTestOps. In organisations where testing is mature, this may not be a specific problem because testing is mature, but others will benefit from a dedicated DevTestOps team.
We are all trying to make the general DevOps approach work in some way, and these terms are the tools we use to help communicate and convince people to get behind the approach.