4 ms·

om my god this guy is full of stuff..... >> "The growing zeitgeist is that “platform engineering is the future.” And given that I co-founded a product in the s

om my god this guy is full of stuff..... >> "The growing zeitgeist is that “platform engineering is the future.” And given that I co-founded a product in the space, I sure hope so!" 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. Kubernetes can be deployed with a single binary nowadays there is no magic anymore the terraform scripts do look similar because you are not doing the actual hard parts like cis compliance or even selinux. This whole discussion is so moot, that every time it comes up i feel a little bit sad inside. Call the things i do what you want, call us the "server-clowns" who cares. It doesn't matter if its "platform engineering" "principle engineer" "devops dude" its the whole shebang of "guy with experience builds stuff that code runs on". 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. And then you hire the cheapest ones and wonder why you need 15 of them. None of this is hard if you have been playing with these concepts for ages and finally that's what companies pay you for. And having your entire statup on serverless? Give me a break. How can you tell that someone doesnt follow compliance or any other regulatory body in one sentence.... If you click on the username you will see that this person tried the same post 7 month ago and therefore i will say it again: Please let al bundy, the shoesalesman complain somewhere else.

urbandw311er 3y ago
Well spotted. This comment should be upvoted - the article needs to be read through this lens.
- dogleash 3y ago
  > 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.
dijit 3y ago
> 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_Glossary_14.pdf https://fileadmin.cs.lth.se/cs/Education/ETS170/IREB_CPRE_Gl...
- jhoelzel 3y ago
  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.
dumpsterdiver 3y ago
> 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.
- jhoelzel 3y ago
  thank you for the explanation, I corrected it
zemo 3y ago
> 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.
- jhoelzel 3y ago
  > " 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 =)

urbandw311er 3y ago

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

dogleash 3y ago
> 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.

dijit 3y ago

> 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_Glossary_14.pdf https://fileadmin.cs.lth.se/cs/Education/ETS170/IREB_CPRE_Gl...

jhoelzel 3y ago
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.

dumpsterdiver 3y ago

> 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.

jhoelzel 3y ago
thank you for the explanation, I corrected it

zemo 3y ago

> 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.

jhoelzel 3y ago
> " 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 =)