[sharts]

I don’t think that’s true anymore. Most companies that seriously deploy k8s tend to have dedicated teams for it.

There’s no way an app developer is going to be able to do their work while also knowing the ins and outs of cluster mgmt.

[bonestamp2]

> Most companies that seriously deploy k8s tend to have dedicated teams for it.

Ya, and everywhere I've worked, that team is called "devops". The application developers are a different team. Maybe that's not the norm, but I thought it was.

[funcDropShadow]

> Ya, and everywhere I've worked, that team is called "devops".

But then that team is only doing operations and not development. Unless they are committers to k8s.

[bonestamp2]

Yes, in my experience they've always done development for the operational tasks.

[hosh]

There are app developers like that. There is a class of problems where you need to be able to do both application development and system work to be able to do well.

What a lot of people miss about larger k8s deployment is that you can create an internal platform team, like a micro-heroku within the company. The company would have to hire people who can create _products_ and also knowing how to work with infra in order to create a platform. It would be this rare combination of product, dev, ops, and focusing on supporting the rest of the engineering team and giving up on the glory of launching something for end users.

[marcus_holmes]

This is one of those cycles that IT does regularly every other decade.

In the early days, computers were huge things that were maintained by a team of specialists (and who actually soldered things together). Getting anything changed involved a series of paper forms and waiting for a specialist to do it for you.

Then came the microcomputer revolution and computers became small things that sat on desks and were maintained by the office geek. Changing anything meant talking to him (it was always him) and it would be done by lunchtime, and you owed him a coffee.

Then companies learned that this meant that no two offices had the same configuration, application suite, or even operating system. IT was centralised, and every office issued with the same stuff. Getting anything changed meant filling in forms and waiting for System Administrators to get around to it.

Then Agile and the Cloud happened and while the rest of the company had to carry on filling in forms, the IT Department turned into Engineering and DevOps was born. Every developer learned how to deploy their stuff to the cloud by themselves.

Then organisations worked out that that meant that applications were deployed badly, using a wide variety of tools and technologies, and essential security practices got skipped because no-one was responsible for them. So DevOps was turned back into SysAdmin and the forms reinvented as JIRA tickets.

And so we go on. There are micro-cycles within these ones, like the one about terminals (are you typing on the actual computer, or on a terminal that talks to the actual computer which is somewhere else? The answer depends on which decade you're in).

The ideal solution is somewhere in between (enough central control for it not to get into a mess, but enough decentralisation to prevent bureaucracy and allow for agility in the actual business). But that is a very hard balance to find and keep.

[politelemon]

That's the problem, many companies don't realize they need to be serious, they just have a few people who want k8s in their stack.

[jml78]

They don’t need to know k8s administration but they need to understand how their services are going to function and scale in k8s.

[funcDropShadow]

But somebody has to know k8s administration.

[jml78]

Yeah, that is me bro.

I started back in 2016 building k8s clusters from scratch via terraform and bash scripting. It was ugly awful but worked thru Covid with zero downtime when we switched to hosted solutions from AWS and Google cloud.

[metalforever]

Everywhere I've been recently has devs doing the ops. This includes big places you have probably heard of.