3 ms·

While your concerns about the term "DevOps" are certainly valid, I'd like to offer a tiny counter-perspective that I think could offer some clarity. Firstly, t

While your concerns about the term "DevOps" are certainly valid, I'd like to offer a tiny counter-perspective that I think could offer some clarity. Firstly, the idea that "DevOps" is rewriting history doesn't hold up well when you consider the natural progression of any industry. Concepts and terms evolve over time. It's not rewriting history, it's a sign of the industry maturing. Speech is in flux all the time, otherwise this post would also read like Shakespeare. Second, the lack of a universal definition isn't necessarily a bad thing. In fact, it might be a strength. It allows different organizations to interpret and apply the principles of DevOps in a way that best fits their specific needs. This flexibility can actually drive innovation. Or differently set, the meaning is assigned and not a given. As a freelancer in the space I get a lot of different offers under the same umbrella, but the truth is that i can simply help in a lot of areas by definition. Third, just because the originator of the term can't pin down a solid definition doesn't necessarily discredit it. It's common in tech for concepts to outgrow their original definitions as they are applied in new contexts and grow in scope. Your point about DevOps teams or engineers signifying failure is also too black and white, in my opinion. The title is less important than the actual practices and methodologies being implemented. Whether we call them DevOps engineers or agyle sysadmins is secondary to their contribution to the project. That is what the job description is for. However, calling this entire branch of IT "bullshit", will remain a marketing scheme for your underlying investment, no matter how much you now try to blame it upon technicality.

dijit 3y ago
> Firstly, the idea that "DevOps" is rewriting history doesn't hold up well when you consider the natural progression of any industry. Concepts and terms evolve over time. It's not rewriting history, it's a sign of the industry maturing. Speech is in flux all the time, otherwise this post would also read like Shakespeare. Yet words like "bridge", "ceiling" and "concrete" are unchanged for a century. Evolution is fine, but we're chocking on our own spit trying to be "next" and "hip" and whatever. So much silly useless effort, but this is worse anyway because we went from more formalised and easy to understand terms to a fuzzy one which nobody had clearly defined. > Second, the lack of a universal definition isn't necessarily a bad thing. In fact, it might be a strength. It allows different organizations to interpret and apply the principles of DevOps in a way that best fits their specific needs. This flexibility can actually drive innovation. Or differently set, the meaning is assigned and not a given. As a freelancer in the space I get a lot of different offers under the same umbrella, but the truth is that i can simply help in a lot of areas by definition. Sorry, no this is a super bad thing, you don't get to choose what "yes" means given a concrete context. This is not materially different. If you have a different job: it should be called as such. > Third, just because the originator of the term can't pin down a solid definition doesn't necessarily discredit it. It's common in tech for concepts to outgrow their original definitions as they are applied in new contexts and grow in scope. He never even supplied a definition, so we are stuck in this loop of defining it constantly. And our definitions almost never match. Lets just let it die. Almost as much time wasted as with timezones. > Your point about DevOps teams or engineers signifying failure is also too black and white, in my opinion. The title is less important than the actual practices and methodologies being implemented. Whether we call them DevOps engineers or agyle sysadmins is secondary to their contribution to the project. That is what the job description is for. I'm just pointing out that many people disagree on the definition, so many will just claim outright that you're doing it wrong. I agree that actions are better than definitions, I'd rather have shitty definitions and functional actions; however that's a false dichotomy, we can have both. > However, calling this entire branch of IT "bullshit", will remain a marketing scheme for your underlying investment, no matter how much you now try to blame it upon technicality. I am invested in nothing, I have no financial or even sunk-cost gain from taking this particular fight, so you're concretely mistaken. FWIW, I am not the original author of the article; mine is here and was written a year earlier: https://blog.dijit.sh/devops-confusion-and-frustration https://blog.dijit.sh/devops-confusion-and-frustration
- jhoelzel 3y ago
  There are over 6500 languages out there (so google tells me) which means there is a lot of interpretation for what word should actually be used for "bridge". At this point we have not even talked about the fact that DevOps is an umbrella term by definition. > "Sorry, no this is a super bad thing, you don't get to choose what "yes" means given a concrete context. This is not materially different. If you have a different job: it should be called as such." Sure we do. It's a made up word for a concept. Especially when we are describing the widest range of possible work for a person working in IT. I have a final point for you: If you really want to go down your own road, your job should have been called "Person who sets up the Kubernetes cluster with terraform, ansible and yaml". No platform is the same. No DevOps is the same. Henceforth we use umbrella terminology.
  - dijit 3y ago
    > "Person who sets up the Kubernetes cluster with terraform, ansible and yaml" Distributed Systems Engineer Cluster Administrator (the actual IAM Role, incidentally; weirdly not called "DevOps") Container Platform Engineer Deployment Automation Engineer Or should I just call developers "IT"? ;)
    - pid-1 3y ago
      Let me join the exercise: > Distributed Systems Engineer Probably best reserved to people that implement distributed systems. One can deploy and manage a K8s cluster with 0 distributed systems knowledge. > Cluster Administrator That's a good one. But many DevOps do more than managing clusters: I create and manage templates for our CI/CD pipelines, project templates and internal libs that abstract best practices, manage networks, databases, data lakes, identity providers... And develop internal applications to automate ops of all those resources. > Container Platform Engineer Same issues as the titles above. > Deployment Automation Engineer That's a good one, I like that. In the end of the day, everything a "DevOps" do is done to deploy things faster and more consistently to prod, as well as keeping deployments running correctly. I think we can even drop the Automation and use "Deployment Engineer"
    - 3y ago

dijit 3y ago

> Firstly, the idea that "DevOps" is rewriting history doesn't hold up well when you consider the natural progression of any industry. Concepts and terms evolve over time. It's not rewriting history, it's a sign of the industry maturing. Speech is in flux all the time, otherwise this post would also read like Shakespeare. Yet words like "bridge", "ceiling" and "concrete" are unchanged for a century. Evolution is fine, but we're chocking on our own spit trying to be "next" and "hip" and whatever. So much silly useless effort, but this is worse anyway because we went from more formalised and easy to understand terms to a fuzzy one which nobody had clearly defined. > Second, the lack of a universal definition isn't necessarily a bad thing. In fact, it might be a strength. It allows different organizations to interpret and apply the principles of DevOps in a way that best fits their specific needs. This flexibility can actually drive innovation. Or differently set, the meaning is assigned and not a given. As a freelancer in the space I get a lot of different offers under the same umbrella, but the truth is that i can simply help in a lot of areas by definition. Sorry, no this is a super bad thing, you don't get to choose what "yes" means given a concrete context. This is not materially different. If you have a different job: it should be called as such. > Third, just because the originator of the term can't pin down a solid definition doesn't necessarily discredit it. It's common in tech for concepts to outgrow their original definitions as they are applied in new contexts and grow in scope. He never even supplied a definition, so we are stuck in this loop of defining it constantly. And our definitions almost never match. Lets just let it die. Almost as much time wasted as with timezones. > Your point about DevOps teams or engineers signifying failure is also too black and white, in my opinion. The title is less important than the actual practices and methodologies being implemented. Whether we call them DevOps engineers or agyle sysadmins is secondary to their contribution to the project. That is what the job description is for. I'm just pointing out that many people disagree on the definition, so many will just claim outright that you're doing it wrong. I agree that actions are better than definitions, I'd rather have shitty definitions and functional actions; however that's a false dichotomy, we can have both. > However, calling this entire branch of IT "bullshit", will remain a marketing scheme for your underlying investment, no matter how much you now try to blame it upon technicality. I am invested in nothing, I have no financial or even sunk-cost gain from taking this particular fight, so you're concretely mistaken. FWIW, I am not the original author of the article; mine is here and was written a year earlier: https://blog.dijit.sh/devops-confusion-and-frustration https://blog.dijit.sh/devops-confusion-and-frustration

jhoelzel 3y ago
There are over 6500 languages out there (so google tells me) which means there is a lot of interpretation for what word should actually be used for "bridge". At this point we have not even talked about the fact that DevOps is an umbrella term by definition. > "Sorry, no this is a super bad thing, you don't get to choose what "yes" means given a concrete context. This is not materially different. If you have a different job: it should be called as such." Sure we do. It's a made up word for a concept. Especially when we are describing the widest range of possible work for a person working in IT. I have a final point for you: If you really want to go down your own road, your job should have been called "Person who sets up the Kubernetes cluster with terraform, ansible and yaml". No platform is the same. No DevOps is the same. Henceforth we use umbrella terminology.
- dijit 3y ago
  > "Person who sets up the Kubernetes cluster with terraform, ansible and yaml" Distributed Systems Engineer Cluster Administrator (the actual IAM Role, incidentally; weirdly not called "DevOps") Container Platform Engineer Deployment Automation Engineer Or should I just call developers "IT"? ;)
  - pid-1 3y ago
    Let me join the exercise: > Distributed Systems Engineer Probably best reserved to people that implement distributed systems. One can deploy and manage a K8s cluster with 0 distributed systems knowledge. > Cluster Administrator That's a good one. But many DevOps do more than managing clusters: I create and manage templates for our CI/CD pipelines, project templates and internal libs that abstract best practices, manage networks, databases, data lakes, identity providers... And develop internal applications to automate ops of all those resources. > Container Platform Engineer Same issues as the titles above. > Deployment Automation Engineer That's a good one, I like that. In the end of the day, everything a "DevOps" do is done to deploy things faster and more consistently to prod, as well as keeping deployments running correctly. I think we can even drop the Automation and use "Deployment Engineer"
  - 3y ago