3 ms·

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 sys

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.

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.