Old man yells at cloud.
My struggle from a UNIX background in the modern "cloud" world
Submitted 1 year ago by otl@lemmy.sdf.org to programming@programming.dev
https://www.srcbeat.com/2023/10/cloud-native/
Comments
Crackhappy@lemmy.world 1 year ago
otl@lemmy.sdf.org 1 year ago
I’m now 30 years old and I wonder what I’ll feel like after another 30 years :(
xantoxis@lemmy.world 1 year ago
Eh, I wouldn’t worry too much. I’m 48, and this rant still sounds like “old man yells at cloud” to me too.
It’s not age, it’s willingness to adapt.
safjx@lemmy.world 1 year ago
“I used to be with ‘it’, but then they changed what ‘it’ was. Now what I’m with isn’t ‘it’ anymore and what’s ‘it’ seems weird and scary. It’ll happen to you!”
Literally old man yells at cloud
Blamemeta@lemm.ee 1 year ago
I swear Im a decent coder, but fuck me if kubernetes and that whole ecosystem just confuses me
boblin@infosec.pub 1 year ago
I am someone with kubernetes in my job title. If you as a developer are expected to know about kubernetes beyond containerizing your application then your company has set itself up for failure. As you aptly said kubernetes is an ecosystem, and the dev portion is a small niche of that.
Gsus4@feddit.nl 1 year ago
What makes DevOps so different from sysadmin? Recruiters always told me it’s the same, but I never got the job, so idk.
ck_@discuss.tchncs.de 1 year ago
It’s actually pretty distinct. DevOps refers to the mindset (or philosophy, if you will) of “you build it, you run it”. It boils down to you as a software developer are also responsible for packaging up you masterpiece, pushing it through CI, getting it deployed and making sure it keeps on running smoothly. It is designed to shift responsibilities away from the sysadmin to the developer.
The problem with this is that it’s not a role or a job title, so recruiters and HR does not know how to work with it. Hence, they invented the DevOps “Role” because it sounds more modern. So in reality its used as a marketing term most of the time. So when someone pitches you a DevOps jobs, this tells you a few things:
- they don’t know what they are talking about
- the company behind the offer puts a lot of meaning into titles, which means things will likely be pretty hierarchical even though they claim it won’t be
- they’ll likely try to pay you less that your worth
toasteecup@lemmy.world 1 year ago
Recruiters lie my dude.
They are similar but with a strong knowledge set in different tools.
TCB13@lemmy.world 1 year ago
“Clould-native” software co-exists with corporate jargon. They obscure and complicate in the interest of perpetuating lucrative contracts over productive environments.
This.
PaX@hexbear.net 1 year ago
Agreed. What we need is real distributed operating systems, like Plan 9, not band-aids and kludges to keep old-world operating systems relevant in a networked world.
serialized_kirin@kbin.social 1 year ago
love the blog! interesting stuff.
custom_situation@lemm.ee 1 year ago
hating on k8s is very in vogue currently. simpler systems like ECS exist and are really good too.
anybody bitching too hard about the tools today isn’t remembering 10 years ago correctly.
boblin@infosec.pub 1 year ago
Running grep without parameters is also pretty fucking useless.
Claims to have a Unix background, doesn’t RTFM.
Translation: Author does not understand APIs.
Ok. Now give me high availability, atomic writes to sets of keys, caching, access control…
This reads as “I applied to the jobs and got rejected. There’s nothing wrong with me, so the jobs must be broken”.
JWBananas@startrek.website 1 year ago
Wat.
boblin@infosec.pub 1 year ago
Literally copied and pasted that from the article.
PaX@hexbear.net 1 year ago
The difference is grep is a simple tool that takes in text, transforms it, and outputs it to a console. It operates in a powerful and easy to understand way by default (take in text and print lines in the text containing the search parameters). This vmalert tool is just an interface to another, even more complicated piece of software.
Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…
The point is that these abstractions do not mesh with the rest of the system. HTTP and REST are very strange ways to accomplish IPC or networked communication on Unix when someone would normally accomplish the same thing with signals, POSIX IPC, a simpler protocol over TCP with BSD sockets, or any other thing already in the base system. It does make sense to develop things this way, though, if you’re a corpo web company trying to manage ad-hoc grids of Linux systems for your own profit rather than trying to further the development of the base system.
I would hope the filesystems you use are “high availability” lol
You’re right, that would be nice. Someone should put together a Plan 9 fileserver that can do that or something.
Plan 9 is capable of handling distributed access controls and caching (even of remote fileservers!). There’s probably some Linux filesystems that can do that too.
In the end, it’s not so much about specific tools that can accomplish this but that there are alternatives to the dominant way of doing things and that the humble file metaphor can still represent these concepts.
This is the maybe the worst way of interpreting what they said. They can come and correct me if I’m wrong but I read that as: they have a particular ideological objection to this “cloud” ecosystem and the way it does things. It’s not a lack of skill as your comment implies but rather a rejection of this way of doing things.
ck_@discuss.tchncs.de 1 year ago
man bashclocks in on about 43.000 words, just FYIboblin@infosec.pub 1 year ago
Not really just an interface. It is a pluggable service that connects to one or more TSDBs, performs periodic queries, and notifies another service when certain thresholds are exceeded. So with all those configuration options, why is the standalone binary expected to have defaults that may sound same on one system but insane in a different one? If the author wants out of the box configuration they could have gotten the helm chart or the operator and then that would be taken care of. But they seem to be deathly allergic to yaml, so I guess that won’t happen.
You just said that this software was much more complex than Unix tools. Also if only there were alternate documentation formats….
Until you need authentication, or of the box libraries, observability instrumentation, interoperability… which can be done much more easily with a mature communication protocol like HTTP. And for those chasing the bleeding edge there’s gRPC.
They’re not, and I’m disappointed that you think they are. Any individual filesystem is a single point of failure. High availability lets me take down an entire system with zero service disruption because there’s redundancy, load balancing, disaster recovery…
They can, and they still do… Inside the container.
Which I understand, I honestly do. I rejected containers for a (relatively) long time myself, and the argument that the author is making echoes what I would have said about containers. Which is why I believe myself to be justified in making the argument that I did, because rejecting a way of doing things based on preconception is a lack of flexibility, and in cloud ecosystems that translates to a lack of skill.
otl@lemmy.sdf.org 1 year ago
This is more along the lines I was thinking.
I think the parent comment went ad hominem rather than trying to understand some of the difficulties I brought up. I’m not sure whether engaging with them would be productive.