[mosura]

It failed because there is an ongoing denial that development and operations are two distinct skillsets.

If you think 10x devs are unicorns consider how much harder it is to get someone 10x at the intersection of both domains. (Personally I have never met one). You are far better off with people that can work together across the bridge, but that requires actual mutual trust and respect, and we’re not able to do that.

[whynotmaybe]

The goal of dev is to be able to change everything whenever they want.

The goal of ops is to have a strong infra that has the fewest changes possible.

They are opposite and usually there are more devs than ops but the first respondent to an issue are ops.

You can only have devops if both roles are intertwined in the same team AND, the organization understands the implications.

Everywhere I've been, devops was just an excuse to transfer ops responsibilities to dev because dev where cheaper. Dev became first respondents without having the knowledge of the infrastructure.

So dev insisted to have docker so that they would be the one managing the infra.

But everyone failed to see that whichever expensive tools you buy, the biggest issue was the lack of personal investment to solve a problem.

If you are a 1.5x dev in a 0.9x team, you get all the incidents, and are still expected to build new stuff.

And building new stuff is fun.

Spending 2 days to analyze a performance issue because a 0.3x dev found it easier to do a .sort() in Linq instead of Sql is fun only once.

[random3]

People can’t care about stuff they don’t know about. Split the roles and you split responsibility. It’s the same with dev and QA. Suddenly, the person paid to care about quality or stability realizes that the person who’s paid for something else doesn’t care like their job depends on it. Because it doesn’t. So OP above is right, splitting things and specializing horizontally is most times a bad and, if you think about it, not very smart move.

[vee-kay]

From someone who has managed both Developmentals team and Operations team for decades.. trust me, they are different beasts and have to be handled/tackled differently.

Expecting Devs or Ops to do both types of work, is usually asking for trouble, unless the organization is geared up from the ground up for such seamless work. It is more of a corporate problem, rather than a team working style or work expectations & behavior problem.

The same goes for Agile vs Waterfall. Agile works well if the organization is inherently (or overhauled to be) agile, otherwise it doesn't.

[SkiFire13]

> Expecting Devs or Ops to do both types of work, is usually asking for trouble, unless the organization is geared up from the ground up for such seamless work.

Could you expand on this? How would an organization be geared up for this?

[frogperson]

I agree. The domains are just too large for anyone to be an expert in everything. Platform engineers are expected to know 3 clouds, k8s, cloudflare, security, SRE, python, javascript, CI/CD and about 20 other things. Its just not possible to be great at all the things at the same time.

Employers would rather pay one salary than 2. They are not punished for demanding more frim their employees.

We really ought to form some kind of union that operates across companies. We must demand better working conditions.

[pjmlp]

For example, https://www.igmetall.de/service/berufeglossar/informatik-gru...

[tsss]

You don't need 10x developers. You just need to avoid the 1/10 multiplier of pitting separate development and operations teams against each other.

[antod]

> You are far better off with people that can work together across the bridge, but that requires actual mutual trust and respect, and we’re not able to do that.

Wasn't that the original goal of DevOps? Getting dev and ops not being siloes and get them collaborating? The "make devs do ops" definition seemed to come along later.

[Conan_Kudo]

The original goal of DevOps never happened. Companies immediately jumped on this with "rationalizations" and "integrations" to make it so fewer people were in charge of more things.

[DarkNova6]

But is DevOps a role or a principle?

The way I have seen it in my carreer is to have operational and development capabilities within the same team. And the idea of a „DevOps guy“ is a guy „developing operations integrations“.

As opposed to completely siloing ops nd dev.

[pjmlp]

For most companies, it is a role, the new name for IT administrators.

[dsr_]

DevOps is the practice of using modern software methods to automate the tasks of operations work. That includes using version control, templating languages and various forms of role-based configuration automation.

Anyone who thinks they can hire a devop or declare that they do devops is as deluded as 97% of the folks who claim that they are doing Agile. (If you are firmly on the other side of each of the four principles of the Agile Manifesto, you may or may not be doing great software development, but it's not Agile.)

The problem with the typical DevOps team is that there's no operations expertise.

[ofrzeta]

I've had recruiters telling me they are "looking for a devops" (not even a "devop").

[tbrownaw]

> You are far better off with people that can work together across the bridge, but that requires actual mutual trust and respect, and we’re not able to do that.

Are you claiming it's fundamentally impossible for people to get along, or just that positive interpersonal relationships can't be reliably forced at scale?

[ramoz]

I mean, look at Kubernetes though. You have to understand both the application and the infrastructure in order to get the deployment right. Especially in any instance of having to pin the runtime to any type of resource (certain disk writing, GPUs, etc).

[firesteelrain]

My experience has been that devs don’t understand their own app resource requirements

[verdverm]

That's not a kubernetes specific issue. If you run on VMs or Edge, devs also need to know the resource requirements. If anything, k8s makes that consistent and as easy as setting a config section (assuming you have the observability to know what good values are). The default behavior I've seen is to set reqs w/o lims so you get Sche'd but not OOM'd