The one word I've not read is consistency (even used CTRL+F). It's one of the things I've been interested in since the 90's. I learned about inconsistency and programming when went to show someone a VB application, and it complained about a missing OCX-file. I Further learned when I tried to compile a Linux application under Windows. It used to infuriate me that nobody seemed to care.
For me efficiency and consistency are the only two drivers for any need to think about combining development and operations. Cost savings are almost tangential, because you could probably save money (short-term) by not testing, or following any one of a number of poor practices.
Once we've got consistency and efficiency (mostly for things few "want to care about"), we can proceed forward knowing the ground won't swallow us (or our free time) whole.
I think reliability is at the top of my list for "reasons to do DevOps". It's helped a lot by consistency, but that doesn't cover the whole of it. Establishing shared ownership and getting rid of the "well, that's an Ops problem" or "this is a Dev problem, send it back to them" goes a long way towards increasing reliability.
I'm fully on your side as far as shared ownership. It's probably because the businesses I work with are a lot smaller, but I still think it's important they have as much to gain (if not more) from embracing cross-over and all the benefits. Anyway great article, enjoy the weekend!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The one word I've not read is consistency (even used CTRL+F). It's one of the things I've been interested in since the 90's. I learned about inconsistency and programming when went to show someone a VB application, and it complained about a missing OCX-file. I Further learned when I tried to compile a Linux application under Windows. It used to infuriate me that nobody seemed to care.
For me efficiency and consistency are the only two drivers for any need to think about combining development and operations. Cost savings are almost tangential, because you could probably save money (short-term) by not testing, or following any one of a number of poor practices.
Once we've got consistency and efficiency (mostly for things few "want to care about"), we can proceed forward knowing the ground won't swallow us (or our free time) whole.
I think reliability is at the top of my list for "reasons to do DevOps". It's helped a lot by consistency, but that doesn't cover the whole of it. Establishing shared ownership and getting rid of the "well, that's an Ops problem" or "this is a Dev problem, send it back to them" goes a long way towards increasing reliability.
I'm fully on your side as far as shared ownership. It's probably because the businesses I work with are a lot smaller, but I still think it's important they have as much to gain (if not more) from embracing cross-over and all the benefits. Anyway great article, enjoy the weekend!