4 ms·

The contract between operations and dev (as concepts, not as people) is in need of renewal. To my mind, that was what "devops" was supposed to be, but it's bee

by duggan 12y ago

The contract between operations and dev (as concepts, not as people) is in need of renewal. To my mind, that was what "devops" was supposed to be, but it's been a bit of a dogpile in the years since the term gained popularity. Systems are opaque to most developers, and many developers wish to make their software opaque to the system on which it runs. This is a failure on behalf of our entire profession, not any one group. Infrastructure software is in a bit of a renaissance period, but it's very early days. Packaging software is a total mystery to most developers. I don't even need to back that up with examples, most of us can recall the last time we can across a well packaged piece of software with joy due to sheer rarity. I'd be very surprised to find the average age of a Debian maintainer was trending anything but upwards, and steeply. Containers are being misused, but that's because the alternatives we've been building for ourselves have not kept up with the strong user experience narrative of web and mobile software. We need to do better.

nvarsj 12y ago
It would be nice to have a well known 'devops manifesto'. I google'd it and came across this: https://sites.google.com/a/jezhumble.net/devops-manifesto/ https://sites.google.com/a/jezhumble.net/devops-manifesto/. Which I think is actually pretty decent - the emphasis on cross functional product teams, for instance. In my mind, that is largely what devops is about - team ownership of the entire product, which includes infrastructure. Instead of having a silo'd 'ops' team writing ansible scripts and doing deployment, this should be part of the team (which could mean having an opsy guy on the team). Anyways, as it pertains to containers, I think containers are more a practice than a principle. It tends to happen naturally when you want reproducible builds and continuous delivery. It's not really about making systems opaque to software, imo, but rather making your product artifacts reproducible (if you rely on running ./configure; make at deploy time, you never know what you'll end up with since dependencies are dynamically determined).
- kungfudevops 12y ago
  IMO here's the best "devops manifesto" out there: https://github.com/chef/devops-kungfu https://github.com/chef/devops-kungfu https://www.youtube.com/watch?v=_DEToXsgrPc https://www.youtube.com/watch?v=_DEToXsgrPc

by duggan 12y ago

nvarsj 12y ago

It would be nice to have a well known 'devops manifesto'. I google'd it and came across this: https://sites.google.com/a/jezhumble.net/devops-manifesto/ https://sites.google.com/a/jezhumble.net/devops-manifesto/. Which I think is actually pretty decent - the emphasis on cross functional product teams, for instance. In my mind, that is largely what devops is about - team ownership of the entire product, which includes infrastructure. Instead of having a silo'd 'ops' team writing ansible scripts and doing deployment, this should be part of the team (which could mean having an opsy guy on the team). Anyways, as it pertains to containers, I think containers are more a practice than a principle. It tends to happen naturally when you want reproducible builds and continuous delivery. It's not really about making systems opaque to software, imo, but rather making your product artifacts reproducible (if you rely on running ./configure; make at deploy time, you never know what you'll end up with since dependencies are dynamically determined).

kungfudevops 12y ago
IMO here's the best "devops manifesto" out there: https://github.com/chef/devops-kungfu https://github.com/chef/devops-kungfu https://www.youtube.com/watch?v=_DEToXsgrPc https://www.youtube.com/watch?v=_DEToXsgrPc