Kubernetes this. Kubernetes that. New tech this. New tech that. Let's ask developers to spend all their time on learning everything instead of concentrating on the fucking business problem that's no where related to Kubernetes or any fucking specific technology for many companies

K8S is still a very good and useful tech tho

@Lyniven It's the perspective. Maybe useful for all the operators, sysadmins. But developers really don't have to know what's going on behind the scenes. They just need to solve their fucking business problem which is usually unrelated to Kubernetes and move on. Only Kubernetes based business folks have to learn all that. And then operators, sysamins could learn it, set it up, whatever. All these companies asking a single role to do everything and learn everything, when the main thing is - solving the business problem which itself is a very complex thing usually

@ilikepleasure true story

@ilikepleasure so as a dev you never have to deal with your env settings and ops ? Meaning that in case of issue you have to wait for an ops/"sysadmin" to help you ? Damn

I think this rant is very true.

It's technology. But most hype it up to a level where it's not a "choice" in a wide range of options, but rather a forceful "we must use it".

That's d a n g e r o u s.

And it applies to a lot in IT. Let it be DevSecOps, IPC / message queues, microservices, No SQL, ....

Kubernetes is a good technology.

Docker V3 / Swarm does the same with a lot less complexity and might be sufficient for a lot of things without going "full bonanza".

In even smaller setups, Docker v2 without any form of cluster management and so on might be the right choice.

If you don't have the experience, don't have the man power and don't need it - don't use it.

I've had these debates really so many times I quite literal get heartburns and palpitation - cause it's really a struggle to get people to use the right toolset instead of just whatever currently is hyped in the groups mindset.

A last thing that is also very underrepresented in technical decisions is cost.

I once "won" a heated debate going on since 3 days (2 hour meetings each day) as I took the last straw available and made clear that the license costs for I think Varnish would make it impossible to hire an additional dev, and last straw as all the devs just were "unavailable" to rational answers.

I remember that we had a full alternative solution with no additional cost available...

Same for e.g. Kubernetes - if you don't need a cluster, nor high availability, nor redundancy on application level - it's quite literal burning money for no reason whatsoever.

@IntrusionCM I’m a super proud supporter of your comment!

@IntrusionCM basically the same rule about clean code.

KISS.
Do not over engineer it.

@Lyniven it sounds a bit wrong.
At least docker level for easy setting up environment for local testing during development with postgres/redis/mongo and e.t.c. should be learned for sure
At least it sounds like a mandatory for backend devs.
Otherwise how the hell are you going to have development with celery / caching / database quering and so on?

Well... technically same shared resource could be used provided by devops... but you cant be sure to have guy like that in company.

But if the dev is not from web, then sure I guess, he does not it then.

Weird @ilikepleasure guy.

@molaram he can answer your msg, and then we can double and triple vote ;)

@molaram well, it is good for devs to learn though, competitive skill ;)
It just can be not good for company to have.
But if they insist, who you are to disagree if they pay you for that.
I usually inform non tech people about bad choices though.

My role is to write software, I have no interest in deployment, availability, whatever else kubernetes is meant to handle. I have absolutely no motivation to learn this nor do I want it shoved down my fucking throat bc “it’s the new way to code”

Half of my work time is dealing with new shit I haven't used before

@molaram I smell the need for some communism here 🤔

And I only recently gotten the hang of Docker 😅

@TeachMeCode But its not the new way to code, its just the new way to deploy and run stuff.

If your company does devops then you'll have to learn those parts as well, if they don't do devops you have to deal with and wait for other people to handle those parts.

Trust me, dealing with people is far worse.

At my current job the developers handle everything related to the software (prioritize, code, test, build, deploy, monitor, etc) and can buy hardware, services and software as we need it. Having to learn a few extra simple things is a small price to pay for that freedom.

(If you're not trusted to make the decisions on what to use it might not be as fun though)

@ItsNotMyFault but you still do have some subdivision of responsibilities in the team, do you? Or everyone does everything?

@iiii we don't do such subdivisions since that only results in personal dependencies. People ofcourse are better at or prefer certain types of work but everyone is expected and trusted to do everything (or atleast expected to know how google works so that they can figure things out and to ask for help if they need it). If we split the team its for tackling multiple challenges in paralell, so basically i do backend. Frontend(web, mobile), general sysadmin, dba, if a feature requires a new service i would also set up the ci, monitoring, deployments, etc for it and if necessary set up new nodes. (Although since our k8s cluster adds new nodes as needed that would only be needed if a service required different hardware such as a gpu or more ram than our current nodes have).

We would also talk to stakeholders to determine what to build (or if we should build anything at all).

The only thing we won't do is graphics design. (We have design guidelines (made by a real designer) to follow)

@Lyniven More like, if there's an issue, I should be able to debug it without having to learn too much stuff. I want logs? I should be given some tool or GUI (web UI or something) to see the logs. Do I need to ssh into the environment? Have another tool for that. But asking Devs to understand Kubernetes, Kubernetes resources, and all the CRDs that are being used, it's just too much I think. A CRD can work in any way and one has to go learn about that in the CRD's docs

@Lyniven Kubernetes has become a monster and I think developers should be saved from it's complexity. Because learning Kubernetes is no easy task and if companies are gonna pay developers to learn and use Kubernetes, and spend time in that too, apart from mainstream work, it seems a bit much. Devs just need some tools and what not to work with their services, regardless of what platform it is on. Be able to build, test, run and test locally and in any environment the same way, without worrying about things. I mean, Kubernetes environments can have tons of issues - which are not related to the developer's service. And it's hard to even tell if it's a platform (Kubernetes) issue or service issue at times. I think we can do a lot better

Idk about the exact ideal situation, but surely the current situation ain't that great according to me

@Lyniven A Dev's job is to spend more time on business problem, than learning Kubernetes. And for deployment they only need to do a few things - define their service's deployment saying where's their repo / artifacts like Jar etc, how many instances or replicas, port exposing information maybe, kind of deployment like canary etc and configuration like environment variables / files etc, how to run their service with a command, any pre run commands like DB migration command, if service needs extra components like DB so that they can provision one with a click a get connection details. I think they really don't have to know if behind the scenes of docker is being used or Podman, or Kubernetes, or Nomad or whatever, or just plain old VMs with no platform for that matter

@ItsNotMyFault It makes sense. I understand that small companies might be doing this or even big ones if they don't want to cut down software development into very very tiny parts and assign it to teams and then make communication as the friction among teams. I just think that the company should also be aware that their developer is gonna end up doing a lot of things when doing all of this and that it eats up the time taken to build the actual software with business logic. And not all businesses are about Kubernetes. I also understand that availability, resilience, possibly reduced cost from shared infra if resources were underutilized before are all good things that come from orchestration, it should also be noted that more new systems, especially distributed systems means more complexity and also more time spent on maintaining and working with them which also comes with a cost. If it's a conscious decision, fine 🤷‍♂️

@iiii I guess every company deals with such things differently. Some companies would just split responsibilities. People who like to do just one thing would love such a setup. Some companies would just say "as a dev, you need to know everything we use" and this also helps with situations when someone goes on vacation or is sick, or leaves the team or company. People do pair programming and what not for similar reasons. People who love to learn everything and learn things across the stack would love such environments