[shortrounddev2]

> I am comfortable with the latter type of people administrating my servers. I am not comfortable about the former.

idk what kind of legacy orgs people in this thread work for where there are Linux sysadmins working for their companies which directly manage server configs and security settings. "Administering my servers" is an interesting phrase in 2023, because there often aren't any servers to directly administer (even a VPS is hard to find). The last few companies I worked for all used some kind of virtualized infrastructure and usually through some kind of declarative interface (Docker, Kubernetes, or some terraform-style tool). Certainly, the people who OWN the servers have sysadmins managing these things, but such things are an abstraction these days, where many organizations don't have to deal with CLI configuration and bash, and just leave infrastructure to devops or even the developers themselves

[distcs]

> idk what kind of legacy orgs people in this thread work for where there are Linux sysadmins working for their companies which directly manage server configs and security settings.

I don't know if you consider Amazon/AWS "legacy org". When I worked there I didn't think it was a legacy org. Yet they needed skilled Linux sysadmins. Sure they are called by fancy names like infrastructure engineer, production engineer, etc. but the work they did used core Linux kernel skills, scripting skills and programming skills, just to name a few of the skills.

A few years later I worked for another cloud provider and it was no different. I don't understand why you think only legacy orgs care about good system-administration skills.

[shortrounddev2]

Yes, obviously the people who offer the virtualized infrastructure are going to need the sysadmins. I'm talking about the majority of businesses and engineers which aren't cloud service providers, but rather customers of those providers.

[worksonmine]

> The last few companies I worked for all used some kind of virtualized infrastructure and usually through some kind of declarative interface (Docker, Kubernetes, or some terraform-style tool)

Which unfortunately is a problem in itself. A lot of core knowledge is lost and many people running infrastructure don't know how to read actual logs and debug outside of what the GUI shows. Just like you mention it's not even VPS these days it's a Dockerfile pushed to some cloud.

Copy/paste a Dockerfile, edit some yaml for the CI and claim you know DevOps. It's a shame really. I don't mind a nice minimal GUI when it makes sense, but it's important to understand the pieces below it.

[shortrounddev2]

> Which unfortunately is a problem in itself. A lot of core knowledge is lost and many people running infrastructure don't know how to read actual logs and debug outside of what the GUI shows. Just like you mention it's not even VPS these days it's a Dockerfile pushed to some cloud.

Plenty of k8s users are accessing their services and logs through CLI. It's just that the relevant logs are from the application and not whatever the underlying infrastructure is. It makes it way easier to have amazon deal with the underlying server and just let me focus on the actual application. Saves labor costs (in theory) by not having to hire an IT guy, and you can put more faith in the security practices of the cloud providers than in your own organization.

Your criticism reads like old school developers complaining about new devs learning Javascript without learning C or Assembly. Technology progresses, the set of baseline skills required to do your job changes. Few software engineers know anything about hardware or electrical engineering, but that used to be a requirement many decades ago.

> Copy/paste a Dockerfile, edit some yaml for the CI and claim you know DevOps. It's a shame really. I don't mind a nice minimal GUI when it makes sense, but it's important to understand the pieces below it.

What you've described is a way to make it dead simple for engineers to develop code without having to interface with a human being (a sysadmin) in between. It makes deployments consistent and easy. When you add CI/CD into the mix, you don't even need to run the command anymore, you just merge the master and swap your staging and production instances. Amazon can hire the sysadmins, the client can hire engineers.

[worksonmine]

> Your criticism reads like old school developers complaining about new devs learning Javascript without learning C or Assembly.

Valid point, but I'm a javascript dev tired of helping my peers figure out their tools when they're not even interested in discussing lower level topics on a normal day. I wish I had some grumpy old-timers around me to learn from.

> It makes deployments consistent and easy.

Consistent on the platform chosen at start, if you run into egress costs you might already be locked in to that platform and migrating AWS container format for every service might take time for those who don't understand what it does exactly. One simple mistake can be really costly if you forget to set limits. It's dangerous to put too much power in the hands of people who don't understand the possible consequences.

Don't get me wrong, I like modern software dev and day to day tasks should be easy. But too many people are lazy and uninterested in the details behind their craft. "Just install half the universe, why bother reinventing the wheel" is too common. You're not a DevOps unless you can setup and manage the workers on a CI on bare metal, you shouldn't always go that route in production though, but the knowledge is important.

[sgarland]

> Your criticism reads like old school developers complaining about new devs learning Javascript without learning C or Assembly.

It’d be great if JS devs could learn JS, but I’m not holding my breath.

Your comments read like someone who doesn’t believe you need to understand how the abstractions work, which tends to end in failure (or extremely high cloud bills).

[sgarland]

People who don’t know how to bootstrap a Linux box have no business spinning up a K8s cluster. It will eventually fail in a Linux-y way, and they will be hopelessly lost, begging ChatGPT for help.

Abstractions leak. They’re great, but you still need to know how they work.