DevOps was a reasonable idea, but it rarely actually manifested. If a company had an actual "DevOps group" separate from the developers, by definition they weren't doing DevOps.

▲

LargeWu 5 hours ago | parent | next [-]

Part of the problem, and what ultimately drove me out of coding altogether, is that Ops is a specialized skillset completely orthoganal to the business of building applications. And, I was really bad at it due to a complete lack of interest. As cloud environments get more and more complicated one ends up spending more and more time dealing with that at the expense of building things.

Conversely, there are lots of folks who love ops type problems and are not well suited to building apps. So, it makes sense to put them on separate teams where they can each do the thing that they're best at, rather than fumble through the parts of the jobs they hate. But yes, at this point it's not really DevOps anymore, it's just ops.

▲

dcss_gardener 5 hours ago | parent | next [-]

IMO it was a worthwhile experiment that probably went too far before being rejected.

Having the maintenance/ops requirements directly feed back into the design and engineering of the product is genuinely powerful. Especially for certain kinds of products, if executed with discipline you can get really good engineering reaction time with no degradation of quality, and often with much cheaper infra costs.

The problem is what you said though. People with both skillsets are rare, and combining them is legitimately a third skill on its own. And even "both" skillsets is a simplification once you start accounting for data, security, compliance, large scaling DB work etc.

It was mostly a dead end for these reasons but it was worth exploring for its potential. And some genuinely good engineering techniques went mainstream out of it, not a total waste.

▲

netcoyote 5 hours ago | parent | next [-]

> Having the maintenance/ops requirements directly feed back into the design and engineering of the product is genuinely powerful.

You’re so right. This is the key, whether a team is doing devops or not.

One of my major contributions when I took on a CTO role was getting dev, ops, and support teams to talk about the pain points. There were so many easy wins to make things run better because the teams didn’t understand the difficulties the other teams were going through.

▲

sublinear 5 hours ago | parent | prev [-]

Isn't that just anyone with an "architect" job title though? I don't think that kind of dev is particularly rare at all.

I've found that "ops" has become far too overabstracted and jargony. Their moat is endless "certifications". Their "experts" are the dogmatic personality types who try everything in their power to prevent their feet from ever touching the ground like it's lava. They lack the kind of dev or sysadmin experience where you have to stand under your own constructions like a Roman engineer.

Any formerly-known-as "full stack" dev who kept at it for the last decade and a half would run circles around anyone in ops. That's every senior dev working right now who doesn't like to manage people.

It used to be that the ones who went SRE just wanted a pay bump for a bullshit job of relatively light coding puzzles and parroting stuff in meetings, but I guess that well has dried up with "AI".

	▲	everforward 4 hours ago \| parent \| next [-]
		Coming from the Ops side, “full stack” usually translates to “our entire infrastructure stack is managed AWS services, we don’t know how they work”. It turns out about as well as if you set the Ops team to shipping features. Eg I’ve seen more than one full stack dev team build a synchronous RPC-over-message-bus framework because they can’t figure out how to make HTTP or actual RPC calls reliable. It is hands down the most poorly and overengineered thing I have ever seen on a service that takes single digit qps. The ops teams fight that shit tooth and nail because if it blows up, they’re the ones who get called. And it is 100% too late to fix it by then. Ripping it out will take months, and the dev team will say they’ll do it, but they never will because the VP is leaning on them about some feature. You either say no early, or you are forever on the hook for whatever abomination the intern has cooked up.
	▲	dcss_gardener 4 hours ago \| parent \| prev [-]
		Right but the dream and promise of devops was that early-to-mid career line engineers could do these things, that these weren't rare skills and combining them wasn't particularly challenging. This turned out not to be the case, these skills are the requirement not the outcome. But if you have the budget and connections to hire a department of people with these skills and experience, and a problem interesting enough to keep them engaged in the day to day building, and a leader capable and charismatic enough to align them all into the business's goals... you should do that.

▲

aleph_minus_one 5 hours ago | parent | prev | next [-]

> Ops is a specialized skillset completely orthog[o]nal to the business of building applications.

Exactly this was the idea: persons in a DevOps role have skills in both areas, i.e. are very wide skill set, so that one can assign them to very diverse tasks for more flexibility. Additionally, these persons can implement synergies to make things more efficient in areas that intersect both development and operation.

▲

ragall 4 hours ago | parent [-]

No, what you descrive is SRE. DevOps was the idea to give people that work 100% as developers the ability to do some amount of ops work (let say 5%), as a way to break the silo between Dev and Ops that existed in older organizations.

▲

LargeWu 2 hours ago | parent | next [-]

In practice though, at least at places I worked, it wasn't 5%, it was more like 80%.

▲

macintux 3 hours ago | parent | prev [-]

I am skeptical that either label is sufficiently well-defined and more importantly well-understood within the industry to offer definitive statements on the differences.

	▲	ragall 3 hours ago \| parent [-]
		Of course it's misunderstood and misused, but that doesn't mean that more discerning people can't understand where it came from and why, and then used the term properly.

▲

KaiserPro 5 hours ago | parent | prev | next [-]

it only really worked as part of a team.

Where it worked well is the "devops" or sre/sysadmin would sit in the same team and take away the rough edges of the infra.

conversly they would also keep an eye on the web people and see what they are doing and why, learning the tooling they use and try and rationalise it so they don't install 50 messaging queues.

▲

ludicrousdispla 3 hours ago | parent | prev | next [-]

yeah, I am a software developer, not a system administrator.

In the early days of devops it was primarily focused on supporting developer productivity (CI/CD) but quickly morphed into sysadmin once cloud computing took off.

▲

iamflimflam1 5 hours ago | parent | prev | next [-]

At one point I was very hopeful that the progression from Infrastructure as a service to Platform as a service was going to simplify things. Instead we seem to have ended up with mind boggling complex services.

	▲	oasisbob 4 hours ago \| parent [-]
		I think this one is really localized. Some places do have really well built out platforms where logging, instrumentation, databases, deployment methodologies, IaC, etc have well-built happy paths that exclude a bunch of accidental complexity. I think a lot of other places are either too small or grow too quickly with the wrong set of values and admit too much into their "platform" which had very little design to begin with.

▲

intelVISA 3 hours ago | parent | prev | next [-]

Imo a dev with no ops exp is like a chef who never tastes their own meals.

	▲	LargeWu 2 hours ago \| parent [-]
		I think a more apt analogy is a chef who is not waiting tables. Which, by the way, are typically completely different roles in a restaurant. Your comparison might work better for a dev with no testing experience. Write the code and throw it over the wall. But I fail to see how an application engineer should need to worry about the intricacies of, say, setting up virtual private gateways.

▲

jeffrallen an hour ago | parent | prev [-]

I disagree: ops is related to dev, because good dev work makes ops easy. But they are different: being good at ops requires a mindset of curiosity, risk management, and being willing to chase things to to last details.

▲

weakfish 3 hours ago | parent | prev | next [-]

I am consistently surprised that I'm unique for enjoying, and if I may be so bold, being pretty good at, both Ops and appdev. Now I'm not the greatest in the world, but I really do firmly believe now that most generalists should strive to be able to do both at a journeyman level.

To my understanding, this _is_ DevOps in the original sense of the word, and the version where they are a separate team is an offshoot bastardization.

At my last job, it was somewhere in-between where we had DevOps specialists who were regular software engineers who allocated the bulk of their time to building / running infra via Real Code (Pulumi vs. TF, minimal YAML wrangling etc) and built paths for app devs to self-service as much as they could. That, I felt, was a really excellent setup.

▲

blauditore 4 hours ago | parent | prev | next [-]

Yes, big companies have a tendency to over-structure things. Devops? Sounds great, let's have a dedicated team for it. Agile? Absolutely, and to make sure it's done right, we need a rigid process around it.

	▲	macintux 3 hours ago \| parent [-]
		The rigid process around agile is absolutely mind-blowing to me, and it seems like it's everywhere in corporate environments, but my current client dials it up to 11. Maddening.

▲

jeffrallen 2 hours ago | parent | prev | next [-]

Devops definitely still exists, I've seen it. It is when people are responsible, even in the middle of the night, for the systems they fucked up engineering in the day.

▲

everfrustrated 4 hours ago | parent | prev [-]

Real DevOps is actually just Dev - in that the Devs are doing the Ops. The people called DevOps are just there to backstop the devs oncall when shit hits fan and you need someone more experienced in ops / incident management to escalate to.