4 ms·

"DevOps" was never originally a team or job role, it was just a workplace culture philosophy that dev and ops should work closely together rather than in isola

"DevOps" was never originally a team or job role, it was just a workplace culture philosophy that dev and ops should work closely together rather than in isolated, and often mutually hostile silos as was common in the 90s. It just became a buzzword that everyone had to have, then C-level leadership needed "invest in DevOps", "grow the DevOps team" (because buying is easier than fixing the culture) until we lost sight of the original point and DevOps just became... ops.

hgsgm 3y ago
Back when I hunted willy mammoths, "DevOps" meant that there was no "dev" and "ops"; developers did ops, to avoid the friction of throwing code over the wall. Essentially it meant more "vertical" "full stack" teams, instead of horizontal layers. You knew how to write and run your system, and probably has a narrower scope of product than someone who was dev for more features or who was ops for more apps.
- jmholla 3y ago
  Interesting. When I started I was told the idea is you apply operations principals to your developer workflows, i.e. your developers making code is as important as getting their code to production.
- jonhohle 3y ago
  That’s how I thought about it (and lived) as well. Developers knew how to configure operating systems and databases, deploy them, etc. Everything but racking their own hardware. And sometimes even that.
nhumrich 3y ago
Actually, it was a role before it was a culture. See: "COO", "SalesOps", "PeopleOps", etc.
coffeebeqn 3y ago
In the last few startups I’ve been at , DevOps just means Infrastructure Engineer
jonhohle 3y ago
I’ve always considered DevOps to be Developer/Operator - as in - you run the stuff you build. This perfectly aligns incentives for creating stable, scalable systems. If it goes down or breaks, the ones who wrote it are the ones who feel the pain. My last job was the first place I saw DevOps as developers working along side operators as DevOps, which was a slight improvement over when they didn’t work together, but seems unnecessarily disjoint. Unfortunately, they had compliance requirements that forced developers and operators to be separate humans with separate access. Not wanting to get back into that world, I’ve not looked at how strict those requirements are or if there are ways around it (HIPPA, FIPS, etc.), but it was an annoying distinction.
- twic 3y ago
  > I’ve always considered DevOps to be Developer/Operator - as in - you run the stuff you build This is also exactly how i've always understood the term, and it makes perfect sense. But the origin of the term is indeed in distinct dev and ops people working more closely together. The origin story is basically Patrick Debois watching this talk, and then turning the title into a noun: https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-a... I think the devs-do-ops idea was also floating around at the time (i was doing in in 2008!), somehow got swept up into the movement.
- cameronh90 3y ago
  The problem is that lots of developers who have no interest in operations, and even most who do aren't that good at it. I've worked with perfectly capable developers who didn't really know what an IP address was beyond "numbers with some dots in them". Personally I view platform engineering (or SRE) as the best endpoint of the ops role and devops philosophy. A good platform engineer is a developer that knows OSes, networking and databases and can expose abstractions that meet the requirements of application developers, akin to how a good application developer knows their the business domain and can expose an interface that meets the requirements of users. Nowadays, the platform engineering is often done by AWS or Google and that's sufficient for many developers and smaller organisations, but many orgs will probably still need some people of various skillsets between what is exposed by the cloud and the business requirements. I mainly think traditional ops is just a dead end. If something happens often enough that you feel like you need to develop a runbook and hire someone to follow it, you should just be automating the fix or fixing the underlying problem. DevOps in the sense of applying a development philosophy to ops (i.e. automation and version control rather than paper runbooks) and applying an ops philosophy to development (i.e. writing stable systems that are robust in the event of failures) is still a valuable philosophy, but the word itself is meaningless now.

hgsgm 3y ago

Back when I hunted willy mammoths, "DevOps" meant that there was no "dev" and "ops"; developers did ops, to avoid the friction of throwing code over the wall. Essentially it meant more "vertical" "full stack" teams, instead of horizontal layers. You knew how to write and run your system, and probably has a narrower scope of product than someone who was dev for more features or who was ops for more apps.

jmholla 3y ago
Interesting. When I started I was told the idea is you apply operations principals to your developer workflows, i.e. your developers making code is as important as getting their code to production.
jonhohle 3y ago
That’s how I thought about it (and lived) as well. Developers knew how to configure operating systems and databases, deploy them, etc. Everything but racking their own hardware. And sometimes even that.

nhumrich 3y ago

Actually, it was a role before it was a culture. See: "COO", "SalesOps", "PeopleOps", etc.

coffeebeqn 3y ago

In the last few startups I’ve been at , DevOps just means Infrastructure Engineer

jonhohle 3y ago

I’ve always considered DevOps to be Developer/Operator - as in - you run the stuff you build. This perfectly aligns incentives for creating stable, scalable systems. If it goes down or breaks, the ones who wrote it are the ones who feel the pain. My last job was the first place I saw DevOps as developers working along side operators as DevOps, which was a slight improvement over when they didn’t work together, but seems unnecessarily disjoint. Unfortunately, they had compliance requirements that forced developers and operators to be separate humans with separate access. Not wanting to get back into that world, I’ve not looked at how strict those requirements are or if there are ways around it (HIPPA, FIPS, etc.), but it was an annoying distinction.

twic 3y ago
> I’ve always considered DevOps to be Developer/Operator - as in - you run the stuff you build This is also exactly how i've always understood the term, and it makes perfect sense. But the origin of the term is indeed in distinct dev and ops people working more closely together. The origin story is basically Patrick Debois watching this talk, and then turning the title into a noun: https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-a... I think the devs-do-ops idea was also floating around at the time (i was doing in in 2008!), somehow got swept up into the movement.
cameronh90 3y ago
The problem is that lots of developers who have no interest in operations, and even most who do aren't that good at it. I've worked with perfectly capable developers who didn't really know what an IP address was beyond "numbers with some dots in them". Personally I view platform engineering (or SRE) as the best endpoint of the ops role and devops philosophy. A good platform engineer is a developer that knows OSes, networking and databases and can expose abstractions that meet the requirements of application developers, akin to how a good application developer knows their the business domain and can expose an interface that meets the requirements of users. Nowadays, the platform engineering is often done by AWS or Google and that's sufficient for many developers and smaller organisations, but many orgs will probably still need some people of various skillsets between what is exposed by the cloud and the business requirements. I mainly think traditional ops is just a dead end. If something happens often enough that you feel like you need to develop a runbook and hire someone to follow it, you should just be automating the fix or fixing the underlying problem. DevOps in the sense of applying a development philosophy to ops (i.e. automation and version control rather than paper runbooks) and applying an ops philosophy to development (i.e. writing stable systems that are robust in the event of failures) is still a valuable philosophy, but the word itself is meaningless now.