Jumziey

It's actually fun to see this. Running systems in a lot of different ways are just interesting. I do however get kinda sad at the hate at k8s because it's really good at what it does.

I've seen so many projects bending over backwards to avoid k8s and pay large cloud bills to avoid it at all costs. (ECS and app services are hopelessly expensive and bothersome)

K8s is really good, pretty easy to maintain, but a bit hard to understand. Mostly because distributed, zero down time systems are a bit hard to get by nature. But if you have someone that wants to take it on I've managed k8s clusters, solo, without incident, while doing lots of other stuff too (working with larger teams now though). Not to mention there's a lot of competence out there that can take over if I'd move on. Most of the deep complexity comes with more advance use cases, that wont show up for smaller deployments.

That said, no h8 towards going your own way! If your a solo developer (or small team) for a smallish project, don't feel the absolute need. If you get to the point you need it you should be earning enough to start paying someone to help ya get your app to a distributed system like k8s.

I think it's good to invest the time in understanding k8s though as a professional. Even if you won't directly run it it teaches you a lot about how to think about distributed, zero downtime systems. And what requirements that puts on an app.

SystemD bashing aside :p Talos is pretty awesome for setting up clusters. At home I just run talos with matchbox for PXE bootstrapping it works like a charm. Been really easy to maintain too. I normally just update matchbox and then reset a machine at a time with talos ctl for a clean install. It's something very reassuring with completely reset your machines so you know you could reinstall or replace them easily.

Granted just used in a home setting running smaller workloads for backups, private projects, git etc.

Lots of comments about issues with dependencies and Graal. I suggest looking into Quarkus. Have had great success with and mandrel (a patched version of Graal for Quarkus). Quarkus focuses on creating Web APIs so wont cover it all but if thats what you want to do its great and builds native images quite easily.

I think the issue is that any energi i spent on trying to make my apps have a less of a co2 footprint would be better spent engaging in climate questions instead, preferbly using ones profession.

Ie doing stuff like writing applications that scrapes metrics and show how green the energi grids are realtime, doing real time stuff around planes current climate effect given the amount of planes up in the air etc.

If thats not an option just vote with climate in mind and engage in public discussion around these issues would probably have a lot more potential

This is a great paper, did my master thesis on adapting in to autonomously navigating large bodies of water with a boat/ship or similar. For which it worked great!

It's almost weird it haven't gotten more attention yet! Awesome post ^^

So you think the issue is semantics and not understanding? Being due today and having 5 developers thinking the end goal is different and working against each other is way worse then spending some time building consensus and work toward the same goal

You can certainly misrepresent your own article. But in this case you're arguing different things as far as I interpret your text.

You having a successful career is not really relevant to the discussion.

I do agree though that the most important part of a professional life is to fill the gap within your team. But that's another discussion.

I supposed instead of saying DevOps has lost its meaning it has been co-opted from it's original meaning to something else. Problem is just that it isn't well defined. I like a definition like this, but as an earlier comment talked about a DevOps role is about facilitating the DevOps culture values, which is quite the different thing.

On another note, how amazing it is to define our systems so we can more systematically iterate on them and improve. I love it when developers get integrated into the process as well.

The general consensus where i work is that everyone does DevOps, you develop the app, you make sure you deliver the app, if there's any issues you debug. You ain't done until your ticket is in production, and you can't point to other to solve it for you, only help you.

Where does the DevOps engineer fit in there?

I'm all ears when you're on brake.

You can certainly advertise a DevOps culture in a listing that isn't for a DevOps engineer, it's not mutually exclusive.

What's DevOps skills in your opinion?

I think there's a point to the blog article itself, but i think you miss a vital point in the conclusion. The way a DevOps position that is described in the blog post is a valid position that could have DevOps in the title. But that's not usually how the DevOps role is used. This can be easily seen in many listings of the job title.

The analogy with agile is pretty good here. Sure you could have an Agile Engineer, that works primarily with making sure the agile process is actually used and help facilitating that. Normally that would not be a position itself though, especially not an engineering one.

In many way the adoption of DevOps has many similarities with the larger adoption of agile development. It just looses it original meaning in a world of little reflection and just surface level knowledge.

Those who can manage to surpass that though can get great productivity from it though.

Generally in my experience, a company that's looking for a DevOps engineer does not know what DevOps is.

DevOps is great, but it's not a title. It's beautifully summarized in "The DevOps Handbook" and it's fictional counterpart "The Pheonix Project". It's about culture.

Some people might feel different and want to re-evaluate due to so many company adapting it in a similar vein many companies want to adapt agile. But make no mistake, you can't define it then, since then the context of the company defines the word. Thus sadly the word is slowly loosing its meaning.

This is likely due to lots of management people wanting to adapt the buzzword without understanding it. This since it has have had such a great success in many companies that actually know what it is, have taken the DevOps culture to heart and implemented processes in line with it.