Hacker News Reader

> I am so sick of these shoesalesman trying to get you to adopt their platform which runs on another platform which runs itself on wishful thinking and startdust.

I think you misunderstood basically everything about this post. The author is not saying to adopt the author's platform, the author is saying that beyond a certain scale, every org is actually building their own internal platform whether they elect to view it that way or not: the author is arguing the opposite of what you describe in this sentence.

> You dont get people who do "DevOps" fresh out of college or people that have been barely using a computer for some time. You get the dudes with experience, but every time someone with experience makes up one of these buzzwords like "platform engineer" "lord of the box" or whatever, tons of people just assume the role without having the experience.

did you even read the post? From the post:

> We have an industry-wide shortage of expertise in the cloud space, a great IDP should have safe, dependable building blocks for designing cloud services quickly.

The ... entire argument is that you need strong foundations and reusable building blocks, and those things take expertise to build specifically because most product engineers do not have or want that expertise.

Your whole argument is describing something the post isn't saying.

> " the author is saying that beyond a certain scale, every org is actually building their own internal platform whether they elect to view it that way or not"

Ohh so devops is not bs? quelle surprise ;)

> The ... entire argument is that you need strong foundations and reusable building blocks,

Like the terraform code he himself admitted to copy and pasting.

> because most product engineers do not have or want that expertise.

henceforth again, devops is not bs. Therefore i conclude the intend of the post is nothing more than an advertisement piece.

Of course the post isnt directly saying "buy my product" by showing it in your face, but then again I have not said that either.

Its super easy though to click on the logo in the top left corner of the post to realize the site, on which this blog is on is directly advertising itself as "Defining Platform Engineering"

heneforth, yes i conclude shoesalesman trying to get you to adopt their platform through a linkedin advertised blog post =)

> If you click on the username you will see that this person tried the same post 7 month ago

I bang this particular drum quite loudly, for sure. However if you'd indulge me as to _why_ I hope I'd be able to change your mind.

To start with, I'd like to state that while I'm not a fan of useless things, I can definitely make peace with non-perfect terms, systems and things that serve no purpose.

However, when it comes to things that actually cause harm: I can't abide that.

Why would "DevOps" as a term cause harm?; you might ask.

It's harmful because it is:

A) Rewriting history

B) Has no universally agreed upon definition

C) Is a term that's proginator can't even define in his own terms

D) Has no chance of ever having a universally agreed upon definition.

The deal is thus: if you have a devops team, some people will say you have failed devops.

If you have a devops engineer; some people will say you failed devops.

If you "practice devops" and you have no people focused on operations: I would say you've failed devops.

So what do we call the people who actually ensure operational excellence and best practice? Aha. DevOps.

I'm not trying to sell you anything, I just think this treadmill needs to stop.

I know it's unfashionable but hiring sysadmins into your project team and having them tied to your Agile methodologies is fine, sysadmins need to code though, as they always did. Heck, even Pat Dubois (originator of the term DevOps) originally envisioned the role as "Agile Systems Administrator".

You might think me pedantic or that I'm being needlessly overwrought on this topic; but precision in language is a very real engineering problem.

We must be precise with our terms, and if we can't even get our methodologies or job titles to align as an industry, can we really be trusted to get any other terminology right.

If you think I'm kidding about precision in language being an engineering problem I invite you to read: https://fileadmin.cs.lth.se/cs/Education/ETS170/IREB_CPRE_Gl...

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.

> 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

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.

> "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"? ;)

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"

i can still argue each of your role titles:

> Distributed Systems Engineer

Not every distributed system is a kubernetes cluster

> Cluster Administrator

There are many services which should always run outside of kubernetes, loadbalancers are the easiest counter example. The IAM Role is called like that because its closely scoped to all things cluster in amazon.

> Container Platform Engineer

entails that you only work on the container platform, while a cluster admin for instance can setup everything on VMs or bare metal

> Deployment Automation Engineer

This sounds like you are only taking care of deployments, monitoring and logging come to mind as counter examples

> Or should I just call developers "IT"

I tend to call myself Freelance Sr. Engineer with Kubernetes / GitOps / DevOps / Golang Focus in order to bring german exactness to a widely defined field. So depending on my hat, I become what's necessary in that scope. But yeah, to most managers, I am simply someone from IT

Companies have a goal in mind when they go out an hire staff for their objectives. Overall I still think that DevOps is neither b*s* nor insufficiently defined to yield a job title. Titles are vague on purpose, because especially in the realm of DevOps your scopes will get extended to more things than just terraforming.

> This whole discussion is so mute

Sorry for being that guy, but it's "moot" not "mute". A moot point is a point with little relevance to the discussion at hand, while a mute point would be a point that is either unheard, or made using mechanisms other than speech.

thank you for the explanation, I corrected it

Well spotted. This comment should be upvoted - the article needs to be read through this lens.

> the article needs to be read through this lens

Would people read this article less critically without knowing the author's position?

If so, then THAT'S the problem with devops (and every other software buzzword). If someone is reading online about ideas in their profession, why should they ever treat the ideas with anything less than maximum critical thinking and distrust? This is their livelihood, after all.